2013/9/23, OGAWA Hirofumi <hirofumi@xxxxxxxxxxxxxxxxxx>:
> Namjae Jeon <linkinjeon@xxxxxxxxx> 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?
Ah.. Sorry for wrong reply. old memory make me confusing.
By allocating cluster in fat fallocate, when write, fat_bmap of
get_block return physical sector number.
So buffer is not set to new in _fat_get_block.
When we fallocate with keep size on -> only clusters are added to the
fat chain calling fat_get_cluster(),and add the cluster to cluster
chain.
This doesn’t call fat_get_block() .
Now when we try to write in the fallocated region in the
fat_write_begin() when it is called first time it checks that the
mismatch is present between the mmu_private and mmu_actual (i.e., the
file has pre-allocated blocks), and hence zero out the region ;
Since buffer_new() is not set for fallocated region by fat_get_block()
, we explicitly zero out the lseek'ed region using
“fat_zero_falloc_area” and normal write occurs beyond that,and i_size
is updated accordingly.
Thanks :)
>
> 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
