8:54 p.m.
Mkrtchyan, Tigran wrote:
> From: "Dave Noveck" <davenoveck(a)gmail.com>
> To: "Marc Eshel" <eshel(a)us.ibm.com>
> Cc: "linux-nfs" <linux-nfs(a)vger.kernel.org>,
"Ganesha-devel" <devel(a)lists.nfs-ganesha.org>, "NFSv4"
<nfsv4(a)ietf.org>,
> "linux-nfs-owner" <linux-nfs-owner(a)vger.kernel.org>
> Sent: Saturday, February 23, 2019 12:38:56 AM
> Subject: Re: [nfsv4] file size and getattr
>
>> Does the NFSv4 spec allows the server to return file size that doesn't
>> include the unstable write to the writer or any other NFS client?
>
> I would say "no". Consider the followiing sentence in the description of
> COMMIT.
>
I would say "yes". Let's have a look at LAYOUTCOMMIT. Spec says:
"The metadata server may
use this information to determine whether the file's size needs to be
updated. If the metadata server updates the file's size as the
result of the LAYOUTCOMMIT operation, it must return the new size
(locr_newsize.ns_size) as part of the results."
I read this as: Metadata server may not know real file size until client sends
the file size information. Our DSes return DATA_SYNC and relay on client to
issue LAYOUTCOMMIT to update file size (well, on close we force data servers
up update file anyway).
For the pNFS case, when I implemented a pNFS server for FreeBSD, I assumed
that the Metadata server only needed to return a correct size for a file
to a client doing a Getattr with a read/write layout after it did a LayoutCommit.
This implementation worked ok for the FreeBSD client, but did not work
correctly for the Linux-4.17-rc2 kernel.
To fix the server implementation to interoperate with the above Linux kernel,
I had to add a tunable that makes the server get an up to date size for the
Getattr operation for a client when a read/write layout is issued to the client.
Just to be clear, I am referring to the case where the Getattr was done by the
client that holds the read/write layout and not another client.
(This does result in additional overheads whenever a client holds a read/write
layout for the file.)
I can't remember exactly how the Linux client failed, but I suspect it would
see a premature EOF when the size returned by the MDS was smaller than
the actual size of the file on the DS.
I honestly don't know if this is a bug in the Linux client or a misinterpretation
of RFC5661?
rick