Date:   Fri, 1 Feb 2019 15:28:30 +0100
From:   Dominique Martinet <asmadeus@codewreck.org>
To:     linux-nfs@vger.kernel.org
Cc:     linux-fsdevel@vger.kernel.org
Subject: NFSv4 i_blocks=0 immediately after creating a file (Was:
 inode_add/set_bytes and i_blocks, dangerous for small files?)
Message-ID: <20190201142830.GA2177@nautica>
References: <20190125140229.GA5119@nautica>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <20190125140229.GA5119@nautica>
User-Agent: Mutt/1.5.21 (2010-09-15)
Sender: linux-nfs-owner@vger.kernel.org
Precedence: bulk

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.

Thanks,
-- 
Dominique