From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 64091CE7A8B for ; Sat, 23 Sep 2023 10:50:53 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229903AbjIWKqt (ORCPT ); Sat, 23 Sep 2023 06:46:49 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43816 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229848AbjIWKqs (ORCPT ); Sat, 23 Sep 2023 06:46:48 -0400 Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 078A6194; Sat, 23 Sep 2023 03:46:43 -0700 (PDT) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 12512C433C7; Sat, 23 Sep 2023 10:46:40 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1695466002; bh=Fgx42TGJn4SqLTc7ScZeuLRx1lxOlKBCJxp1VQ2ncDI=; h=Subject:From:To:Cc:Date:In-Reply-To:References:From; b=n8wR7GtcQlt+Y6uw/B6vII1a/XDIbqd0UdQTMcjBUz2g0/VsKjSwI8inZLq+sX8Js ULXksUYHaRuq9sM6QZPqSeyfnv0+rUOLLpb3XQKnjBMkWnvk4waz4wbOzT3zAXsVM6 EpduFXU6dZSt62GUp0tVVT0Q6bNAwKte47YP3GE+uRNnbkovxlOv4VhAPaUGLhlguS EZRee95FVgikS3rPUEhLMdHe8BOnKlzpRssERL4H9tWHU26Xr4cvy0hjbGQx1rmsFJ K6rLlE4tGLEMaoshPe4L/ksS9Qpa6YtO2ji7zAGAC7LoVMMHIHcPyb+gMN/+Qn87oS HVwwCUdISOQAw== Message-ID: <5e3b8a365160344f1188ff13afb0a26103121f99.camel@kernel.org> Subject: Re: [PATCH v8 0/5] fs: multigrain timestamps for XFS's change_cookie From: Jeff Layton To: Amir Goldstein Cc: Alexander Viro , Christian Brauner , Chuck Lever , Neil Brown , Olga Kornievskaia , Dai Ngo , Tom Talpey , Chandan Babu R , "Darrick J. Wong" , Dave Chinner , Jan Kara , Linus Torvalds , Kent Overstreet , linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, linux-nfs@vger.kernel.org, linux-xfs@vger.kernel.org Date: Sat, 23 Sep 2023 06:46:39 -0400 In-Reply-To: References: <20230922-ctime-v8-0-45f0c236ede1@kernel.org> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.48.4 (3.48.4-1.fc38) MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: linux-xfs@vger.kernel.org On Sat, 2023-09-23 at 10:15 +0300, Amir Goldstein wrote: > On Fri, Sep 22, 2023 at 8:15=E2=80=AFPM Jeff Layton = wrote: > >=20 > > My initial goal was to implement multigrain timestamps on most major > > filesystems, so we could present them to userland, and use them for > > NFSv3, etc. > >=20 > > With the current implementation however, we can't guarantee that a file > > with a coarse grained timestamp modified after one with a fine grained > > timestamp will always appear to have a later value. This could confuse > > some programs like make, rsync, find, etc. that depend on strict > > ordering requirements for timestamps. > >=20 > > The goal of this version is more modest: fix XFS' change attribute. > > XFS's change attribute is bumped on atime updates in addition to other > > deliberate changes. This makes it unsuitable for export via nfsd. > >=20 > > Jan Kara suggested keeping this functionality internal-only for now and > > plumbing the fine grained timestamps through getattr [1]. This set take= s > > a slightly different approach and has XFS use the fine-grained attr to > > fake up STATX_CHANGE_COOKIE in its getattr routine itself. > >=20 > > While we keep fine-grained timestamps in struct inode, when presenting > > the timestamps via getattr, we truncate them at a granularity of number > > of ns per jiffy, >=20 > That's not good, because user explicitly set granular mtime would be > truncated too and booting with different kernels (HZ) would change > the observed timestamps of files. >=20 Thinking about this some more, I think the first problem is easily addressable: The ctime isn't explicitly settable and with this set, we're already not truncating the atime. We haven't used any of the extra bits in the mtime yet, so we could just carve out a flag in there that says "this mtime was explicitly set and shouldn't be truncated before presentation". The second problem (booting to older kernel) is a bit tougher to deal with however. I'll have to think about that one a bit more. --=20 Jeff Layton