Re: [nfsv4] file size and getattr

["Mkrtchyan, Tigran" <tigran.mkrtchyan@desy.de>]

----- 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