Re: [nfsv4] Progressing RFC errata for RFC 5661

Rick Macklem <rmacklem@uoguelph.ca> Wed, 18 September 2019 16:39 UTC

Return-Path: <rmacklem@uoguelph.ca>
X-Original-To: nfsv4@ietfa.amsl.com
Delivered-To: nfsv4@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D05881200E6 for <nfsv4@ietfa.amsl.com>; Wed, 18 Sep 2019 09:39:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G-PBxilFqo1R for <nfsv4@ietfa.amsl.com>; Wed, 18 Sep 2019 09:39:23 -0700 (PDT)
Received: from CAN01-QB1-obe.outbound.protection.outlook.com (mail-eopbgr660054.outbound.protection.outlook.com [40.107.66.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 757B3120045 for <nfsv4@ietf.org>; Wed, 18 Sep 2019 09:39:23 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=k77KmcbwjOnvVsj5mDenh8UGXhEGKSram6qzfl196wflHV6S0N1F39uC+3dKev+Pb6N1RE4cwmwho8hlQq6BEv+jg9vqoncFM6TNs/ZECC459+cELnUjeyFtEYOQBBmCkk06xZHdcdihqyo4HulDPI5oMkuPzQpX3rfHWrNrf0ZK9SuxDtuMl5ogoX6rz/aOpOPFu/K2Qz6qFN9id2b4+wUF2zJ07/1sIEuO6RT5DVSNTLG3QouD/W/6Ngk95eEzNW+qsi72FajAf5/Q5P16qEk8HWfCe3qpQHULMmYwmUGJY8BtldBUY9NXmtsvrUjKGd4SBclHb6StOdE0eIqsFw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=xjbqkBW6onOikFysLQx9wYJ9v8UXpUSTdwZ6LjLxJoQ=; b=imKsF8lCNYGm76IlWkXyNRDOiutUCze0zr43WFhffC9tAw/39drfKzCisenSQFYCV4CuY2lqP/X6Rg+rmOLOoNgC7Cq7DkQ9vFnDf3oABsuz83UCx6OM7zKckkGX8+rIl/LIQdWIJcA4BfhDOhRYzbslopQJHOa1w8cT+gHGcUZYfnev//NTlQhkhKAizOTNe7Y7S97ojA0skV1FNr3Bahxae7uZB8f8T9DMc/15nv9c+HNYlCiKu/p93jts68l8eDYe7vhjzl5AnpG4N9yryJPcVD5I4ZGJwc3CtZpsaoI2blSbhaXng05hWZg3FEoSfF/x3FEWKm9i0PXoevIeeQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=uoguelph.ca; dmarc=pass action=none header.from=uoguelph.ca; dkim=pass header.d=uoguelph.ca; arc=none
Received: from YTXPR0101MB2189.CANPRD01.PROD.OUTLOOK.COM (52.132.39.22) by YTXPR0101MB1502.CANPRD01.PROD.OUTLOOK.COM (52.132.33.32) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2284.20; Wed, 18 Sep 2019 16:39:21 +0000
Received: from YTXPR0101MB2189.CANPRD01.PROD.OUTLOOK.COM ([fe80::5413:22e8:7013:d8b9]) by YTXPR0101MB2189.CANPRD01.PROD.OUTLOOK.COM ([fe80::5413:22e8:7013:d8b9%5]) with mapi id 15.20.2263.023; Wed, 18 Sep 2019 16:39:21 +0000
From: Rick Macklem <rmacklem@uoguelph.ca>
To: "Mkrtchyan, Tigran" <tigran.mkrtchyan@desy.de>
CC: Trond Myklebust <trondmy@gmail.com>, Dave Noveck <davenoveck@gmail.com>, Magnus Westerlund <magnus.westerlund@ericsson.com>, NFSv4 <nfsv4@ietf.org>
Thread-Topic: [nfsv4] Progressing RFC errata for RFC 5661
Thread-Index: AQHVbM0EuGFC68ZdA0WMehAxtQCJUqcwwJsEofkpcSPeB7DymQ==
Date: Wed, 18 Sep 2019 16:39:21 +0000
Message-ID: <YTXPR0101MB21892F5E56B089AC6A255506DD8E0@YTXPR0101MB2189.CANPRD01.PROD.OUTLOOK.COM>
References: <DB7PR07MB5736124B2F507DA20F317BC195B30@DB7PR07MB5736.eurprd07.prod.outlook.com> <CADaq8jd4u-Lwvy_Csu2jqrcGFZ_tLOeSkqKwUW0eivuc=trsBg@mail.gmail.com> <CAABAsM5TDGx0qiMv+Ln4WLOKjuQiTFKr6HD6d9zqD3NfjpvoFg@mail.gmail.com> <YTXPR0101MB2189B0CB69FA090BD1D54F92DD8E0@YTXPR0101MB2189.CANPRD01.PROD.OUTLOOK.COM>, <1941956044.30576385.1568804777656.JavaMail.zimbra@desy.de>
In-Reply-To: <1941956044.30576385.1568804777656.JavaMail.zimbra@desy.de>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=rmacklem@uoguelph.ca;
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 0b6bc425-8755-4150-d6e5-08d73c56c229
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600167)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:YTXPR0101MB1502;
x-ms-traffictypediagnostic: YTXPR0101MB1502:
x-ms-exchange-purlcount: 1
x-microsoft-antispam-prvs: <YTXPR0101MB150291496C92502ECBFA06C0DD8E0@YTXPR0101MB1502.CANPRD01.PROD.OUTLOOK.COM>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 01644DCF4A
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(39860400002)(396003)(136003)(376002)(366004)(189003)(199004)(8936002)(71190400001)(71200400001)(6916009)(81156014)(81166006)(86362001)(54906003)(8676002)(14444005)(486006)(14454004)(305945005)(478600001)(256004)(74316002)(76116006)(476003)(11346002)(786003)(46003)(55016002)(102836004)(76176011)(99286004)(33656002)(6436002)(64756008)(5660300002)(66556008)(4326008)(6246003)(25786009)(229853002)(66946007)(446003)(66476007)(6506007)(316002)(7696005)(66446008)(52536014)(2906002)(186003)(6306002)(9686003); DIR:OUT; SFP:1101; SCL:1; SRVR:YTXPR0101MB1502; H:YTXPR0101MB2189.CANPRD01.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None (protection.outlook.com: uoguelph.ca does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: ttpdzn93mT74Cjoa/7ztlsYj09+0yxEMlOjDNQ1jZBBbQAjHX2d5bvZN+hxuVwlHHOVVWEH0zPG0DXtwU3JSl7YhG4vZLkVxqobakPGLTUK+iWSILJbDoZVPpQZkvVcwGYq0hF2mw6B2KLzN6TGsTKcVDLdhgf9QGtjapRWg6H0ACE8Cnf9RazISl5h+sUW5HK7SyOA+Ow3vGZE1Bh4T200pQbBlVA5bcWhJgayHXjsWhApyzAVBT/a883naieuw0z2QDNh6wPXHCLbHv4kIQmdauanyH9ZdhrHVl5S2xq+uOf/CdBzn6GibzL81IGK7o2KjQIJFvlGuMIkNj/6VXMZl11kFE+jhiQNEQIfeaiVHHcRwxw2UYBTg/iDgFXR8dWe+fZHSw0lSkHNyKHNINF5xS4RhBxYpm7WN7vs6ibI=
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: uoguelph.ca
X-MS-Exchange-CrossTenant-Network-Message-Id: 0b6bc425-8755-4150-d6e5-08d73c56c229
X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Sep 2019 16:39:21.8100 (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-CrossTenant-userprincipalname: j5p/Gb8Nb35ra+BZrgN6a5BL7MKcyZU7Wtb+OKrh6U+3Kr3IFOeLMyvrEA/LfoLaE2Dt1zhHZc0w/Gg1bsJbUQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: YTXPR0101MB1502
Archived-At: <https://mailarchive.ietf.org/arch/msg/nfsv4/M6h-VbGeji5zPho30UhnSNghi2E>
Subject: Re: [nfsv4] Progressing RFC errata for RFC 5661
X-BeenThere: nfsv4@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NFSv4 Working Group <nfsv4.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/nfsv4>, <mailto:nfsv4-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/nfsv4/>
List-Post: <mailto:nfsv4@ietf.org>
List-Help: <mailto:nfsv4-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/nfsv4>, <mailto:nfsv4-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 18 Sep 2019 16:39:26 -0000

Mkrtchyan, Tigran wrote:
[stuff snipped]
>Hi Rick,
>
>here is the public link to errata
>
>https://www.rfc-editor.org/errata/eid2751
>
>Tigran.
Thanks Tigran.

Ok, so now that I've read it I have to admit I think it is rewriting the RFC
to conform with what the Linux client does.

I think this para. from Sec. 13.10 of RFC-5661 is clear:
   The NFSv4.1 protocol only provides close-to-open file data cache
   semantics; meaning that when the file is closed, all modified data is
   written to the server.  When a subsequent OPEN of the file is done,
   the change attribute is inspected for a difference from a cached
   value for the change attribute.  For the case above, this means that
   a LAYOUTCOMMIT will be done at close (along with the data WRITEs) and
   will update the file's size and change attribute.  Access from
   another client after that point will result in the appropriate size
   being returned.

It states "will be done". It doesn't say anything about UNSTABLE4 vs FILE_SYNC4.
(I think most POSIX-like clients would consider the fsync(2) syscall to require
 the same treatment as "close" above, but that is a POSIX-specific client issue.)
I can see the argument that, since there is no "must" in the statement, that a
client can choose not to do this, but that would also imply that the client will
need to live with the consequences of it.

I think the second sentence of the first para. of the errata is bogus:
For file layouts, WRITEs to a Data Server that return a stable_how4 value of 
FILE_SYNC4 guarantee that data and file system metadata are on stable 
storage.  This means that a LAYOUTCOMMIT is not needed in order to make the 
data and metadata visible to the metadata server and other clients.

Why?
The FILE_SYNC4 was returned by the DS. This would imply the DS
has committed data and metadata to stable storage on the DS.
However, I am not aware of anything in RFC-5661 that would imply that
the Size, Time_Modify and Change attributes or anything else must have
been updated or in stable storage on the MDS at this time.

If a server does not require LayoutCommit operations for correct behaviour
then it can simply reply NFS4ERR_NOTSUPP (as I believe the Netapp filer
does) and the client then no longer needs to do them.

If there is somewhere in RFC-5661 that it is stated that LayoutCommits are
not required when the DS replies FILE_SYNC4, then I missed it and there
is a problem with RFC-5661 that needs to be addressed.

Otherwise, sorry, but it seems that the bug is in the Linux client implementation
and not RFC-5661.

Is there a File Layout pNFS server implementation where the DSs return
FILE_SYNC4 that will break if the client does a LayoutCommit for this case?
(If so, then something may need to be done.)

rick