Namjae Jeon <linkinjeon@xxxxxxxxx> writes: >>>> Hm, why d_count == 1 check is needed? Feel strange and racy. >>> Since, fat_file_release() is called on every close for the file. >> >> What is wrong? IIRC, it is what you choose (i.e. for each last close for >> the file descriptor). > Yes, this is what we had chosen after discussion. Freeing reserved > space point being the file release path. > But if there are multiple accessors for the file then file_release > will be called by each process. > Freeing the space in first call will result in wrong file attributes > for the other points. So, we needed a differentiation of last close > for the file. > Am I missing something ? Then, per-file discard fallocate space sounds like wrong. fallocate space probably is inode attribute. >> I know. Question is, why do we need to initialize twice. >> >> 1) zeroed for uninitialized area, 2) then copy user data area. We need >> only either, right? This seems to be doing both for all fallocated area. > We did not initialize twice. We are using the ‘pos’ as the attribute > to define zeroing length in case of pre-allocation. > Zeroing out occurs till the ‘pos’ while actual write occur after ‘pos’. > If we file size is 100KB and we pre-allocated till 1MB. Next if we try > to write at 500KB, > Then zeroing out will occur only for 100KB->500KB, after that there > will be normal write. There is no duplication for the same space. Ah. Then write_begin() really initialize after i_size until page cache boudary for append write? I wonder if this patch works correctly for mmap. Thanks. -- OGAWA Hirofumi <hirofumi@xxxxxxxxxxxxxxxxxx> -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
