From owner-freebsd-fs@freebsd.org Wed Apr 19 21:26:51 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 F15A1D460D4 for ; Wed, 19 Apr 2017 21:26:51 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from CAN01-QB1-obe.outbound.protection.outlook.com (mail-eopbgr660060.outbound.protection.outlook.com [40.107.66.60]) (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 9F71A175B for ; Wed, 19 Apr 2017 21:26:50 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from YTXPR01MB0189.CANPRD01.PROD.OUTLOOK.COM (10.165.218.133) by YTXPR01MB0189.CANPRD01.PROD.OUTLOOK.COM (10.165.218.133) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1034.10; Wed, 19 Apr 2017 21:26:49 +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; Wed, 19 Apr 2017 21:26:49 +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/6HM0kmAgABXYs2AABEAkQ== Date: Wed, 19 Apr 2017 21:26:48 +0000 Message-ID: References: , , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: rabson.org; dkim=none (message not signed) header.d=none;rabson.org; dmarc=none action=none header.from=uoguelph.ca; x-microsoft-exchange-diagnostics: 1; YTXPR01MB0189; 7:Zj4GkgAZyaVmLkoqJNmmw0AmLLTGDLJyZ3YK/9AcX/rdrbhM/+cm3P/Rhow8Vn0vJym9cqlSPKRNx2v8yWze+QIzHyTGO+2UV+yPvmhdKh9Ty+n4T/vbQNBQkOc/QZKBEoTJpMS2bUGrCNUDSMMhGkLA/unqqSRqYnNVaM3G+ox1PyMw8itYvbszJSc3Zj1iBHGEnAhMxQZZMZBnW7vdPV1AjtdUA3PEHUTQiq3ZyfTGsSsxtK+vMrpNiyXaV0iVpLnRLKyKuP1xDxDhgKK9sRW0h8H7EO97oNCv3H+ByBqHmew+dNvIKVxCmBbmRSaUQ52qmidgW3kXJ7Vc11uo9A== x-ms-office365-filtering-correlation-id: 0843d047-1617-484b-7296-08d4876ac9f6 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081); SRVR:YTXPR01MB0189; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(75325880899374); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(2401047)(8121501046)(5005006)(10201501046)(3002001)(93006095)(93001095)(6041248)(20161123564025)(20161123560025)(20161123562025)(201703131423075)(201702281529075)(201702281528075)(201703061421075)(20161123555025)(6072148); SRVR:YTXPR01MB0189; BCL:0; PCL:0; RULEID:; SRVR:YTXPR01MB0189; x-forefront-prvs: 028256169F x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39840400002)(39450400003)(39400400002)(39410400002)(39850400002)(51444003)(51914003)(377454003)(24454002)(76176999)(4326008)(6916009)(7696004)(54356999)(2900100001)(53546009)(25786009)(2950100002)(110136004)(229853002)(50986999)(33656002)(122556002)(3280700002)(189998001)(55016002)(77096006)(6246003)(38730400002)(102836003)(74482002)(81166006)(6506006)(2906002)(8676002)(3660700001)(8936002)(74316002)(6306002)(9686003)(5660300001)(305945005)(53936002)(6436002)(86362001)(54906002); DIR:OUT; SFP:1101; SCL:1; SRVR:YTXPR01MB0189; H:YTXPR01MB0189.CANPRD01.PROD.OUTLOOK.COM; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: uoguelph.ca X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Apr 2017 21:26:49.0016 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: be62a12b-2cad-49a1-a5fa-85f4f3156a7d X-MS-Exchange-Transport-CrossTenantHeadersStamped: YTXPR01MB0189 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: Wed, 19 Apr 2017 21:26:52 -0000 Hope you don't mind a quick top post related to my last email... I just looked in the new RFC for NFSv4.0 and it notes that the reply to Open should specify the attribute(s) used to store the create_verifier. Either this wasn't in the original RFC (3530) or I never read it, because t= he FreeBSD NFSv4.0 server doesn't do this. 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 behaviour. Also, the server doesn't set this bit in the EXCLUSIVE4_1 reply as RFC5661 says it should, so I need to patch this too. I suspect this will fix the problem without using an extended attribute to store the create_verifier. Having said that, I think that storing the create_verifier in an extended a= ttribute might be a good idea, for file systems that support them? Thanks for the comments that convinced me to take another look at the RFCs,= rick ________________________________________ From: owner-freebsd-fs@freebsd.org on behalf= of Rick Macklem Sent: Wednesday, April 19, 2017 4:29:08 PM To: Doug Rabson Cc: freebsd-fs@freebsd.org; jim@ks.uiuc.edu Subject: Re: NFSv4 Linux client atime for exclusive create 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 >force the cli= ent to update it separately. The packet trace Jim sent me was NFSv4.0 and, as such, used EXCLUSIVE4. (The Open was followed by a Setattr in a separate compound RPC that only sp= ecified the "mode" attribute. The client never seemed to specify an atime.) I haven't tried an NFSv4.1 mount yet, but I need to take a look at it. (I did succeed in reproducing the problem with an NFSV4.0 mount from a Linu= x box I have.) >It would be helpful to see a packet trace for this which should make it cl= earer what is >happening here. Jim did send me this off list. I now have a patch that stores the create_verifier in an extended attribute= and I think that should be fine? (It does imply that NFSv4.0 read/write mounts will onl= y work correctly for server file systems that support extended attributes, but I t= hink that is a reasonable restriction that can't be avoided?) [stuff snipped] rick _______________________________________________ freebsd-fs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-fs To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org"