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 lists.sourceforge.net (lists.sourceforge.net [216.105.38.7]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id C6AB2CE79D0 for ; Wed, 20 Sep 2023 11:49:32 +0000 (UTC) Received: from [127.0.0.1] (helo=sfs-ml-3.v29.lw.sourceforge.com) by sfs-ml-3.v29.lw.sourceforge.com with esmtp (Exim 4.95) (envelope-from ) id 1qivhz-0002XH-DH; Wed, 20 Sep 2023 11:49:29 +0000 Received: from [172.30.20.202] (helo=mx.sourceforge.net) by sfs-ml-3.v29.lw.sourceforge.com with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.95) (envelope-from ) id 1qivhx-0002XB-Gl for linux-f2fs-devel@lists.sourceforge.net; Wed, 20 Sep 2023 11:49:28 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=sourceforge.net; s=x; h=In-Reply-To:Content-Type:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=KOwFYJFVauAzGdLHiygCqgNB24b8lWzTQA0Uqsb4joQ=; b=T2lwssEoD7KkmGWPMVI6fUsd0l /6Kyp/0dbmTj/4DTPO6CPl8wfnf71iFG4wS97gt+OG3Y9hJV49tIeFwCfbWxofeomXNaf6RfsCDf5 jkNGJhoS+YOUzOOHJ3a43pSTI6bBbkrTM3HDudiLx2KESqxSuCwGTpGXXtqy5WxCsfy8=; DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=sf.net; s=x ; h=In-Reply-To:Content-Type:MIME-Version:References:Message-ID:Subject:Cc:To :From:Date:Sender:Reply-To:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=KOwFYJFVauAzGdLHiygCqgNB24b8lWzTQA0Uqsb4joQ=; b=a/p+jfohl3ujyJQAgka3Htd9W6 EELnTV4J7pxhHxxwGAatpvdCez0ClRmMUWunV8fboFoWOGY/OBkUvHEGfwdWCW4m554EX3AYbBdUq 1iHVcHgjV1zu8r/uSi64PzwG+GqDsFCAv7Y/uKVgBh82GFJX/oFm6kUXFfHz/2GgDspI=; Received: from ams.source.kernel.org ([145.40.68.75]) by sfi-mx-2.v28.lw.sourceforge.com with esmtps (TLS1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.95) id 1qivhu-00012m-Ve for linux-f2fs-devel@lists.sourceforge.net; Wed, 20 Sep 2023 11:49:27 +0000 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 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-Disposition: inline In-Reply-To: <317d84b1b909b6c6519a2406fcb302ce22dafa41.camel@kernel.org> X-Headers-End: 1qivhu-00012m-Ve Subject: Re: [f2fs-dev] [PATCH v7 12/13] ext4: switch to multigrain timestamps X-BeenThere: linux-f2fs-devel@lists.sourceforge.net X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Latchesar Ionkov , Martin Brandenburg , Konstantin Komarov , Jan Kara , linux-xfs@vger.kernel.org, "Darrick J. Wong" , Dominique Martinet , Christian Schoenebeck , linux-unionfs@vger.kernel.org, David Howells , Chris Mason , Andreas Dilger , Hans de Goede , Marc Dionne , codalist@coda.cs.cmu.edu, linux-afs@lists.infradead.org, linux-mtd@lists.infradead.org, Mike Marshall , Paulo Alcantara , Amir Goldstein , Eric Van Hensbergen , bug-gnulib@gnu.org, Andreas Gruenbacher , Miklos Szeredi , Richard Weinberger , Mark Fasheh , Hugh Dickins , Benjamin Coddington , Tyler Hicks , cluster-devel@redhat.com, coda@cs.cmu.edu, linux-mm@kvack.org, Gao Xiang , Iurii Zaikin , Namjae Jeon , Trond Myklebust , Xi Ruoyao , Shyam Prasad N , ecryptfs@vger.kernel.org, Kees Cook , ocfs2-devel@lists.linux.dev, linux-cifs@vger.kernel.org, linux-erofs@lists.ozlabs.org, Josef Bacik , Tom Talpey , Tejun Heo , Yue Hu , Alexander Viro , Ronnie Sahlberg , David Sterba , Jaegeuk Kim , ceph-devel@vger.kernel.org, Xiubo Li , Ilya Dryomov , OGAWA Hirofumi , Jan Harkes , linux-nfs@vger.kernel.org, linux-ext4@vger.kernel.org, Theodore Ts'o , Joseph Qi , Greg Kroah-Hartman , v9fs@lists.linux.dev, ntfs3@lists.linux.dev, samba-technical@lists.samba.org, linux-kernel@vger.kernel.org, linux-f2fs-devel@lists.sourceforge.net, Steve French , Sergey Senozhatsky , Luis Chamberlain , Jeffle Xu , devel@lists.orangefs.org, Anna Schumaker , Jan Kara , Bo b Peterson , linux-fsdevel@vger.kernel.org, Andrew Morton , Sungjong Seo , Bruno Haible , linux-btrfs@vger.kernel.org, Joel Becker Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: linux-f2fs-devel-bounces@lists.sourceforge.net > > > 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. _______________________________________________ Linux-f2fs-devel mailing list Linux-f2fs-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel