Re: [PATCH v6] fat: additions to support fat_fallocate

[OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>]

Namjae Jeon <linkinjeon@gmail.com> writes:

>>> +	if (MSDOS_I(inode)->mmu_private > round_up(i_size, sb->s_blocksize)
>>> +			&& pos > i_size) {
>>> +		err = fat_zero_falloc_area(file, mapping, pos);
>>> +		if (err) {
>>> +			fat_msg(sb, KERN_ERR,
>>> +				"Error (%d) zeroing fallocated area", err);
>>> +			return err;
>>> +		}
>>> +	}
>>
>> Again, I'm not fan of this way.
>>
>> Normally, get_block() returns with buffer_new(). Then, caller checks
>> blockdev buffer with
>>
>> 	unmap_underlying_metadata(bh->b_bdev, bh->b_blocknr);
>>
>> then, zeroed buffer. Do we really don't need to check this race?
> We considered after your advice before. we reach for the conclusion
> that use this method.
> because, Cluster is already allocated in fat fallocate and
> when we write with radom offset over i_size on fallocated region, It
> will be hit by fat cache in fat_bmap of get_block, which mean buffer
> is not set to new.

Hm, how does it hit to fat cache? I think fat_alloc_clusters() and
fat_chain_add() doesn't update fat cache, right? I.e. initial write
after fallocate() should not hit fat cache over i_size?

Thanks.
-- 
OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>