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 1BF5FC25B67 for ; Fri, 27 Oct 2023 10:36:05 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 3876B6B03A6; Fri, 27 Oct 2023 06:36:05 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 337756B03A7; Fri, 27 Oct 2023 06:36:05 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1D7E76B03A8; Fri, 27 Oct 2023 06:36:05 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 0ECA06B03A6 for ; Fri, 27 Oct 2023 06:36:05 -0400 (EDT) Received: from smtpin08.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id C650881272 for ; Fri, 27 Oct 2023 10:36:04 +0000 (UTC) X-FDA: 81390886248.08.5D99817 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf27.hostedemail.com (Postfix) with ESMTP id 03D1D4001B for ; Fri, 27 Oct 2023 10:36:02 +0000 (UTC) Authentication-Results: imf27.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=UVXKZh2p; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf27.hostedemail.com: domain of jlayton@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=jlayton@kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1698402963; 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=wQklQBWWi3q5RrX0mgkbHS32RUoA0iW2wHKZzc9ZHTA=; b=RxvARf0vRR3n8ECdAYepah84xNKfaGeQLjgsFaly+EJ64vtlhrgyVrwWTfT7B61ggS8wH6 jJJQfZs7Iyu6TFzEBlFOI6ot9lk016WQibZw0Av7OfNaQDu/AZjuSH9vccvydsU3HKzb+G qc41VBVUzlvNIcjam6OfqTlBabuDYhQ= ARC-Authentication-Results: i=1; imf27.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=UVXKZh2p; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf27.hostedemail.com: domain of jlayton@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=jlayton@kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1698402963; a=rsa-sha256; cv=none; b=IAj6z7LcQKKE1x2tPQe0z8OssXe2rhtnKc2llJoTKs6FWSDYdzIoy4Hp8M1JDR7Y4A1Ahs LVmjbCj+GmaP1B1+j0l3oqyclTVG+oI69kRS+g8p2HGHB3QAFLuiE7JY8PG1/u1w4+mpuC DQ9NLgzaTwGx3KW6/FMu/iXW8ryuZHE= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id D03A66224A; Fri, 27 Oct 2023 10:36:01 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 39336C433C8; Fri, 27 Oct 2023 10:35:59 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1698402961; bh=VhY7QbKdLKYqIDXPYrnQDYPAsjSB5qnb7uEtzCqAr40=; h=Subject:From:To:Cc:Date:In-Reply-To:References:From; b=UVXKZh2puLMQITt0KDbqEsmmgGhrSIaUjArTj/QriDrgVKraAist2AE0jWBDqkMHT ek/J3aYZfXbMG+/FCT7xA4Zi3AwrcLD58zQru0GR0mZgTkyHGdmGHt4U0T1d1YvzaQ RvWiCsKGFdE9RWj6E5hsMkft1377XkUIKDCnYbBx49FeN3DXvEgloG7jNWBV62Vhai fsFVEc4KrZkFPWkOwucZw+pQ/M+RKLFFm+/x/A0Ggg9MCMRtNFMBIFHKYe/+DRjoKa QJsDY1eJqd4hcY9s/Q2y6wmnEsaxcKts4CImuXC3iNrZChbj2Z2To5ICWXius09aEt 45jXgjywaDQVw== Message-ID: <6df5ea54463526a3d898ed2bd8a005166caa9381.camel@kernel.org> Subject: Re: [PATCH RFC 2/9] timekeeping: new interfaces for multigrain timestamp handing From: Jeff Layton To: Dave Chinner Cc: Amir Goldstein , Linus Torvalds , Kent Overstreet , Christian Brauner , Alexander Viro , John Stultz , Thomas Gleixner , Stephen Boyd , Chandan Babu R , "Darrick J. Wong" , 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 Date: Fri, 27 Oct 2023 06:35:58 -0400 In-Reply-To: References: <61b32a4093948ae1ae8603688793f07de764430f.camel@kernel.org> <2ef9ac6180e47bc9cc8edef20648a000367c4ed2.camel@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 X-Rspamd-Queue-Id: 03D1D4001B X-Rspam-User: X-Rspamd-Server: rspam05 X-Stat-Signature: qa4anss8haefhjy65g69kan14rcyw8g7 X-HE-Tag: 1698402962-592825 X-HE-Meta: U2FsdGVkX1/3TgBHE6AYlEpWDKAlWj8T09eum4+614Xh9igvE5laqn5XZZ8r4DWQJ0NijHoSulMjHnCN9IMktU6JZ4v3yuwjwECLmDFfskyMWVHzEa/4AW7oDiSLFM08Vr5/GetNEGetrxO0dtT32Eyenm+e6afbOLzNhGkjJ7u4vfuMbrDFncaYKKe0R8MCX4JD7qghu72cNHnQN6P0RNR8NI43qQuqiF1+l52clBWREvWBMoESWPRM7ITOZH/F7tDoDqVfkPebgmV9HQ1ZWu4q91ff+VqrM7TUq8o82RwSsL6IXlX2+p014WHU8YMWNCVd5MV+o9UigYnwwsbvof8TI7b3Q7UkR4tHZjivPCcB7FR0fzkygkSbc+kMGRb46Bmc9vGtU1HEBM90+fGWcXIOrZbLvrehiRokG5fUZ4ZDfzY/y7D8wA5tLcQR3iKxoT76/5J4FrZARt9SjUenzVwcVT1NejiFHF5wAPVg3Ox+FaU3QW0WS1l5I31frRP6VrxgjBRzPAefOGFpu5ycFIrcmL0hCUlbwcMlv0eYsSP1i2hLxhhPuzQ2Y/y99KtAAZ+oomouCx2t5xd+7hpjLVCzumCpL7JhlzdURQRiByPHG090qVeTSJyawGk08cWOmRQnlc3tVOHvYw0jtYFIBxsPLeM63/Edl4Ee1X29rNjTqJYgrmu9PqUNj4EcU342zkSGosGRJ0te/ZXtuyyMlJmV8E1Kn4rJqefP5tcMs4lxGLuKVHL3mb2VdiFdrV6VaSpNjHDuSwBN8k/n+pdORcV9aKi2/zVHqRou6yhdts2YeNVbvlZW0h5kSwzB3YZfbj/THbJF1980A5NjH33BI/C1UT8fezBDj5vuBzCK2q54jozeaimdImn92vX44T/GmeXU5MOCuMczhzt5HcYyQQgNRYzV+dJIcw8zY3OhxXDCD8wTgctbUaiVG/lKLWXq1nEDSXGaoeH+gqb4DWE +ftu7wNZ QmrsI7BCiqKxKzVcq7gEEVDY6I06kXqB9gE9hFhvHTGLTwfX8M8ShXzON+MVi3SeseEk/Gs2Yf8P/YXK4j3knjHocjaLEBzo86BszGrEpBuFj9jWPokTbvkRJFrF4giDftLkJHOGUJznnvOj01TKGqLAjjNcz+Vmicr2oV4tn9B3KHHyYuEv2kH1hbRYUGlndcIvRzQ9Kzu0mFCje+5hFdAo6dPypASwlLzkOfR7Pr3e7D2hlkDiKmwqh3uWf6gx1n/IgS/7a8eogqOdSOduSYdLnkqRflcbcZBO816JE4bb5gK/t/atAKe+xLw== 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 Thu, 2023-10-26 at 13:20 +1100, Dave Chinner wrote: > On Wed, Oct 25, 2023 at 08:25:35AM -0400, Jeff Layton wrote: > > On Wed, 2023-10-25 at 19:05 +1100, Dave Chinner wrote: > > > On Tue, Oct 24, 2023 at 02:40:06PM -0400, Jeff Layton wrote: > > > > On Tue, 2023-10-24 at 10:08 +0300, Amir Goldstein wrote: > > > > > On Tue, Oct 24, 2023 at 6:40=E2=80=AFAM Dave Chinner wrote: > > > > > >=20 > > > > > > On Mon, Oct 23, 2023 at 02:18:12PM -1000, Linus Torvalds wrote: > > > > > > > On Mon, 23 Oct 2023 at 13:26, Dave Chinner wrote: > > > > > Does xfs_repair guarantee that changes of atime, or any inode cha= nges > > > > > for that matter, update i_version? No, it does not. > > > > > So IMO, "atime does not update i_version" is not an "on-disk form= at change", > > > > > it is a runtime behavior change, just like lazytime is. > > > >=20 > > > > This would certainly be my preference. I don't want to break any > > > > existing users though. > > >=20 > > > That's why I'm trying to get some kind of consensus on what > > > rules and/or atime configurations people are happy for me to break > > > to make it look to users like there's a viable working change > > > attribute being supplied by XFS without needing to change the on > > > disk format. > > >=20 > >=20 > > I agree that the only bone of contention is whether to count atime > > updates against the change attribute. I think we have consensus that al= l > > in-kernel users do _not_ want atime updates counted against the change > > attribute. The only real question is these "legacy" users of > > di_changecount. >=20 > Please stop refering to "legacy users" of di_changecount. Whether > there are users or not is irrelevant - it is defined by the current > on-disk format specification, and as such there may be applications > we do not know about making use of the current behaviour. >=20 > It's like a linux syscall - we can't remove them because there may > be some user we don't know about still using that old syscall. We > simply don't make changes that can potentially break user > applications like that. >=20 > The on disk format is the same - there is software out that we don't > know about that expects a certain behaviour based on the > specification. We don't break the on disk format by making silent > behavioural changes - we require a feature flag to indicate > behaviour has changed so that applications can take appropriate > actions with stuff they don't understand. >=20 > The example for this is the BIGTIME timestamp format change. The on > disk inode structure is physically unchanged, but the contents of > the timestamp fields are encoded very differently. Sure, the older > kernels can read the timestamp data without any sort of problem > occurring, except for the fact the timestamps now appear to be > completely corrupted. >=20 > Changing the meaning of ithe contents of di_changecount is no > different. It might look OK and nothing crashes, but nothing can be > inferred from the value in the field because we don't know how it > has been modified. >=20 > Hence we can't just change the meaning, encoding or behaviour of an > on disk field that would result in existing kernels and applications > doing the wrong thing with that field (either read or write) without > adding a feature flag to indicate what behaviour that field should > have. >=20 > > > > Perhaps this ought to be a mkfs option? Existing XFS filesystems co= uld > > > > still behave with the legacy behavior, but we could make mkfs.xfs b= uild > > > > filesystems by default that work like NFS requires. > > >=20 > > > If we require mkfs to set a flag to change behaviour, then we're > > > talking about making an explicit on-disk format change to select the > > > optional behaviour. That's precisely what I want to avoid. > > >=20 > >=20 > > Right. The on-disk di_changecount would have a (subtly) different > > meaning at that point. > >=20 > > It's not a change that requires drastic retooling though. If we were to > > do this, we wouldn't need to grow the on-disk inode. Booting to an olde= r > > kernel would cause the behavior to revert. That's sub-optimal, but not > > fatal. >=20 > See above: redefining the contents, behaviour or encoding of an on > disk field is a change of the on-disk format specification. >=20 > The rules for on disk format changes that we work to were set in > place long before I started working on XFS. They are sane, well > thought out rules that have stood the test of time and massive new > feature introductions (CRCs, reflink, rmap, etc). And they only work > because we don't allow anyone to bend them for convenience, short > cuts or expediting their pet project. >=20 > > What I don't quite understand is how these tools are accessing > > di_changecount? >=20 > As I keep saying: this is largely irrelevant to the problem at hand. >=20 > > XFS only accesses the di_changecount to propagate the value to and from > > the i_version, >=20 > Yes. XFS has a strong separation between on-disk structures and > in-memory values, and i_version is simply the in-memory field we use > to store the current di_changecount value. We force bump i_version > every time we modify the inode core regardless of whether anyone has > queried i_version because that's what di_changecount requires. i.e. > the filesystem controls the contents of i_version, not the VFS. >=20 > Now that NFS is using a proper abstraction (i.e. vfs_statx()) to get > the change cookie, we really don't need to expose di_changecount in > i_version at all - we could simply copy an internal di_changecount > value into the statx cookie field in xfs_vn_getattr() and there > would be almost no change of behaviour from the perspective of NFS > and IMA at all. >=20 > > and there is nothing besides NFSD and IMA that queries > > the i_version value in-kernel. So, this must be done via some sort of > > userland tool that is directly accessing the block device (or some 3rd > > party kernel module). >=20 > Yup, both of those sort of applications exist. e.g. the DMAPI kernel > module allows direct access to inode metadata through a custom > bulkstat formatter implementation - it returns different information > comapred to the standard XFS one in the upstream kernel. >=20 > > In earlier discussions you alluded to some repair and/or analysis tools > > that depended on this counter. >=20 > Yes, and one of those "tools" is *me*. >=20 > I frequently look at the di_changecount when doing forensic and/or > failure analysis on filesystem corpses. SOE analysis, relative > modification activity, etc all give insight into what happened to > the filesystem to get it into the state it is currently in, and > di_changecount provides information no other metadata in the inode > contains. >=20 > > I took a quick look in xfsprogs, but I > > didn't see anything there. Is there a library or something that these > > tools use to get at this value? >=20 > xfs_db is the tool I use for this, such as: >=20 > $ sudo xfs_db -c "sb 0" -c "a rootino" -c "p v3.change_count" /dev/mapper= /fast > v3.change_count =3D 35 > $ >=20 > The root inode in this filesystem has a change count of 35. The root > inode has 32 dirents in it, which means that no entries have ever > been removed or renamed. This sort of insight into the past history > of inode metadata is largely impossible to get any other way, and > it's been the difference between understanding failure and having no > clue more than once. >=20 > Most block device parsing applications simply write their own > decoder that walks the on-disk format. That's pretty trivial to do, > developers can get all the information needed to do this from the > on-disk format specification documentation we keep on kernel.org... >=20 Fair enough. I'm not here to tell you that you guys that you need to change how di_changecount works. If it's too valuable to keep it counting atime-only updates, then so be it. If that's the case however, and given that the multigrain timestamp work is effectively dead, then I don't see an alternative to growing the on- disk inode. Do you? --=20 Jeff Layton