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 39D08CE79AF for ; Wed, 20 Sep 2023 09:58:22 +0000 (UTC) Received: from [127.0.0.1] (helo=sfs-ml-1.v29.lw.sourceforge.com) by sfs-ml-1.v29.lw.sourceforge.com with esmtp (Exim 4.95) (envelope-from ) id 1qityO-0000DD-LO; Wed, 20 Sep 2023 09:58:19 +0000 Received: from [172.30.20.202] (helo=mx.sourceforge.net) by sfs-ml-1.v29.lw.sourceforge.com with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.95) (envelope-from ) id 1qityN-0000D7-EB for linux-f2fs-devel@lists.sourceforge.net; Wed, 20 Sep 2023 09:58:18 +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=5cx/4/QTnSQH/xoBZtq0Dbb3QvNNJW5HvvEMLfrjPF8=; b=FN9Ff15igg//QmTK098r1ruqiT QwmUSd5IpuckucWKHu2ZOmd5cYRWlwWaOErcV/DBcNCbbPl6og8GKEQk3FKoWDJYaa+cvJ7YuyAoy sEwGPGnpAxFBpYjLWRqEu7FUZtb0hZsjBbAup8PP0a3mZbn/2e3bV6aaOPhbHEIcnGIo=; 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=5cx/4/QTnSQH/xoBZtq0Dbb3QvNNJW5HvvEMLfrjPF8=; b=MrEUaZTMCu927nGpXYoAXntPUX E7HJAyE1qBBvuZCBy4tq4DYvI9t7k1cDlb9XCvlgh1kjcTHRtKo8kJMdg1jHZkUPqspCNCeQ0KAMn Yj2BNWU1xGGo4EuuAVr4CFVNyXVrSejZrWVQ5uUhQ+APL6gcEKPV9dfDgl4lwrFZwrpQ=; Received: from smtp-out2.suse.de ([195.135.220.29]) by sfi-mx-2.v28.lw.sourceforge.com with esmtps (TLS1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.95) id 1qityK-0002ff-KB for linux-f2fs-devel@lists.sourceforge.net; Wed, 20 Sep 2023 09:58:18 +0000 Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by smtp-out2.suse.de (Postfix) with ESMTPS id 3BDE31FEB5; Wed, 20 Sep 2023 09:58:09 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_rsa; t=1695203889; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=5cx/4/QTnSQH/xoBZtq0Dbb3QvNNJW5HvvEMLfrjPF8=; b=BYHC4/FQp0jOPuSZahj4EmBcrB6WqWWyb6bVG4tzLJvtQOD6FLAr0dDhpQkR6V1shi0Mhn Wnl16oS1oija7d9fXqGCmLn/ra7ZBIyWecE/f8BKE4QEvWRM8DTlr0qUeJQBIy74OP3jId Xr35EzHqpCVb2+JvJzh1fo4PASSm4UY= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_ed25519; t=1695203889; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=5cx/4/QTnSQH/xoBZtq0Dbb3QvNNJW5HvvEMLfrjPF8=; b=Inurd+QUrEWmA0gt+rtqxZtUQzsEAGSeU+EJGHN4fUZvLVNJlZX/VLCNUyqlPc1A4HF+Lq dsq7y3KAnJwsQfCA== Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by imap2.suse-dmz.suse.de (Postfix) with ESMTPS id 2502313A64; Wed, 20 Sep 2023 09:58:09 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id RdgECTHCCmUJCAAAMHmgww (envelope-from ); Wed, 20 Sep 2023 09:58:09 +0000 Received: by quack3.suse.cz (Postfix, from userid 1000) id B20DAA077D; Wed, 20 Sep 2023 11:58:08 +0200 (CEST) Date: Wed, 20 Sep 2023 11:58:08 +0200 From: Jan Kara To: Jeff Layton Message-ID: <20230920095808.x2gurkdgbrqoumir@quack3> References: <20230807-mgctime-v7-0-d1dec143a704@kernel.org> <20230919110457.7fnmzo4nqsi43yqq@quack3> <1f29102c09c60661758c5376018eac43f774c462.camel@kernel.org> <4511209.uG2h0Jr0uP@nimes> <08b5c6fd3b08b87fa564bb562d89381dd4e05b6a.camel@kernel.org> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <08b5c6fd3b08b87fa564bb562d89381dd4e05b6a.camel@kernel.org> X-Headers-End: 1qityK-0002ff-KB 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 , Christian Brauner , 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-nfs@vger.kernel.org, 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 On Tue 19-09-23 12:31:08, Jeff Layton wrote: > 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. > > > > This is only of secondary importance, because the scenario by Jan Kara > > shows a much more fundamental breakage: > > > > > > The ultimate problem is that a sequence like: > > > > > > > > write(f1) > > > > stat(f2) > > > > write(f2) > > > > stat(f2) > > > > write(f1) > > > > stat(f1) > > > > > > > > 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 compare > > > > timestamps between two files. Jeff? > > > > > > > > > > Basically yes. > > > > f1 was last written to *after* f2 was last written to. If the timestamp of f1 > > is then lower than the timestamp of f2, timestamps are fundamentally broken. > > > > Many things in user-space depend on timestamps, such as build system > > centered around 'make', but also 'find ... -newer ...'. > > > > > 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. TL;DR I don't think we can just wave away the change as "the problem has always been there". Firstly, the fact that something is not quite reliable on NFS doesn't mean people don't rely on the behavior on local filesystems. NFS has a historical reputation of being a bit weird ;). Secondly, I agree that the same problems can manifest currently for files on two filesystems with different timestamp granularity. But again that is something that is rare - widely used filesystems have a granularity of a jiffy and in most cases build and source files are on the same filesystem anyway. So yes, in principle the problems could happen even before multigrain timestamps but having different granularity per inode just made them manifest in much much more setups and that matters because setups that were perfectly fine before are not anymore. > 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: Regarding whether the problem is real: I wouldn't worry too much about the particular test that started this thread. That seems like something very special. But the build system issues could be real - as you wrote in your motivation for the series - a lot can happen in a jiffy on contemporary computers. I can imagine build product having newer timestamp than build source because the modification of source managed to squeeze into the same jiffy and still use a coarse-grained timestamp. Or some other producer-consumer type of setup... Sure usually there would be enough stat(2) calls on both sides to force finegrained timestamps on both files but if there are not in some corner case, debugging the problem is really tough. > 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. >From a first glance I'd guess the performance overhead will be too big for a busy filesystem to enable this unconditionally. But I could be wrong... Honza -- Jan Kara SUSE Labs, CR _______________________________________________ Linux-f2fs-devel mailing list Linux-f2fs-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel