lkml.org 
[lkml]   [2013]   [Sep]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [PATCH v6] fat: additions to support fat_fallocate
Date
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>


\
 
 \ /
  Last update: 2013-09-23 15:41    [W:0.072 / U:5.832 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site