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