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 E5421C4167B for ; Tue, 31 Oct 2023 07:04:12 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 63E678D0011; Tue, 31 Oct 2023 03:04:12 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 5EC778D0008; Tue, 31 Oct 2023 03:04:12 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 4B5048D0011; Tue, 31 Oct 2023 03:04:12 -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 3BB818D0008 for ; Tue, 31 Oct 2023 03:04:12 -0400 (EDT) Received: from smtpin23.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 0F2401CB304 for ; Tue, 31 Oct 2023 07:04:12 +0000 (UTC) X-FDA: 81404867544.23.E25EA38 Received: from mail-oi1-f173.google.com (mail-oi1-f173.google.com [209.85.167.173]) by imf28.hostedemail.com (Postfix) with ESMTP id 5AEFAC0025 for ; Tue, 31 Oct 2023 07:04:10 +0000 (UTC) Authentication-Results: imf28.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=LkHtvEar; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf28.hostedemail.com: domain of amir73il@gmail.com designates 209.85.167.173 as permitted sender) smtp.mailfrom=amir73il@gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1698735850; 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=/QHIvEcmJ0urypIUJ4I1hXriZ0FhrfT5zBc+eZq8EH4=; b=LAChpWhJTWi6xOjI/ZmV0jrmI4FSKhC+p2pUEEHQ3OV4R2MFh1mBhTBV2WDafIdS4JbflN AWZ1i2cnWfK1mYy+kLM1SuwaT6UX2EE8nTC5XJisJZhnFXC4wcxqGK3i6zQzXm2E2cUS05 p+oWiR521m6ybgnU+Ei/PVshAVXFnKw= ARC-Authentication-Results: i=1; imf28.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=LkHtvEar; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf28.hostedemail.com: domain of amir73il@gmail.com designates 209.85.167.173 as permitted sender) smtp.mailfrom=amir73il@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1698735850; a=rsa-sha256; cv=none; b=kmrHe77XjZ3b66xTiQF1rCLzhwzeZad+W3neGmbmazG67cbpMnmyxrQb21jIbs6IQsE+hG NLCCd8uP4d337mEO4o5VCutI2S414bttrAusGlI9pWieG3AbWl+qkGVMPEcag5SPQiuzsV 72BI4P1dkBnCt5vAInIhd0gFVTUQ1mk= Received: by mail-oi1-f173.google.com with SMTP id 5614622812f47-3b2e4107f47so3726129b6e.2 for ; Tue, 31 Oct 2023 00:04:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1698735849; x=1699340649; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=/QHIvEcmJ0urypIUJ4I1hXriZ0FhrfT5zBc+eZq8EH4=; b=LkHtvEar+YiVKZEAZcmKJ1HeiaTPj6nBt+9QLRIq2f6WpjAlZCJRLds4BKCPzJ3WMo v6P/ld1B+9rhRIRBepoDFIlW1/DDY4uQr9jDmuF3GqzoOt+UpljGInRUmEITrY/t1j70 HoPmEyn2pNRPtVnwqDGhBW8R32E8uvWgg+j9S2EVdUZBW8KE3fk2WDoli/HxJeK9rFNh gXJvcgvqz6StVbFgduY37Kd9AEyQB/OJ2zFs2ae13/8fune/j1RmId8ojUoSWFiw/epq Qe78GEkvpsBvyqcfihSon3/GlwUCw+7dTixbL3HX7G0wNQpaXyO7nxnSGFmvVnwJ4QxC DOMw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1698735849; x=1699340649; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=/QHIvEcmJ0urypIUJ4I1hXriZ0FhrfT5zBc+eZq8EH4=; b=cDtTfCU+ZXeFl1N+mBOhSvA9Ise9jWMroHnd40hBrGQtmh3m86KNA221xmAeCq1jzx nBlq9qcU9GKc07BPwnVekBVoEZM2X9wSvIRnG1G2IxjunYFw4cYqJLW/wmlxcMT9+eSF g8xlkutz43TdeitDhLeUImXgshEjMccJxgrk9FjHL8f92u7ilCs3QkF2F+GfGmq6Iq4a 8UbdlA8G5xhEeAPGfaKpwrQd+/GOslrrpZc9K/x1gerGqja3XR/qnp8nMRc2ylu44Mxw 68QvuRD1S+95gNubA0z0+atQYnsVuVn88zwRrc2AmOOGvqf8xXFlE35EOJX2nkzwPp0t QSFA== X-Gm-Message-State: AOJu0YywBilx7HXd6YKvaTU2Dd9PnUlub7zPHsFiBMLNuhuiH2Alg/uK GGgGL1lMYr06WrAHuZEdryCukI7Sm4WJLcqF360= X-Google-Smtp-Source: AGHT+IFJczJ9Y/Gta2VEUUZlMPlc/e+BEvHoooShDS3IUryTcj10C5j9NWzQ+H0qQ0tSno1kZ94fcMD7UWyA5SIWMGk= X-Received: by 2002:aca:909:0:b0:3b0:da4a:4823 with SMTP id 9-20020aca0909000000b003b0da4a4823mr12874300oij.56.1698735849512; Tue, 31 Oct 2023 00:04:09 -0700 (PDT) MIME-Version: 1.0 References: <2ef9ac6180e47bc9cc8edef20648a000367c4ed2.camel@kernel.org> <6df5ea54463526a3d898ed2bd8a005166caa9381.camel@kernel.org> In-Reply-To: From: Amir Goldstein Date: Tue, 31 Oct 2023 09:03:57 +0200 Message-ID: Subject: Re: [PATCH RFC 2/9] timekeeping: new interfaces for multigrain timestamp handing To: Dave Chinner Cc: Linus Torvalds , Jeff Layton , 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 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspam-User: X-Stat-Signature: nngouau5naym3zns1487ddz4rsy9cgj9 X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: 5AEFAC0025 X-HE-Tag: 1698735850-210486 X-HE-Meta: U2FsdGVkX1/N3Vxcyguo1RaCqCNtoNrD079iwxjXqCEHRK/M1f0480w4jLQben4hGyYEyvYORBj4Q6/pBlzRGcRsYiwWu/iexF2j0tchDE/hXCk5Xf2dx2ihZDX1PYlOQuY+7hShH22l4fFGn0CDP6b72QzjG2+iRi1S2KXLFz9j2WCjJiBVxk8Pt3vQihiZVY4+QEzIw+FwIrO0NUBFW4glZO+Zi1Dfxh9sWRueb41k+WcR6BICVtYN3LWAaBsPjLrfEQgieRCSQdO/2wMY/DsxcDeK+G5dUlEZrDa20VdotMmpHG2jXwB6lWfJh/A2t/GWwfPG9FDB1c4D/fBppED1BzZyRGU90a93FMKZ6wELIjOA8SSnD7mYuDdfZ/tF++SF8wLzpDplLsL1TGk2tdNoKgI1qZcuzxVoy2XWuhrLthS6liZVhX+/PdZ63pMUUEit3bRAk9A5HMpwe4bljAePJRi0LM9bftOkUv5TkYwnGfcpSpgyhYYZdTse2hkPvmv8nB6NK5jEAhlpUvWHmsUSDKsGnlfO0EyuICmoTuB4q9ge0s8fvSkVNdulNOK+5pt4KDLiGnHHcmTrJbbwecVFrK/cIht33UwacG5/nJWL0w7JVvEydW/oCmbkjV9+7YGPJm/vXUebjnSB1d3QswB1vWqle2qgDBWb7TLvF7f5Md2CMyZLZQogJrLcUQvyD5ZZzO/0unPu9tdq+r5gsEL2AlIzSwMHGq0oXpVP9OVcJ6sjRFQqu2a+0Ru+O7iyDHM9jeuODoMC8UT6wZT5pZ3T2JnzusucpFgGk3yOdQapLyOKtNowRRWuQWkkvXF0jhP+QV8pA0Q1yJky7UeAFKQ3UGyZ5PeON4UjOv7XhUpPqO65W5mTMcZ3yRSWLXabh7tSGjA2Uzu/r1zsDrECxD3GmDBtJ+KJaFxBcWeneXRZYZIrB4Al4W8JWj9aeYZmF2uk20+AJjmKWnzsIrV RXQ+Zo7N 8o7WmP4IMGpc0oU2/patWpbrmaDDaUUXs2C3OAb3ScR8+H1/um6cJS79u/jPVUd62JTR42C9zBi3UK9SeRx6eKthBoyISF8ZX3nhIw8e91sA5e3SYl8ZAaG7BBJgqPAZxvBV5hnKI+j8Ys9WB/ldIe1awIRw5drr2bwIEfU51ya7iSgK9kPLbtpUSObOwmTGK/kTDl2ETCTbJ0XDdkGbHus9KbvvUdemn1u63cu38TbgH9rQp1wjNFELR7otgaW4aLfsZ5F1yeFHkFG6tifEYlev+bpBDp4TXSK4Ocyi7aPVge2v41bkLX8sqk67oXP3x/YMq7BsERoIAdEWvfFYuTHrmDkBm3Hsme/+GcmxFuaH1Z1xYN1OSAXmIkk+chemojkJ71qMzTbQeUO+fiRHglcKkNAap58iMUiB1uzAhgi1cSpeOx5LFNNjKCw== 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 3:42=E2=80=AFAM Dave Chinner = wrote: > [...] > .... and what is annoying is that that the new i_version just a > glorified ctime change counter. What we should be fixing is ctime - > integrating this change counting into ctime would allow us to make > i_version go away entirely. i.e. We don't need a persistent ctime > change counter if the ctime has sufficient resolution or persistent > encoding that it does not need an external persistent change > counter. > > That was reasoning behind the multi-grain timestamps. While the mgts > implementation was flawed, the reasoning behind it certainly isn't. > We should be trying to get rid of i_version by integrating it into > ctime updates, not arguing how atime vs i_version should work. > > > So I don't think the issue here is "i_version" per se. I think in a > > vacuum, the best option of i_version is pretty obvious. But if you > > want i_version to track di_changecount, *then* you end up with that > > situation where the persistence of atime matters, and i_version needs > > to update whenever a (persistent) atime update happens. > > Yet I don't want i_version to track di_changecount. > > I want to *stop supporting i_version altogether* in XFS. > > I want i_version as filesystem internal metadata to die completely. > > I don't want to change the on disk format to add a new i_version > field because we'll be straight back in this same siutation when the > next i_version bug is found and semantics get changed yet again. > > Hence if we can encode the necessary change attributes into ctime, > we can drop VFS i_version support altogether. Then the "atime bumps > i_version" problem also goes away because then we *don't use > i_version*. > > But if we can't get the VFS to do this with ctime, at least we have > the abstractions available to us (i.e. timestamp granularity and > statx change cookie) to allow XFS to implement this sort of > ctime-with-integrated-change-counter internally to the filesystem > and be able to drop i_version support.... > I don't know if it was mentioned before in one of the many threads, but there is another benefit of ctime-with-integrated-change-counter approach - it is the ability to extend the solution with some adaptations also to mtime. The "change cookie" is used to know if inode metadata cache should be invalidated and mtime is often used to know if data cache should be invalidated, or if data comparison could be skipped (e.g. rsync). The difference is that mtime can be set by user, so using lower nsec bits for modification counter would require to truncate the user set time granularity to 100ns - that is probably acceptable, but only as an opt-in behavior. The special value 0 for mtime-change-counter could be reserved for mtime that was set by the user or for upgrade of existing inode, where 0 counter means that mtime cannot be trusted as an accurate data modification-cookie. This feature is going to be useful for the vfs HSM implementation [1] that I am working on and it actually rhymes with the XFS DMAPI patches that were never fully merged upstream. Speaking on behalf of my employer, we would love to see the data modification-cookie feature implemented, whether in vfs or in xfs. *IF* the result on this thread is that the chosen solution is ctime-with-change-counter in XFS *AND* if there is agreement among XFS developers to extend it with an opt-in mkfs/mount option to 100ns-mtime-with-change-counter in XFS *THEN* I think I will be able to allocate resources to drive this xfs work. Thanks, Amir. [1] https://github.com/amir73il/fsnotify-utils/wiki/Hierarchical-Storage-Ma= nagement-API