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
- [nfsv4] Progressing RFC errata for RFC 5661 Magnus Westerlund
- Re: [nfsv4] Progressing RFC errata for RFC 5661 David Noveck
- Re: [nfsv4] Progressing RFC errata for RFC 5661 Trond Myklebust
- Re: [nfsv4] Progressing RFC errata for RFC 5661 David Noveck
- Re: [nfsv4] Progressing RFC errata for RFC 5661 Mkrtchyan, Tigran
- Re: [nfsv4] Progressing RFC errata for RFC 5661: … Magnus Westerlund
- Re: [nfsv4] Progressing RFC errata for RFC 5661: … Trond Myklebust
- Re: [nfsv4] Progressing RFC errata for RFC 5661 Rick Macklem
- Re: [nfsv4] Progressing RFC errata for RFC 5661 Mkrtchyan, Tigran
- Re: [nfsv4] Progressing RFC errata for RFC 5661 Rick Macklem
- Re: [nfsv4] Progressing RFC errata for RFC 5661 Trond Myklebust
- Re: [nfsv4] Progressing RFC errata for RFC 5661 Rick Macklem
- Re: [nfsv4] Progressing RFC errata for RFC 5661 Mkrtchyan, Tigran
- Re: [nfsv4] Progressing RFC errata for RFC 5661 David Noveck
- Re: [nfsv4] Progressing RFC errata for RFC 5661: … Magnus Westerlund
- Re: [nfsv4] Progressing RFC errata for RFC 5661 Trond Myklebust
- Re: [nfsv4] Progressing RFC errata for RFC 5661 Rick Macklem
- Re: [nfsv4] Progressing RFC errata for RFC 5661 Rick Macklem
- Re: [nfsv4] Progressing RFC errata for RFC 5661 Chuck Lever
- Re: [nfsv4] Progressing RFC errata for RFC 5661 Magnus Westerlund