From:   Rick Macklem <rmacklem@uoguelph.ca>
To:     "Mkrtchyan, Tigran" <tigran.mkrtchyan@desy.de>,
        Dave Noveck <davenoveck@gmail.com>
CC:     Marc Eshel <eshel@us.ibm.com>,
        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>
Subject: Re: [nfsv4] file size and getattr
Thread-Topic: [nfsv4] file size and getattr
Thread-Index: xB45BipLgBZpsCd+0L6G4OWR1hcJRu0o7KH9
Date:   Tue, 26 Feb 2019 02:54:08 +0000
Message-ID: <QB1PR01MB3537C4C84605F9C26050DDA8DD7B0@QB1PR01MB3537.CANPRD01.PROD.OUTLOOK.COM>
References: <155049372736.14318.3390584694682770373.idtracker@ietfa.amsl.com>
 <CADaq8je2Ap4oAZAPOguaWctUs8dQ=Q9g=TO39EOiJW5EJSFTGg@mail.gmail.com>
 <OFE5A6CD32.4DC48078-ON882583A9.007FB4BC-882583A9.0080ACAC@notes.na.collabserv.com>
 <CADaq8jfT=nxmVPz4mDRFAaOx36uxWqKbxitqS-YH3GCOs4CsrQ@mail.gmail.com>,<741516773.7109032.1551084577150.JavaMail.zimbra@desy.de>
In-Reply-To: <741516773.7109032.1551084577150.JavaMail.zimbra@desy.de>
Accept-Language: en-US
Content-Language: en-US
received-spf: None (protection.outlook.com: uoguelph.ca does not designate
 permitted sender hosts)
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8BIT
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 6b6dcb9f-0a21-4a19-089d-08d69b95adc8
X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Feb 2019 02:54:08.6113
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: be62a12b-2cad-49a1-a5fa-85f4f3156a7d
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-Transport-CrossTenantHeadersStamped: QB1PR01MB3508
Sender: linux-nfs-owner@vger.kernel.org
Precedence: bulk
List-ID: <linux-nfs.vger.kernel.org>
X-Mailing-List: linux-nfs@vger.kernel.org

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