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 1AD83C00142 for ; Tue, 31 Oct 2023 12:55:37 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 3DE9C6B02F0; Tue, 31 Oct 2023 08:55:37 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 3676E6B02F1; Tue, 31 Oct 2023 08:55:37 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 208216B02F2; Tue, 31 Oct 2023 08:55:37 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 0E4486B02F0 for ; Tue, 31 Oct 2023 08:55:37 -0400 (EDT) Received: from smtpin22.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id D18B714078F for ; Tue, 31 Oct 2023 12:55:36 +0000 (UTC) X-FDA: 81405753072.22.219200E Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by imf16.hostedemail.com (Postfix) with ESMTP id CB9E7180012 for ; Tue, 31 Oct 2023 12:55:34 +0000 (UTC) Authentication-Results: imf16.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=Fc9r3Hnh; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf16.hostedemail.com: domain of jlayton@kernel.org designates 145.40.68.75 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=1698756935; 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=8zpPpc7hJPOndlv09kob1Y+xERTxbWOWhv/QjJNUCRo=; b=H3AuZPxa5b4X06DFKVh1m0UUOLhAWRmFNXKGVoMFwtkkFNML/cz8LffJwcQzr1ChTfD2S0 qqqPuvJuVqIfQEWpI1MtMYbIi2zu4RqYpKG3DW2mPKFv4UcSt8QqOORJxmQbqC5lf92mJI 9bQX9EJwuoF+08Pa6QAkU+6yYGFGYp8= ARC-Authentication-Results: i=1; imf16.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=Fc9r3Hnh; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf16.hostedemail.com: domain of jlayton@kernel.org designates 145.40.68.75 as permitted sender) smtp.mailfrom=jlayton@kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1698756935; a=rsa-sha256; cv=none; b=KuEAYglKvQy9lMW+ZsqMkIF0LpEV4XpEBVH/RnCIqZPGCWUgEZjj68Ki8gYVa+1pq8MuYF kh9piWN07N4ukRHTOsr92Wg7Y5dslCJrY2PrEVxw3Gu9DVFKYzPunMh6Y+cHIHEO2wnrDI AqjbxguMgho+2E5rYZZ3bNsYGXQaDak= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by ams.source.kernel.org (Postfix) with ESMTP id 1FA07B80ECE; Tue, 31 Oct 2023 12:55:33 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 33947C433C8; Tue, 31 Oct 2023 12:55:30 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1698756932; bh=s7UBSmOan5oLtMhAz9UbCJu2Vxkj6b+7mYph/6f2OQ4=; h=Subject:From:To:Cc:Date:In-Reply-To:References:From; b=Fc9r3HnhP2vrDNKoCbIYyj3IJrXZ1Gm3bIlLEPBLpBVAkLstdVfLk6/LS2vex+SSO IditxlTPlqhQJJBWOO4+9OnQvTpiyYVst57FnePcyEXPbPf6WafvGffAsLZsmjSeLk TA7XVfrRoSpIxjCKtKIzdMUQZaDByKBL3fVP/bni2e6bgRUy0dsa2oaqhYVI3GaSD5 PGrVhNmfxijl1WfwMkaFeLulhpH5WRmskhcrN5LVFtQ9v9FPE8kO4eFEI9JeukVXxV Gz1bmq0XjkkizrBM9/eo9IILVDmb28ZOBoHHxY6PHPZm35yM391OYl8lssPbx3jcZG dGJal2gIxTzgQ== Message-ID: <34e2c1231f54309c204c5b67e1999dfe1a00fceb.camel@kernel.org> Subject: Re: [PATCH RFC 2/9] timekeeping: new interfaces for multigrain timestamp handing From: Jeff Layton To: Jan Kara Cc: Dave Chinner , 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: Tue, 31 Oct 2023 08:55:28 -0400 In-Reply-To: <20231031122201.kmxzttzfbearu6iu@quack3> References: <2ef9ac6180e47bc9cc8edef20648a000367c4ed2.camel@kernel.org> <6df5ea54463526a3d898ed2bd8a005166caa9381.camel@kernel.org> <20231031122201.kmxzttzfbearu6iu@quack3> Content-Type: text/plain; charset="ISO-8859-15" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.48.4 (3.48.4-1.fc38) MIME-Version: 1.0 X-Rspam-User: X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: CB9E7180012 X-Stat-Signature: wzq1nwpk7ejy4un1fte7kqwpz3pru74e X-HE-Tag: 1698756934-201222 X-HE-Meta: U2FsdGVkX1/fO6mCsSZMpxMBGuNGc07DLhXXUX5/exqQYBhqQVlLSRUOoYoPtcwJtys55xut+ih4YNpy/XmCZH2+GKqI+YTU39vXAyttd1A/hpq8yawlX6LltUDO+hTLB9Teb3j5lNYSqz6nfe4F8VyhQ5UuJZ0xR02gDLf9HESDAFKWjIJAREfczVWlmEJjJ3x/tgpTlhX3N71vAtMzb+tjw75z5ZAOYUs+8n+xglJkKuUaBQBrJaZkeWIz7b5yB3+x5ZvGgb+u0jO/Ly/zAcDKRGP6lhxnOgREQQOoyT1LrRPZ72IJ/I781LFovWVC3AQ2pDB9P/3v35+6BB310s+CiLP0kImKe0qiGUJvzc1JyRWxFMBxSCrccsBeSzy08gNs/rI8HepsMK66+qywe3EaJAQLJKUgN8IJoYEsvPHDvBHGFZj2VOhQpcRPWJ5g4w2a0DR85B4TmTpiNbEqC52ifPHusWegeab5e7NmNYWchheROkLIz6G29U8Oge8WRVkLhDFLYodl5k6MpNAhpdT0GGnwF2JcIWTnHraD4B6eb9jH5BW+IWW6ebZdvSHlUCDkJ7xulXlAYQO41MdvZqAyNOClqP3ouTEI9zRx5FyOLyoWoJVTmET5IEj99XvRMiobGIZKKpPcChKkHxMk3I3N0buw3En+g5NV9DsVd5jwGg20pmpIDrMe5IzBzKiD81pClApzgGxbisyHOF86GTomFWYRqsTJzdIYNYGxmfHMnyBhzhcjuOJ2+AXrm7xNBT0ZswNiL8uIVuIuGN8Kin94CJfz7uNY18ZuYxrjOetsvmsOTc+kkp/s7bdhAJ6SHHV8fO2dZdrn1XtDC2j49jWPe8IUtOTy2AOITStN6zjXM0v/52Z3geUiDakS5zjkgxBrVq/FmQExTQsxOrDSjzRsNn+7ALBQlf6VVDGQntIuvCJ9hZ4kvtVx+XeHrl9xPxJB6eyVkgji+bJCabP /Vd1Q/VK jkgJjhX3a1qffGEBpXQIQ/Koi+K5RsTffF+gIfX5bwi99s18fscPm3mmATdPl/aGx0Plm5euxlc8FDoeGd4x2ANlpS/cqEg9sxwPpEyobkAsiFEEYlg+AvwOEeENtPPW+/0apJemHpAiBL+gKSTQva9h8U4cnPSwMuv2zZfsjJ9eEAbA474jyOmXGKjkgyCN0+IGHb7AMab6q3Z5o918+2mdWtXMYyD1go7zp0nez+ekkqVQBss1reUmjJg== 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, 2023-10-31 at 13:22 +0100, Jan Kara wrote: > On Tue 31-10-23 07:04:53, Jeff Layton wrote: > > On Tue, 2023-10-31 at 09:37 +1100, Dave Chinner wrote: > > > I have suggested mechanisms for using masked off bits of timestamps > > > to encode sub-timestamp granularity change counts and keep them > > > invisible to userspace and then not using i_version at all for XFS. > > > This avoids all the problems that the multi-grain timestamp > > > infrastructure exposed due to variable granularity of user visible > > > timestamps and ordering across inodes with different granularity. > > > This is potentially a general solution, too. > >=20 > > I don't really understand this at all, but trying to do anything with > > fine-grained timestamps will just run into a lot of the same problems w= e > > hit with the multigrain work. If you still see this as a path forward, > > maybe you can describe it more detail? >=20 > Dave explained a bit more details here [1] like: >=20 > Another options is for XFS to play it's own internal tricks with > [cm]time granularity and turn off i_version. e.g. limit external > timestamp visibility to 1us and use the remaining dozen bits of the > ns field to hold a change counter for updates within a single coarse > timer tick. This guarantees the timestamp changes within a coarse > tick for the purposes of change detection, but we don't expose those > bits to applications so applications that compare timestamps across > inodes won't get things back to front like was happening with the > multi-grain timestamps.... > - >=20 > So as far as I understand Dave wants to effectively persist counter in lo= w > bits of ctime and expose ctime+counter as its change cookie. I guess that > could work and what makes the complexity manageable compared to full > multigrain timestamps is the fact that we have one filesystem, one on-dis= k > format etc. The only slight trouble could be that if we previously handed > out something in low bits of ctime for XFS, we need to keep handing the > same thing out until the inode changes (i.e., no rounding until the momen= t > inode changes) as the old timestamp could be stored somewhere externally > and compared. >=20 > Honza >=20 > [1] https://lore.kernel.org/all/ZTjMRRqmlJ+fTys2@dread.disaster.area/ >=20 >=20 Got it. That makes sense and could probably be made to work. Doing that all in XFS won't be simple though. You'll need to reimplement stuff like file_modified() and file_update_time(). Those get called from deep within the VFS and from page fault handlers. FWIW, that's the main reason the multigrain work was so invasive, even though it was a filesystem-specific feature. --=20 Jeff Layton