From owner-freebsd-fs@freebsd.org Wed Apr 19 15:06:55 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 6B4ECD45BD0 for ; Wed, 19 Apr 2017 15:06:55 +0000 (UTC) (envelope-from dfr@rabson.org) Received: from mail-yb0-x230.google.com (mail-yb0-x230.google.com [IPv6:2607:f8b0:4002:c09::230]) (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 2C79DB8 for ; Wed, 19 Apr 2017 15:06:55 +0000 (UTC) (envelope-from dfr@rabson.org) Received: by mail-yb0-x230.google.com with SMTP id 6so4903159ybq.2 for ; Wed, 19 Apr 2017 08:06:55 -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=4Nfuat7EX45NN6KSo3OCJuBl15dey5+aPZJizunUL1Q=; b=subGdY2PZqK5nt7KgiY1b0X9WdJXjv2w7AkTOhihaB2ayzMWyjF5Y4ASL+ZS084p/w pUuymDyBfQ0DTbJV8IeWQ+o48JLHRMY/vyEI7KYTuTSY3LXeSQZNCkn2JpRnX4XR6wA9 0+EX+IoG4fYFAtwCNcwoDPU1L5wh14MZ0RTuO2xbVSrz7uWjFOil6+zCsJM2mgN+Aztb ZvXojQcg99kOQiWqrxRG6GcAsXEG7FYVYFLNM/gbju8gnutSqFFPLmgNBk7OjVX7OlLK 3TJyx/XvngfocOtub/emvpXorrHEqTnJXvS3BJi/qgDOvS+feVSpKCRtzSuQJ2hId1hc 5GEg== 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=4Nfuat7EX45NN6KSo3OCJuBl15dey5+aPZJizunUL1Q=; b=oilOj1z8eGMRqlKYzYmgxmFKyt5Fs1p0U0/GrvQgYv6gZoJWvlywYJ9+DT3Ef0Ecdu txJC/ZDvg9XW5Ex26pHR4UotRbxfKZUOAAw1/35xDxT49oA/FH9Q807KXEaO9Xh5ZML7 WeSBjUrDCAOyXnURBr+aJAwcV14QBHTcZZIcWbx3iQeV0Z6HrfOfVlYjpESYoCZw/lMx Wx1SlTPmpvUt/zGIE6FLn23yF2pzRrVeH9WMK7ibkFym3w6pelqLLXTz+tER8d8OhTvx gCJFZjtAsqQbO3h59s0ApFj4/3yZUGPlqumQw12J5dcekwRZM0YsvE7hNnMRVcS9Ag20 v3kg== X-Gm-Message-State: AN3rC/7XjCjBDSjOnP0iNwscCSlI/V1QZgn5YS0m96HDo3tmTkBkmgDx m3KwyTa5t0pVaLCQlfkIUeiJh+XsIg== X-Received: by 10.157.21.17 with SMTP id u17mr1564011otf.43.1492614414238; Wed, 19 Apr 2017 08:06:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.170.161 with HTTP; Wed, 19 Apr 2017 08:06:53 -0700 (PDT) In-Reply-To: References: From: Doug Rabson Date: Wed, 19 Apr 2017 16:06:53 +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: Wed, 19 Apr 2017 15:06:55 -0000 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. It would be helpful to see a packet trace for this which should make it clearer what is happening here. On 14 April 2017 at 23:44, Rick Macklem wrote: > PR#218218 reports a problem where a file created by an NFSv4 mount (using > a recent > Linux kernel) results in a bogus atime for the newly created file. > > With the help of a packet trace from the problem reported I now know what > is > happening, but it turns out to be interesting and I am not sure I have a > good way > to fix it. > Here's the story... > - The Linux client does an Exclusive create. > - As was the norm for NFSv3, the FreeBSD server stores the create_verifier > for this > exclusive create in the atime field of the newly created file, so it can > be checked > for a retry of the exclusive create. > --> For NFSv3, it was required that a client follow an exclusive create > with a Setattr > of atime to fix the atime. > It turns out that, for NFSv4, the client is not required to do the Setattr > of atime. > (The FreeBSD client does do this and I think older Linux NFSv4 clients > did.) > --> This Linux client follows the exclusive create with a Setattr, but > only for the "mode" > attribute, leaving the create_verifier in the atime field. > > I can think of two ways to fix this: > 1 - Make the Setattr set atime whenever it sets any other attribute. > --> This would result in atime being set for changes to the file's > metadata, which is not > what atime is supposed to do. (Yuck!) > 2 - For NFSv4, store the create_verifier in an extended attribute instead > of atime. > --> I think this would work, but it would imply that only file > systems that support > extended attributes (UFS, ZFS, ??) could be exported to NFSv4 > clients. > > Anyone have other ideas w.r.t. how to fix this? > > Does restricting NFSv4 exports to file systems that support extended > attributes sound > reasonable? > > Thanks for any comments w.r.t. this, 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" >