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 kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 911D4C00142 for ; Tue, 31 Oct 2023 23:47:27 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id BBA438D0029; Tue, 31 Oct 2023 19:47:26 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id B69948D0003; Tue, 31 Oct 2023 19:47:26 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A31718D0029; Tue, 31 Oct 2023 19:47:26 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 9479D8D0003 for ; Tue, 31 Oct 2023 19:47:26 -0400 (EDT) Received: from smtpin24.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 6046A160BDB for ; Tue, 31 Oct 2023 23:47:26 +0000 (UTC) X-FDA: 81407395692.24.E326C09 Received: from mail-pf1-f170.google.com (mail-pf1-f170.google.com [209.85.210.170]) by imf21.hostedemail.com (Postfix) with ESMTP id 5D5FF1C001F for ; Tue, 31 Oct 2023 23:47:24 +0000 (UTC) Authentication-Results: imf21.hostedemail.com; dkim=pass header.d=fromorbit-com.20230601.gappssmtp.com header.s=20230601 header.b=xBzC3BVB; dmarc=pass (policy=quarantine) header.from=fromorbit.com; spf=pass (imf21.hostedemail.com: domain of david@fromorbit.com designates 209.85.210.170 as permitted sender) smtp.mailfrom=david@fromorbit.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1698796044; a=rsa-sha256; cv=none; b=kb0zONCzid/s/K+1J4xKzZte2voMZbN4K7SsNfs1ihbYb0C/Tr3qd69bQC6O6PSqLSHpGz fRQA4evNXa5us1Tze7o3SYKo+pQRYP1y4SB87hauRgl0FDotsG9j84x3xy0Og0u2GGi8KP k4dfrIloM5jfEE4Eot3fhibcPmkYKoY= ARC-Authentication-Results: i=1; imf21.hostedemail.com; dkim=pass header.d=fromorbit-com.20230601.gappssmtp.com header.s=20230601 header.b=xBzC3BVB; dmarc=pass (policy=quarantine) header.from=fromorbit.com; spf=pass (imf21.hostedemail.com: domain of david@fromorbit.com designates 209.85.210.170 as permitted sender) smtp.mailfrom=david@fromorbit.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1698796044; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=LL8tYW50Kf6aNPlxTNrj3Zv6ugWw5JL8Pwwf5RV47qU=; b=oXElaboSzTwyLjMmFmpdHmeDigYcbmtByMfLWYF7AYf7blogRV82wm2qolgbwpty/jkcuM uAp5yFdFjzaCnYuvhMBhEvZ8iw4KeWbpFINIU2PJ2FSBPEs5hKTYCbZybM2eP2OaW5JoLp fxkZx0Dr9m/bFxXGzD8LNFtvanv0nfc= Received: by mail-pf1-f170.google.com with SMTP id d2e1a72fcca58-6b1ef786b7fso6242640b3a.3 for ; Tue, 31 Oct 2023 16:47:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fromorbit-com.20230601.gappssmtp.com; s=20230601; t=1698796043; x=1699400843; darn=kvack.org; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:from:to :cc:subject:date:message-id:reply-to; bh=LL8tYW50Kf6aNPlxTNrj3Zv6ugWw5JL8Pwwf5RV47qU=; b=xBzC3BVBrdwYPbVgoeQOKVF33iYCoZIe1g175fH/8oLeTTQiTvHNo5ZBYlX+DDd9n/ +b3XZBJSDK6zmODhfz6SK+mHc7fIBvw5f1PSiE35lI3um6Ds5mS1pA4nCkLwg/+hD1+A +IlQEqj/UD3LQrYRV/qXckp3qujNE5LQCC8Zv89ciagV5d3WG7Nhe/5zNBaoME1eWoAy nSemBLQWU7dWqXoxKLzFq7UKGuVz0Nr7hrQvaSmnZ5onnXjWQnWcQzflnzQQFyYHKy1Q +rX8LotBSBRS7Oz29LYJAOat2nDtPX5WyKiVI4dVLQzmDZCeLdnIlb45FuTNHJ9cZhft 70+w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1698796043; x=1699400843; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=LL8tYW50Kf6aNPlxTNrj3Zv6ugWw5JL8Pwwf5RV47qU=; b=hJEdXGlE/tcqqgV4A8vLd5+QZN7SdeIhOQiK5AzrJdJe8cxRStigilW/KgDOZQiOSI qX62X05t2IDLGDcFktYb3TxOipV1qbEk2cNLMbPqAQtuNr9li3wqpMHieuTh9QEvE8rv KqK82131qfYNd34Bokma0nWJhX5/YbxUItoV/y4d4xzPooqRqvkeQYvsliTVu5R38exP Aj8SguCFdvFpR3mKurLwu1tSNwdUJeBqASmfq0zjW3jg3AtU2nM2+Ix1nmRznwG7lNSu 7YggAsMJdYi1vqHCrvl3avEmC5p8tZ13TBBnjX4rgaq0CXviD1FYLudygdW5Dwf55Pzx 2aeQ== X-Gm-Message-State: AOJu0YxmUgB/uuUTk5tQoLBd1aOrt9ugzvPEoNgnTSbEZuJ4zZdUlzSg YCIeVjynVJ2fpG+ATU+wNNPR7g== X-Google-Smtp-Source: AGHT+IG0Ny9Z2Xdu0995f1HPr5AykcrHAfoUPqFEd6JDhsfJl5wm1cwFJ4giSGoazkZucS2Diz+3Eg== X-Received: by 2002:a05:6a21:78a4:b0:16b:846a:11b1 with SMTP id bf36-20020a056a2178a400b0016b846a11b1mr17455016pzc.32.1698796043058; Tue, 31 Oct 2023 16:47:23 -0700 (PDT) Received: from dread.disaster.area (pa49-180-20-59.pa.nsw.optusnet.com.au. [49.180.20.59]) by smtp.gmail.com with ESMTPSA id c25-20020a637259000000b0058a9621f583sm1537767pgn.44.2023.10.31.16.47.22 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 31 Oct 2023 16:47:22 -0700 (PDT) Received: from dave by dread.disaster.area with local (Exim 4.96) (envelope-from ) id 1qxyS7-006YqP-22; Wed, 01 Nov 2023 10:47:19 +1100 Date: Wed, 1 Nov 2023 10:47:19 +1100 From: Dave Chinner To: "Darrick J. Wong" Cc: Jeff Layton , Amir Goldstein , Linus Torvalds , Kent Overstreet , Christian Brauner , Alexander Viro , John Stultz , Thomas Gleixner , Stephen Boyd , Chandan Babu R , Theodore Ts'o , Andreas Dilger , Chris Mason , Josef Bacik , David Sterba , Hugh Dickins , Andrew Morton , Jan Kara , David Howells , linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, linux-xfs@vger.kernel.org, linux-ext4@vger.kernel.org, linux-btrfs@vger.kernel.org, linux-mm@kvack.org, linux-nfs@vger.kernel.org Subject: Re: [PATCH RFC 2/9] timekeeping: new interfaces for multigrain timestamp handing Message-ID: References: <2ef9ac6180e47bc9cc8edef20648a000367c4ed2.camel@kernel.org> <6df5ea54463526a3d898ed2bd8a005166caa9381.camel@kernel.org> <3d6a4c21626e6bbb86761a6d39e0fafaf30a4a4d.camel@kernel.org> <20231031230242.GC1205143@frogsfrogsfrogs> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20231031230242.GC1205143@frogsfrogsfrogs> X-Rspam-User: X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: 5D5FF1C001F X-Stat-Signature: ajya1nwfbk11xyoy5pod1w63ncredq1a X-HE-Tag: 1698796044-97019 X-HE-Meta: U2FsdGVkX1/0KEuGWC/IsTSYt1g273YPSH0btO59CXOglWK9T+FrNpuMcOHH6RqmCrjen46KZKgK8TOOs3FHPRL1d9dQKh0m/QPzTmo8uoZ5mnyPcX1EHBJxYLhOaE1zPqrr5z+GGRwOT1YecUHQBoo1xk2xjGl3AuhtQeAa7jElPpHC77WUFe0rZNn4IeYBBWTsbCR/bHGasLX9aP2U07IKwk7bJao6Ztj53nCnuvdZ8Cre68fkV06xlVWAxCO2VqAY1LDEo9enJLe01y4CQntWl4HxiiCiupW/lQXeRp2c/Hfm1RuEZ+lAKXQTccYHW6wmSShOPsZJDoGUD6Nyi+3vhC390wEPAggt58GlFpdwzlT3c7emr9Tyl9Xi5plmTrXtllJ/qkPGG1F5VsONbzsNajFEL6hhzxQnbrVDqtp0PuX8mhqywMeSJuF+MGyW47KEtWlqYmES4XXXMkW1izVzYkt4Cc3XAJ6JVKe+sGzG5SB4Vf+el8QmsxizfNPNbTiF/YNUQ3J4j5XCuCmSKZTTZFBILLhIJv11TvdNU3kRxPNWcCmKQn/xnMZdoIV6Unbo33qI4tleukc36Rk9wM897Q3mSUiMXpouN/y0NtGieoSfDrPEBRbM/o5tNdSicu4YDs6LAEGJjWvlxILU5VwHwYIeqkFzpmK+AbRvoDvOXdND3iMb3NQnS4aSQlxGFJ75stjLRtPvz3koWBuGynE+JQUpcN6iNkHs8SeMSRL6DZSS+ZxFqrv8aiR9SuX6z+AsByI94KFKynyGU6sztqYtKD9HOFEVmSjsZ5xw9JvZFxlm4w0uISOtnLB3UQtgHu6kzYTmxKF/ONtjWIgVFUthr+qbQLlBeTaljkSTUn8q61brC8h4tRh6sgnmcm+lvuDWcYu08/CakTYDtD9N68DmIF59hiceGW8ThbLzsWVqXW84TFR1hfGnxSFwUKNKdwuFhiGL8x38xe2+1qw 0V+MR3oM gsr+b5Z11tjbSzQ6P/KkKqPDbsJaVMw13UQy1tFe5CKcTPD1YLeqZ6URiEfLOj/8J1dLbGIJB14K/5KNoeZY953tPSz4DCt8FldXqWsdtMP/A6fHeeLr50Ve7SM6Q1ew1B+02E6koB1SqkC7XC0fGwMr59475AGcP+kUxvaeyOzTioC1PiVXQN27B//c3mPzTscFhq+5XoW6Ti6Wy/pH1MeO2ayHIPvmioeGMCccgmK0da8MnR1GBCXSJapEwYBWM5Cs9p++cGT9q66cI1Sx/dneFFkZfpRejlZguomaSb/3bGXTMWvHxaSrRmOxFYRjGSq/Zg6aKKg1hKWYw9efS9O060gMMw7botpmIRv1hA0UFAKY/dAwIbQqcE+CVCkj+M6DgNoRFNNgHpK0IsXl0czBhhvB+e8R02RKYQH/8lnndOTCAiuZh0gidR2nch+vOtWxj X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On Tue, Oct 31, 2023 at 04:02:42PM -0700, Darrick J. Wong wrote: > On Wed, Nov 01, 2023 at 08:57:09AM +1100, Dave Chinner wrote: > > On Tue, Oct 31, 2023 at 07:29:18AM -0400, Jeff Layton wrote: > > > On Tue, 2023-10-31 at 09:03 +0200, Amir Goldstein wrote: > > > > On Tue, Oct 31, 2023 at 3:42 AM Dave Chinner wrote: > > e.g. the current code flow for an atime update is: > > > > touch_atime() > > atime_needs_update() > > > > inode_update_time(S_ATIME) > > ->update_time(S_ATIME) > > > > > > I'd much prefer this to be: > > > > touch_atime() > > if (->update_time(S_ATIME)) { > > ->update_time(S_ATIME) > > xfs_inode_update_time(S_ATIME) > > if (atime_needs_update()) > > > > } else { > > /* run the existing code */ > > } > > > > Similarly we'd turn file_modified()/file_update_time() inside out, > > and this then allows the filesystem to add custom timestamp update > > checks alongside the VFS timestamp update checks. > > > > It would also enable us to untangle the mess that is lazytime, where > > we have to implement ->update_time to catch lazytime updates and > > punt them back to generic_update_time(), which then has to check for > > lazytime again to determine how to dirty and queue the inode. > > Of course, generic_update_time() also does timespec_equal checks on > > timestamps to determine if times should be updated, and so we'd > > probably need overrides on that, too. > > Hmm. So would the VFS update the incore timestamps of struct inode in > whatever manner it wants? That's kind of what I want to avoid - i want the filesystem to direct the VFS as to the type of checks and modifications it can make. e.g. the timestamp comparisons and actions taken need to be different for a timestamp-with-integrated-change-counter setup. It doesn't fold neatly into inode_needs_update_time() - it becomes a branchy, unreadable mess trying to handle all the different situations. Hence the VFS could provide two helpers - one for the existing timestamp format and one for the new integrated change counter timestamp. The filesystem can then select the right one to call. And, further, filesystems that have lazytime enabled should be checking that early to determine what to do. Lazytime specific helpers would be useful here. > Could that include incrementing the lower > bits of i_ctime.tv_nsec for filesystems that advertise a non-1nsec > granularity but also set a flag that effectively means "but you can use > the lower tv_nsec bits if you want"? Certainly. Similar to multi-grain timestamps, I don't see anything filesystem specific about this mechanism. I think that anyone saying "it's ok if it's internal to XFS" is still missing the point that i_version as a VFS construct needs to die. At most, i_version is only needed for filesystems that don't have nanosecond timestamp resolution in their on-disk format and so need some kind of external ctime change counter to provide fine-grained, sub-timestamp granularity change recording. > And perhaps after all that, the VFS should decide if a timestamp update > needs to be persisted (e.g. lazytime/nodiratime/poniesatime) and if so, > call ->update_time or __mark_inode_dirty? Then XFS doesn't have to know > about all the timestamp persistence rules, it just has to follow > whatever the VFS tells it. Sure. I'm not suggesting that the filesystem duplicate and encode all these rules itself. I'm just saying that it seems completely backwards that the VFS encode all this generic logic to handle all these separate cases in a single code path and then provides a callout that allows the filesystem to override it's decisions (e.g. lazytime) and do something else. The filesystem already knows exactly what specific subset of checks and updates need to be done so call ou tinto the filesystem first and then run the VFS helpers that do exactly what is needed for relatime, lazytime, using timestamps with integrated change counters, etc. > > Sorting the lazytime mess for internal change counters really needs > > for all the timestamp updates to be handled in the filesystem, not > > bounced back and forward between the filesystem and VFS helpers as > > it currently is, hence I think we need to rework ->update_time to > > make this all work cleanly. > > (Oh, I guess I proposed sort of the opposite of what you just said.) Not really, just seems you're thinking about how to code all the VFS helpers we'd need a bit differently... Cheers, Dav.e -- Dave Chinner david@fromorbit.com