From owner-freebsd-fs@freebsd.org Thu Apr 20 08:39: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 A2355D46136 for ; Thu, 20 Apr 2017 08:39:51 +0000 (UTC) (envelope-from dfr@rabson.org) Received: from mail-oi0-x234.google.com (mail-oi0-x234.google.com [IPv6:2607:f8b0:4003:c06::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6D9EE351 for ; Thu, 20 Apr 2017 08:39:51 +0000 (UTC) (envelope-from dfr@rabson.org) Received: by mail-oi0-x234.google.com with SMTP id j201so40670348oih.2 for ; Thu, 20 Apr 2017 01:39:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rabson-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=bDJH/JdDcIXRVxRdlgDdwlL7ztuo4VeMxWen8+T8hmE=; b=H7aGFPgpL/kyhrBo5WLsW2Sh+l4p3fcubXwyB2K0NBtUaA/rqE/SezjneORP8JeiAb XeUz63NYZiSawdz2NweqQK85ru7maNQOgAzFOIUdsDDAhH3Gz+qLUBOnVEYG+ERL/jjH ANC51F+aM5ZpTBDDX5gKy1sUw1pbOGLMpYJNN6ccme8K7LobzuD7kLW/Skt19iyAovht 7gGqoQt9ihaF8j7a6Elmn5Jc8n8VGWaRglVGzBi2eLxwyG1+41v2hKzkYDGN8ssA1miq d+Fpvb1yLlqgJ1Kei0X4Huue6UfAeA6hio9XqrG0uizr38UdnvxzFQH5VKWeoDbCKsuf Hatw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=bDJH/JdDcIXRVxRdlgDdwlL7ztuo4VeMxWen8+T8hmE=; b=T+qDGEcyeCeIO1+pcH29Re1KyRjFx3YnKpLcOsXmykW0nOifuE5k3GsgeN0rS3vJ0b P6HsFFjqPaDzlCNC120cqEM4wCNLiF9ZbsmCfiOWmj3NE+erldCRG/O83k5zgHgThlQS Ky43I4pNrZKqsAX3BUuviy+m9ie9pXbJ3oBTMyqKutfTw4ikgh+rikHS7ikPZlLVlcwG Vtt7ppQCBA4jDLqOxzvAK1ySi5AyFmhs527XFJk8fwglXO1mZccCQcR0kxq8BrfrWKV7 lPBzezwhd+EloUytNDOvXP6s6maqOvpuepJazBFIn+CSh2h/TWR+fP+Ec7s+jEzg/kQa QyVw== X-Gm-Message-State: AN3rC/7s/456jxuAwzBTt35lDLCIRL0nJFl8iWChS/1YuA4KCWw/cEfN VllB4WDe4zrH3IthpOQPeXQpUZupnA== X-Received: by 10.157.43.40 with SMTP id o37mr1326221otb.64.1492677590513; Thu, 20 Apr 2017 01:39:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.170.161 with HTTP; Thu, 20 Apr 2017 01:39:50 -0700 (PDT) In-Reply-To: References: From: Doug Rabson Date: Thu, 20 Apr 2017 09:39:50 +0100 Message-ID: Subject: Re: NFSv4 Linux client atime for exclusive create To: Rick Macklem Cc: "freebsd-fs@freebsd.org" , "jim@ks.uiuc.edu" Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.23 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 08:39:51 -0000 That was actually going to me my next suggestion, honest. Hopefully that fixes the problem, if not its a bug in the Linux client. On 19 April 2017 at 22:26, Rick Macklem wrote: > 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 > the > 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 > attribute > 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 > EXCLUSIVE4_1, i.e. the >mode which allows attribute setting during the > open, the client should use the value of >the supattr_exclcreat attribute > (see section 5.8.1.14 of rfc5661) to figure out what >attributes can be > set. In this case, supattr_exclcreat should not include atime which should > >force the client 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 > specified > 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 > Linux > box I have.) > > >It would be helpful to see a packet trace for this which should make it > clearer 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 > only work > correctly for server file systems that support extended attributes, but I > think 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" >