From owner-freebsd-fs@freebsd.org Thu Apr 20 23:46:03 2017 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7D7AED48A2F for ; Thu, 20 Apr 2017 23:46:03 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from CAN01-QB1-obe.outbound.protection.outlook.com (mail-eopbgr660049.outbound.protection.outlook.com [40.107.66.49]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "Microsoft IT SSL SHA2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 26F4B3E5 for ; Thu, 20 Apr 2017 23:46:02 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from YTXPR01MB0189.CANPRD01.PROD.OUTLOOK.COM (10.165.218.133) by YTXPR01MB0190.CANPRD01.PROD.OUTLOOK.COM (10.165.218.134) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1034.10; Thu, 20 Apr 2017 23:46:00 +0000 Received: from YTXPR01MB0189.CANPRD01.PROD.OUTLOOK.COM ([10.165.218.133]) by YTXPR01MB0189.CANPRD01.PROD.OUTLOOK.COM ([10.165.218.133]) with mapi id 15.01.1034.015; Thu, 20 Apr 2017 23:46:00 +0000 From: Rick Macklem To: Doug Rabson CC: "freebsd-fs@freebsd.org" , "jim@ks.uiuc.edu" Subject: Re: NFSv4 Linux client atime for exclusive create Thread-Topic: NFSv4 Linux client atime for exclusive create Thread-Index: AQHStW9Xwd3iU1MkQkKHy7u7vlbe/6HM0kmAgABXYs2AABEAkYAAvc8AgAD5RDY= Date: Thu, 20 Apr 2017 23:45:59 +0000 Message-ID: References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: freebsd.org; dkim=none (message not signed) header.d=none;freebsd.org; dmarc=none action=none header.from=uoguelph.ca; x-microsoft-exchange-diagnostics: 1; YTXPR01MB0190; 7:s6Y5ghzPk/lif65Di8LduNptkINkcE874G1FbagMGcacQF/id2W/TYqTCLJwXMcNRuoEaNo/QA6GN8gQMOkSbzz67LIm9Cy8rZ3t7Z2/n/mymIRb7REirWSK95EkAfa+Su9za32sZw9+yT9/8CbGoz12zhbaiuqg+SUIiIKXKWEeqXxqvODmY+b2H5j8Oj1tZPHVwpoW/DLKJ88dJzyUOkTLrt4iPL6DmXkUIn7AZb0L7t3aK7xWDNW+4ibW9OVkJfJkHHfTyuLD7rCTCRMmKrO+FpggwSinbiANyO6Uv2Rr/KdxdHJULBt2Jfcey7kCpAsAR2JsJbSJ8N6AH4wtNQ== x-ms-office365-filtering-correlation-id: 4a48b80c-6d0c-426e-53fc-08d4884765fc x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081); SRVR:YTXPR01MB0190; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(102415395)(6040450)(2401047)(5005006)(8121501046)(10201501046)(3002001)(93006095)(93001095)(6041248)(20161123560025)(201703131423075)(201702281529075)(201702281528075)(201703061421075)(20161123555025)(20161123564025)(20161123562025)(6072148); SRVR:YTXPR01MB0190; BCL:0; PCL:0; RULEID:; SRVR:YTXPR01MB0190; x-forefront-prvs: 02830F0362 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39400400002)(39840400002)(39850400002)(39450400003)(39410400002)(24454002)(93886004)(5890100001)(6246003)(305945005)(5660300001)(229853002)(8676002)(99936001)(122556002)(74316002)(77096006)(54356999)(9686003)(2900100001)(110136004)(4326008)(102836003)(76176999)(6506006)(38730400002)(25786009)(50986999)(3280700002)(3660700001)(6436002)(7696004)(189998001)(2906002)(54906002)(86362001)(55016002)(74482002)(81166006)(53936002)(33656002)(6916009)(2950100002)(8936002); DIR:OUT; SFP:1101; SCL:1; SRVR:YTXPR01MB0190; H:YTXPR01MB0189.CANPRD01.PROD.OUTLOOK.COM; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/mixed; boundary="_002_YTXPR01MB0189AFA97A8BFE756E6EFE4DDD1B0YTXPR01MB0189CANP_" MIME-Version: 1.0 X-OriginatorOrg: uoguelph.ca X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Apr 2017 23:45:59.9632 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: be62a12b-2cad-49a1-a5fa-85f4f3156a7d X-MS-Exchange-Transport-CrossTenantHeadersStamped: YTXPR01MB0190 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Apr 2017 23:46:03 -0000 --_002_YTXPR01MB0189AFA97A8BFE756E6EFE4DDD1B0YTXPR01MB0189CANP_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Doug Rabson wrote: >That was actually going to me my next suggestion, honest. Hopefully that f= ixes the >problem, if not its a bug in the Linux client. Yep, the attached patch fixed the problem. I wrote: >I'll come up with a patch that sets the atime bit in the EXCLUSIVE4 Open >reply and see if that changes the Linux client. The attached patch sets the TIMEACCESS bit in the reply for both NFSv4.0 an= d NFSv4.1 and fixes the problem for both cases for a quick test with the Linux client= . (With this bit set in the reply, Linux sets TIMEACCESSSET in the Setattr.) Doug Rabson wrote: >Is the client using EXCLUSIVE4 or EXCLUSIVE4_1 for the open? If its EXCLUS= IVE4_1, i.e. the >mode which allows attribute setting during the open, the = client should use the value of >the supattr_exclcreat attribute (see sectio= n 5.8.1.14 of rfc5661) to figure out what >attributes can be set. In this c= ase, supattr_exclcreat should not include atime which should=20 The FreeBSD NFSv4.1 server does exclude atime from the supattr_exclcreat b= itset and it checks for it set and returns the correct error. However, like NFSv4.0, the code didn't set the TIMEACCESS attribute bit in = the EXCLUSIVE4_1 reply. (The attached little patch fixes this for both NFSv4.0 = and NFSV4.1.) Thanks everyone for your help. I am thinking that storing the create_verifier in an extended attribute for= file systems that support extended attributes is a good idea, since it will allo= w NFSv4.1 clients to avoid following the Open/Exclusive4_1 with a Setattr RPC. Anyone else have an opinion w.r.t. this? (I'll leave this for a future commit, depending on what others think of the= idea.) I will probably commit the attached patch soon, rick ps: Jim, I don't think there is any point in testing the other patch, altho= ugh I suspect it would fix the problem. You could test this one, if you can easily = do it. pss: My only excuse for never doing this is that it is one sentence in an R= FC of several hundred pages;-) --_002_YTXPR01MB0189AFA97A8BFE756E6EFE4DDD1B0YTXPR01MB0189CANP_ Content-Type: application/octet-stream; name="atime2.patch" Content-Description: atime2.patch Content-Disposition: attachment; filename="atime2.patch"; size=476; creation-date="Thu, 20 Apr 2017 23:41:08 GMT"; modification-date="Thu, 20 Apr 2017 23:41:08 GMT" Content-Transfer-Encoding: base64 LS0tIGZzL25mc3NlcnZlci9uZnNfbmZzZHBvcnQuYy5zYXYJMjAxNy0wNC0yMCAxMDo0Nzo1MS40 NDY5ODMwMDAgLTA0MDAKKysrIGZzL25mc3NlcnZlci9uZnNfbmZzZHBvcnQuYwkyMDE3LTA0LTIw IDExOjAzOjUzLjMzOTIyODAwMCAtMDQwMApAQCAtMTQzNiw3ICsxNDM2LDkgQEAgbmZzdm5vX29w ZW4oc3RydWN0IG5mc3J2X2Rlc2NyaXB0ICpuZCwgcwogCQkJCQkJdnB1dChuZHAtPm5pX3ZwKTsK IAkJCQkJCW5kcC0+bmlfdnAgPSBOVUxMOwogCQkJCQkJbmQtPm5kX3JlcHN0YXQgPSBORlNFUlJf Tk9UU1VQUDsKLQkJCQkJfQorCQkJCQl9IGVsc2UKKwkJCQkJCU5GU1NFVEJJVF9BVFRSQklUKGF0 dHJiaXRwLAorCQkJCQkJICAgIE5GU0FUVFJCSVRfVElNRUFDQ0VTUyk7CiAJCQkJfSBlbHNlIHsK IAkJCQkJbmZzcnZfZml4YXR0cihuZCwgbmRwLT5uaV92cCwgbnZhcCwKIAkJCQkJICAgIGFjbHAs IHAsIGF0dHJiaXRwLCBleHApOwo= --_002_YTXPR01MB0189AFA97A8BFE756E6EFE4DDD1B0YTXPR01MB0189CANP_--