file size and getattr
What is the file size returned by the NFS server for getattr after an unstable write to the NFS client that did the write or to other NFS clients. As far as I know most file systems will always return the file size that includes the unstable writes. 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? Marc.
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.
If the count is zero, a flush from the offset to the end of the file is done.
Note that he size returned by GETATTR gives you the end of the file so that, if it did not reflect the unstable writes, COMMIT wouldn't work right. On Fri, Feb 22, 2019 at 6:25 PM Marc Eshel <eshel@us.ibm.com> wrote:
What is the file size returned by the NFS server for getattr after an unstable write to the NFS client that did the write or to other NFS clients.
As far as I know most file systems will always return the file size that includes the unstable writes.
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?
Marc.
On Feb 22, 2019, at 3:38 PM, David Noveck <davenoveck@gmail.com> wrote:
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.
If the count is zero, a flush from the offset to the end of the file is done.
Note that he size returned by GETATTR gives you the end of the file so that, if it did not reflect the unstable writes, COMMIT wouldn't work right.
On Fri, Feb 22, 2019 at 6:25 PM Marc Eshel <eshel@us.ibm.com <mailto:eshel@us.ibm.com>> wrote: What is the file size returned by the NFS server for getattr after an unstable write to the NFS client that did the write or to other NFS clients.
As far as I know most file systems will always return the file size that includes the unstable writes.
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?
Marc.
_______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www.ietf.org/mailman/listinfo/nfsv4
Assume a fresh file, you do a WRITE, and get back the count in the WRITE4resok. You would expect that to be the same length as a subsequent GETATTR - notice nothing was said about the stable_how4 in the argument.
----- Original Message -----
From: "Dave Noveck" <davenoveck@gmail.com> To: "Marc Eshel" <eshel@us.ibm.com> Cc: "linux-nfs" <linux-nfs@vger.kernel.org>, "Ganesha-devel" <devel@lists.nfs-ganesha.org>, "NFSv4" <nfsv4@ietf.org>, "linux-nfs-owner" <linux-nfs-owner@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). Tigran.
If the count is zero, a flush from the offset to the end of the file is done.
Note that he size returned by GETATTR gives you the end of the file so that, if it did not reflect the unstable writes, COMMIT wouldn't work right.
On Fri, Feb 22, 2019 at 6:25 PM Marc Eshel <eshel@us.ibm.com> wrote:
What is the file size returned by the NFS server for getattr after an unstable write to the NFS client that did the write or to other NFS clients.
As far as I know most file systems will always return the file size that includes the unstable writes.
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?
Marc.
_______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www.ietf.org/mailman/listinfo/nfsv4
Your question was about an NFS server, which I assumed meant an integrated data server and metadata server. In that case, the answer is "no". In the case in which the data server and metadata server are distinct, there can be a disagreement but the data server has to know the corect length of the file even if there is no way for the client to ask for it. For example, if you (or another client) read data written unstably, and there was been no restart you will see bytes past the eof as known by the metadata server. BTW, I'm curous whether this poential inconsistency can occur even if the writes are done stably. I assume it can since, in that case, you would be in the same position n which a COMMON, but not a LAYOUTCOMMIT, had been done. On Mon, Feb 25, 2019 at 3:49 AM Mkrtchyan, Tigran <tigran.mkrtchyan@desy.de> wrote:
----- Original Message -----
From: "Dave Noveck" <davenoveck@gmail.com> To: "Marc Eshel" <eshel@us.ibm.com> Cc: "linux-nfs" <linux-nfs@vger.kernel.org>, "Ganesha-devel" < devel@lists.nfs-ganesha.org>, "NFSv4" <nfsv4@ietf.org>, "linux-nfs-owner" <linux-nfs-owner@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).
Tigran.
If the count is zero, a flush from the offset to the end of the file is done.
Note that he size returned by GETATTR gives you the end of the file so that, if it did not reflect the unstable writes, COMMIT wouldn't work right.
On Fri, Feb 22, 2019 at 6:25 PM Marc Eshel <eshel@us.ibm.com> wrote:
What is the file size returned by the NFS server for getattr after an unstable write to the NFS client that did the write or to other NFS clients.
As far as I know most file systems will always return the file size that includes the unstable writes.
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?
Marc.
_______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www.ietf.org/mailman/listinfo/nfsv4
On Mon, Feb 25, 2019 at 10:50:21AM -0500, David Noveck wrote:
For example, if you (or another client) read data written unstably, and there was been no restart you will see bytes past the eof as known by the metadata server.
Possibly worth noting that if there *is* a restart, all bets are off. And how do you know there hasn't been a restart? Or if you can figure that out (e.g. if you're using sessions), how do you know when clients have finished retransmitting unstable write data? I'd be curious what prompted the original question. --b.
Mkrtchyan, Tigran wrote:
From: "Dave Noveck" <davenoveck@gmail.com> To: "Marc Eshel" <eshel@us.ibm.com> Cc: "linux-nfs" <linux-nfs@vger.kernel.org>, "Ganesha-devel" <devel@lists.nfs-ganesha.org>, "NFSv4" <nfsv4@ietf.org>, "linux-nfs-owner" <linux-nfs-owner@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
participants (6)
-
David Noveck -
J. Bruce Fields -
Marc Eshel -
Mkrtchyan, Tigran -
Rick Macklem -
Thomas Haynes