On Feb 1, 2019, at 7:28 AM, Dominique Martinet <asmadeus@xxxxxxxxxxxxx> wrote:
>
> Following up on this for NFS as I made a sneaky bug report hard to
> notice, this might be worth having a look:
>
> Dominique Martinet wrote on Fri, Jan 25, 2019:
>> [...] There is a small, few seconds window
>> where I can reproduce a similar issue on nfs:
>> $ echo foo > bar; stat -c %b bar; sleep 3; stat -c %b bar
>> 0
>> 8
>> with a 4.14.87 knfsd and 4.19.15-300.fc29 client, nfs 4.2, both x86_64,
>> no export option or explicit client option.
>
> In other words, the file's i_blocks isn't updated for a short while on
> nfs v4 which might lead to data loss (see previous email for example
> e.g. tar), just create a file and immediately stat to notice.
>
>
> nfs v3 doesn't exhibit the problem.
>
> I also wasn't able to reproduce on the 4.14.87 machine as a and nfs v4
> client so it's likely a semi-recent regression, I could probably bissect
> it if really required but I'm sure someone here has some dedicated
> hardware for this better than my laptop :)
>
> Feel free to ask if you cannot reproduce and I'll try updating to master
> on both client and server just in case.
The "i_blocks == 0" causes problems with some software that thinks the file
has no data and treats it as sparse. We work around this in ext4 and Lustre
by always reporting i_blocks > 0 for files that have data in them (e.g.
unwritten dirty pages or inline data), see comments nin ext4_file_getattr():
/*
* If there is inline data in the inode, the inode will normally not
* have data blocks allocated (it may have an external xattr block).
* Report at least one sector for such files, so tools like tar, rsync,
* others don't incorrectly think the file is completely sparse.
*/
if (unlikely(ext4_has_inline_data(inode)))
stat->blocks += (stat->size + 511) >> 9;
Cheers, Andreas
Attachment:
signature.asc
Description: Message signed with OpenPGP
