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 C795DCE79D1 for ; Wed, 20 Sep 2023 11:49:25 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id EE39A6B013E; Wed, 20 Sep 2023 07:49:24 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id E6CD86B0146; Wed, 20 Sep 2023 07:49:24 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D0CB96B0149; Wed, 20 Sep 2023 07:49:24 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id BFB426B013E for ; Wed, 20 Sep 2023 07:49:24 -0400 (EDT) Received: from smtpin16.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 9AACDA0E93 for ; Wed, 20 Sep 2023 11:49:24 +0000 (UTC) X-FDA: 81256805448.16.50EED5C Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by imf12.hostedemail.com (Postfix) with ESMTP id BB2A44001B for ; Wed, 20 Sep 2023 11:49:22 +0000 (UTC) Authentication-Results: imf12.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=cFYKmaGX; spf=pass (imf12.hostedemail.com: domain of brauner@kernel.org designates 145.40.68.75 as permitted sender) smtp.mailfrom=brauner@kernel.org; dmarc=pass (policy=none) header.from=kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1695210563; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=KOwFYJFVauAzGdLHiygCqgNB24b8lWzTQA0Uqsb4joQ=; b=yePzI0uA4y/eAsSi04GjiBdaMYqnzCJcxoDnUs4bfQwYC+L3MN4yy2luJVtZkGIyw9lmnF okRKYN3qIXCYyJBOgTA6sGB8Qbqvz+mCdVdxEcnEF7OAkp8lWvlATZ7/vufDdokG7b5jNc FiicGiXIsioEuLmgK0fGsz1pdkrnCY0= ARC-Authentication-Results: i=1; imf12.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=cFYKmaGX; spf=pass (imf12.hostedemail.com: domain of brauner@kernel.org designates 145.40.68.75 as permitted sender) smtp.mailfrom=brauner@kernel.org; dmarc=pass (policy=none) header.from=kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1695210563; a=rsa-sha256; cv=none; b=TmehPnrbj7avB/2qj5oLeLS89XpDtRdqj1TsXfl9Egc8RYvnsOtyJ2eeGELbUv4z8NbQ96 UWk5V+K9fZLqXufG59JYJZcg0uQU0ImmCPN6g4Wo+1nZQShWHnQ+1IFT4HpwhmzrtxsA+t MnN6fkdVGsAWJUn8wLfjo0wY3SDzR38= 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 ams.source.kernel.org (Postfix) with ESMTPS id 96616B81CD5; Wed, 20 Sep 2023 11:49:20 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 6370EC433C9; Wed, 20 Sep 2023 11:49:02 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1695210559; bh=TqtjWOcEef/+khFbYtdnIshKRIs8+bywMfiG/cwmuh4=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=cFYKmaGXziAaFdOhpy49kuzCT+oXmuuyMlKdt5avbqCKSL/Zu7OVEs3mlm7M/sHyA 0HvJ8d7afp2KnwqnvPT80LQhjFnRks3F/YsDrfT7vnnepp6+WGA4Zh/TgQaMx3vzG/ FSdjSYHz15F17uBZuvgclX0e0Uzn2y3zr2N4KuAbC7L4TSP8nzppTP6PGz7ksuIBn6 D7F8fYpVmjnW0KAu5zZZbDeVJBeiDbOkUDLtjQKowBnwbvuuMN7P3da3QHW8y+AF7o 0GQW+1Wqk+Kq+clrWKVSkVIemiMGsEV0NqdTi+gPzRLCsKCVTIw/LoOQ2OmEp/Yh2H Okefwq3+K1QiA== Date: Wed, 20 Sep 2023 13:48:59 +0200 From: Christian Brauner To: Jeff Layton Cc: Jan Kara , Bruno Haible , Xi Ruoyao , bug-gnulib@gnu.org, Alexander Viro , 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 Subject: Re: [PATCH v7 12/13] ext4: switch to multigrain timestamps Message-ID: <20230920-raser-teehaus-029cafd5a6e4@brauner> References: <20230807-mgctime-v7-0-d1dec143a704@kernel.org> <20230919110457.7fnmzo4nqsi43yqq@quack3> <1f29102c09c60661758c5376018eac43f774c462.camel@kernel.org> <4511209.uG2h0Jr0uP@nimes> <08b5c6fd3b08b87fa564bb562d89381dd4e05b6a.camel@kernel.org> <20230920-leerung-krokodil-52ec6cb44707@brauner> <20230920101731.ym6pahcvkl57guto@quack3> <317d84b1b909b6c6519a2406fcb302ce22dafa41.camel@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <317d84b1b909b6c6519a2406fcb302ce22dafa41.camel@kernel.org> X-Rspamd-Queue-Id: BB2A44001B X-Rspam-User: X-Stat-Signature: h6n88nqt4f43i37qzbb1mhdzpb4hgziu X-Rspamd-Server: rspam01 X-HE-Tag: 1695210562-844261 X-HE-Meta: U2FsdGVkX1/Zn8H8MN/H3xNmx6ij65Sh1X1HeEmo+qtAlluXlL2PgcUA/Ab/2XG7E7/Km/IFoLZpwCqLRcHtyVGS4lLyVf9yhwP544n0xikrj+wwfCM3mpRfYpCMxULWPvZuiI6vwEL226VwErFn2VbnB2E+FOLBsEv9mjrtID5v4MzwdEWVxTTIGodpoXrUJB4vQL8P+IBPAcp21lIlKTYGpSasYFOv+SedaZa/ahAZHCS4Vky76D3lF0blAg4BEXrQmIEHuFkUEcEZVjnLiurup8y4fqCRkrwF7iC7dBozSLlVjdwSKRknts2+fCt20CsxwaKsiQHm6/lGYjDKb5b6WA59bHYrdnABpXG8Irm1eaS11DWue4uO2oHQZUn5HiVmz7C2nsLrZwX9u1tpsvQWwOKviQ8bXPChMFaK7vDE3UbQzfBWXutJD3KkJf7+ygoLQoI0lZmnwqoy/i/arLm4tlI/WH2ZDgrHevcBryScfFwftSZtVCHhv+GALghqF/njjh1hH56p910w3Dgy5SVleMW4mTobnxnFHYEG9pWlhgVkdMssGC/wh334Eya4z7tQJObm0p9Kt9LJT/DFCAFkQBAzSvvBHuKvh5/yneG62rgkdduGCXFyIb+dYAluoqDWYctXCtpjuHMEAOLEkKNym0skxa9e2L4ydP6sl8zo6xUy++ZyVgKW+mmo/ZnL8FEFBRmw9SLYMm7MI9f9+QVNsgY4hPyDoCTDpvtJVCtIZ8jXQL9mRUTRndvFWSlAuOQdIqalXOAYxMeiE7nS+W0bFj9AyzSmHECvks+dIontGYodJKmCcmw7smhoAPC0PjaNMqrHVKxPvr3NVkkvn5lk6yofQcO4Sb+uVAon0q5jTzc4BmHQBLN+Fss/53RLyUb4T/ozvEWVuzwJ3+OAEelBdPenjjZry7F8A1Nsop25umSyudrjQ6DuOhrTmW6maN/TDq5HzAEzbc1wnFS xtGrc1hy IhSTH3qr+jgyQtCwCzosbNyqmP8FjzeQBiWdXzGEdCDi9rZSB1UG7vumvbwMcEHG7FwpLcwhfbU4XhLU9A1HjwgrwQEoGLFdriJz36gJGxE6pi/A70RCikpUUszw8pm7Pzs2E5VaZIadl1fTJ5qRLhzW7HrxlHsv6TGKnab+ACbzGrTCfXh2hE5FSX4waRxEMq3hgCoBINZsGWHnG1fcqM3Vci1lszcR3iggtd7uG/HivLh9Ebn1k42RQLoyhW2iB1mk0y7Uirv6J+22ire33Av/Rd65LjkS/I4gH 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: > > > While we initially thought we can do this unconditionally it turns out > > > that this might break existing workloads that rely on timestamps in very > > > specific ways and we always knew this was a possibility. Move > > > multi-grain timestamps behind a vfs mount option. > > > > Surely this is a safe choice as it moves the responsibility to the sysadmin > > and the cases where finegrained timestamps are required. But I kind of > > wonder how is the sysadmin going to decide whether mgtime is safe for his > > system or not? Because the possible breakage needn't be obvious at the > > first sight... > > > > That's the main reason I really didn't want to go with a mount option. > Documenting that may be difficult. While there is some pessimism around > it, I may still take a stab at just advancing the coarse clock whenever > we fetch a fine-grained timestamp. It'd be nice to remove this option in > the future if that turns out to be feasible. > > > If I were a sysadmin, I'd rather opt for something like > > finegrained timestamps + lazytime (if I needed the finegrained timestamps > > functionality). That should avoid the IO overhead of finegrained timestamps > > as well and I'd know I can have problems with timestamps only after a > > system crash. > > > I've just got another idea how we could solve the problem: Couldn't we > > always just report coarsegrained timestamp to userspace and provide access > > to finegrained value only to NFS which should know what it's doing? > > > > I think that'd be hard. First of all, where would we store the second > timestamp? We can't just truncate the fine-grained ones to come up with > a coarse-grained one. It might also be confusing having nfsd and local > filesystems present different attributes. As far as I can tell we have two options. The first one is to make this into a mount option which I really think isn't a big deal and lets us avoid this whole problem while allowing filesytems exposed via NFS to make use of this feature for change tracking. The second option is that we turn off fine-grained finestamps for v6.6 and you get to explore other options. It isn't a big deal regressions like this were always to be expected but v6.6 needs to stabilize so anything that requires more significant work is not an option.