Mkrtchyan, Tigran wrote: >> From: "Dave Noveck" <davenoveck@xxxxxxxxx> >> To: "Marc Eshel" <eshel@xxxxxxxxxx> >> Cc: "linux-nfs" <linux-nfs@xxxxxxxxxxxxxxx>, "Ganesha-devel" <devel@xxxxxxxxxxxxxxxxxxxxx>, "NFSv4" <nfsv4@xxxxxxxx>, >> "linux-nfs-owner" <linux-nfs-owner@xxxxxxxxxxxxxxx> >> 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
