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 C405DCE79A8 for ; Tue, 19 Sep 2023 16:31:26 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 537D76B0082; Tue, 19 Sep 2023 12:31:26 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 4E7B96B0085; Tue, 19 Sep 2023 12:31:26 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 311386B0096; Tue, 19 Sep 2023 12:31:26 -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 1884A6B0082 for ; Tue, 19 Sep 2023 12:31:26 -0400 (EDT) Received: from smtpin22.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id CADA0C0DD8 for ; Tue, 19 Sep 2023 16:31:25 +0000 (UTC) X-FDA: 81253887330.22.2F609BD Received: from sin.source.kernel.org (sin.source.kernel.org [145.40.73.55]) by imf27.hostedemail.com (Postfix) with ESMTP id 4495140021 for ; Tue, 19 Sep 2023 16:31:22 +0000 (UTC) Authentication-Results: imf27.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b="NSgO9mQ/"; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf27.hostedemail.com: domain of jlayton@kernel.org designates 145.40.73.55 as permitted sender) smtp.mailfrom=jlayton@kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1695141084; a=rsa-sha256; cv=none; b=v9/WDbEpwh+nQWxnnpU/aIcNc8lUYJRNUNcindEkf34pNQ+Orj0CKPDAlEzxbgIuhu4URI cnCaLcD4QlUoWXMdHOXahUXNpo7xDM+DEE6f5kVf3oreggbOTqnV9h4nNM+N3esY2VsHn6 P//Gc4xHBoLiGhSTeGcOTito9Hcd02k= ARC-Authentication-Results: i=1; imf27.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b="NSgO9mQ/"; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf27.hostedemail.com: domain of jlayton@kernel.org designates 145.40.73.55 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=1695141084; 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=2YOWI6/JAFOB4t8+Jl1G0UAU2WJNOEKR+ozWrF+wCHw=; b=79C4h9D4yNs0xAuZccMB/PWtPxB1ZbAx57xaIldyfng/WU3tSAGTyha7z/FdEXgn6pL/Ro b+oKzoJW5bByPv05eaYlPK8Kpfa1V9+J6cGaQo9CrGoVc2po4fp0lte5iSgUXq3bW4FZtx noSAAZEoge9emvGiSVt7MaEWYlwYMdg= Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by sin.source.kernel.org (Postfix) with ESMTPS id 8CD0BCE139A; Tue, 19 Sep 2023 16:31:18 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 07A27C433CD; Tue, 19 Sep 2023 16:31:09 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1695141076; bh=2YOWI6/JAFOB4t8+Jl1G0UAU2WJNOEKR+ozWrF+wCHw=; h=Subject:From:To:Cc:Date:In-Reply-To:References:From; b=NSgO9mQ/kogScKOyruXs27QKGb28KeH5iN8518jdQIxYZ9Zq8W5Yeb8HJpLNbIZ40 EQDdGtIWCMRwCZr+hkVhSKagEDB2fBTdAzDnNexBTyvRGH8+mWpGC7k4O3oOthSODy kLPJh5RYmd+l51ixbejRXP63ZyU1UyglaFGETEGRw2BGftvafb/kUzhWZeRY/B1ibo Wti21rW2JgdQmcow8/EHQlT7uWQR0pPH/ecD4lkrfORAvjqUH6xcDxBDFUTwISNY24 GBmtqEOt9wCW1B2y4/2rn4A5SVB2ofaAjm8Z64p+ka1gu4ZTZ9u3KdunqSf9K8+AlP OJGP0iADrktsQ== Message-ID: <08b5c6fd3b08b87fa564bb562d89381dd4e05b6a.camel@kernel.org> Subject: Re: [PATCH v7 12/13] ext4: switch to multigrain timestamps From: Jeff Layton To: Bruno Haible , Jan Kara , Xi Ruoyao , bug-gnulib@gnu.org Cc: Alexander Viro , Christian Brauner , Eric Van Hensbergen , Latchesar Ionkov , Dominique Martinet , Christian Schoenebeck , David Howells , Marc Dionne , Chris Mason , Josef Bacik , David Sterba , Xiubo Li , Ilya Dryomov , Jan Harkes , coda@cs.cmu.edu, Tyler Hicks , Gao Xiang , Chao Yu , Yue Hu , Jeffle Xu , Namjae Jeon , Sungjong Seo , Jan Kara , Theodore Ts'o , Andreas Dilger , Jaegeuk Kim , OGAWA Hirofumi , Miklos Szeredi , Bo b Peterson , Andreas Gruenbacher , Greg Kroah-Hartman , Tejun Heo , Trond Myklebust , Anna Schumaker , Konstantin Komarov , Mark Fasheh , Joel Becker , Joseph Qi , Mike Marshall , Martin Brandenburg , Luis Chamberlain , Kees Cook , Iurii Zaikin , Steve French , Paulo Alcantara , Ronnie Sahlberg , Shyam Prasad N , Tom Talpey , Sergey Senozhatsky , Richard Weinberger , Hans de Goede , Hugh Dickins , Andrew Morton , Amir Goldstein , "Darrick J. Wong" , Benjamin Coddington , linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, v9fs@lists.linux.dev, linux-afs@lists.infradead.org, linux-btrfs@vger.kernel.org, ceph-devel@vger.kernel.org, codalist@coda.cs.cmu.edu, ecryptfs@vger.kernel.org, linux-erofs@lists.ozlabs.org, linux-ext4@vger.kernel.org, linux-f2fs-devel@lists.sourceforge.net, cluster-devel@redhat.com, linux-nfs@vger.kernel.org, ntfs3@lists.linux.dev, ocfs2-devel@lists.linux.dev, devel@lists.orangefs.org, linux-cifs@vger.kernel.org, samba-technical@lists.samba.org, linux-mtd@lists.infradead.org, linux-mm@kvack.org, linux-unionfs@vger.kernel.org, linux-xfs@vger.kernel.org Date: Tue, 19 Sep 2023 12:31:08 -0400 In-Reply-To: <4511209.uG2h0Jr0uP@nimes> References: <20230807-mgctime-v7-0-d1dec143a704@kernel.org> <20230919110457.7fnmzo4nqsi43yqq@quack3> <1f29102c09c60661758c5376018eac43f774c462.camel@kernel.org> <4511209.uG2h0Jr0uP@nimes> 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: rspam06 X-Rspamd-Queue-Id: 4495140021 X-Stat-Signature: r8qig5kz1zqgri5965rxjm5gt7spsqmm X-HE-Tag: 1695141082-552239 X-HE-Meta: U2FsdGVkX1/58tOHqwJGOJqJHhdrdm5QcippVhYAsxB5z6Mdcgp7FTGZBVejW4KSWe0whVR7QpgVDLTdUs1k3Ef8wq3i115+tHKxFMZWw2eL76KXbRDc6qxmQxBSsfqWkjD0Muko9jWiKzMCXWljguphLgT55V/m/duYUBPYEgkMjed4LK8veaYSRylElOrsTltfzR5RV35Q2KBX0vqiIL3th5DI85X9STnCuYlPFisb8dEfwEQ/G6VBglnGdDUmJWnaHgwJpKKngwbxkHI8tAktUAwXGKeXuaHhdzZP76Lb8F28aFRGqcQytP7PWXAYVvhrPF7BbGzkyi8YiyyfqNbCJudwJRlToSLUWaow0bfdbeJPsmt9zJJKLW2qjhAjs5JAxZ1VLTP2nuYgZCJzVz456jBaVPCnnmrI2xnw+rmospbTrF75U3f6UJ8QDwSGE03ZBI0nJES5Le2+5aSpqhgRYTMnnePgzNIZaCYPmAJDntfZnyUKq/J1LOloLMhUyKoJHYt98c3SNqcNWlIYITvFRZNQWTLnDOnBIbHoElrmUmrKfx6AOrS9jiljK1XWzfcId+g4TfXE/AaNKc8q9I3k4hCpfOe37QTCU2iWbEIyFzZ0JHtUlENqlA4nBJks5Il9uP+OufLGuy3vHKnZeDEfajJb+qpHQOM431/YFMhx27GxbMOLrn8xmXybccwr23hBS7t0e/9JxTsx2GFM+Zr/DNGAoOU6IDmSC/KUg2Z/8PUO8IxUDHIULHoUxiLzzu/fkafo3y2aOfRF4DrUghBpd1sXo1EbRWlAafSV2UOnUOHQaDRWp6wcFhd+kJfajfr+gSNuHemsqJOLL3wdcyrZHNzAJx0Ly4bPTyTNguQyFFT760CSgs0SP7WuYJMjZ/Um7yhDL7UNeDEb0b9cVUhiyfsupFmsoUwDgueHowS1EDk14ukp3hoM5b934SkjHwkhUhcPlFHRF7u9flT VDxN5KnO MIblNZpD41q8K4D+maUPDZI9C2FxmA4TToOMgMuHDzHEANJV0nfk9oo+oCdpdnxMCgBmV5opukcBCDJY46KJoNm4g4UcWXMiWCoEFwy6FAVCi8ANFwwNgGdea1vELkjYX/dTH7qT+HwukhPJq8AN13qQITb35CzY9R+LzHmEXGP8gjaYPqe8eapIWByZfWaim3PtI/xfMZG3YFd6xqFWPCxQw9LkPD39OfEjo8HzZBcy90L1wu8d7t4Qv6l1GUPtYNlovOcDA2O6rtg8dHhmgdvTI83QrEwA91agxI1dV/56X0gfzu1jRmW1sq14YUtVO2Gu6/XMuJ6KBP8++R/lLgCQaZdCrgmQgk8RT 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: On Tue, 2023-09-19 at 16:52 +0200, Bruno Haible wrote: > Jeff Layton wrote: > > I'm not sure what we can do for this test. The nap() function is making > > an assumption that the timestamp granularity will be constant, and that > > isn't necessarily the case now. >=20 > This is only of secondary importance, because the scenario by Jan Kara > shows a much more fundamental breakage: >=20 > > > The ultimate problem is that a sequence like: > > >=20 > > > write(f1) > > > stat(f2) > > > write(f2) > > > stat(f2) > > > write(f1) > > > stat(f1) > > >=20 > > > can result in f1 timestamp to be (slightly) lower than the final f2 > > > timestamp because the second write to f1 didn't bother updating the > > > timestamp. That can indeed be a bit confusing to programs if they com= pare > > > timestamps between two files. Jeff? > > >=20 > >=20 > > Basically yes. >=20 > f1 was last written to *after* f2 was last written to. If the timestamp o= f f1 > is then lower than the timestamp of f2, timestamps are fundamentally brok= en. >=20 > Many things in user-space depend on timestamps, such as build system > centered around 'make', but also 'find ... -newer ...'. >=20 What does breakage with make look like in this situation? The "fuzz" here is going to be on the order of a jiffy. The typical case for make timestamp comparisons is comparing source files vs. a build target. If those are being written nearly simultaneously, then that could be an issue, but is that a typical behavior? It seems like it would be hard to rely on that anyway, esp. given filesystems like NFS that can do lazy writeback. One of the operating principles with this series is that timestamps can be of varying granularity between different files. Note that Linux already violates this assumption when you're working across filesystems of different types. As to potential fixes if this is a real problem: I don't really want to put this behind a mount or mkfs option (a'la relatime, etc.), but that is one possibility. I wonder if it would be feasible to just advance the coarse-grained current_time whenever we end up updating a ctime with a fine-grained timestamp? It might produce some inode write amplification. Files that were written within the same jiffy could see more inode transactions logged, but that still might not be _too_ awful. I'll keep thinking about it for now. --=20 Jeff Layton