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 C1EE7CE79A9 for ; Tue, 19 Sep 2023 20:10:56 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 3E3DA6B00CF; Tue, 19 Sep 2023 16:10:56 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 393D26B00D0; Tue, 19 Sep 2023 16:10:56 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 25CF66B00D1; Tue, 19 Sep 2023 16:10:56 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 1A1316B00CF for ; Tue, 19 Sep 2023 16:10:56 -0400 (EDT) Received: from smtpin07.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id E39F61A0596 for ; Tue, 19 Sep 2023 20:10:55 +0000 (UTC) X-FDA: 81254440470.07.8F46AAD Received: from mail.cs.ucla.edu (mail.cs.ucla.edu [131.179.128.66]) by imf27.hostedemail.com (Postfix) with ESMTP id BD63D40026 for ; Tue, 19 Sep 2023 20:10:52 +0000 (UTC) Authentication-Results: imf27.hostedemail.com; dkim=pass header.d=cs.ucla.edu header.s=9D0B346E-2AEB-11ED-9476-E14B719DCE6C header.b=e7FwFS1N; dmarc=pass (policy=none) header.from=cs.ucla.edu; spf=pass (imf27.hostedemail.com: domain of eggert@cs.ucla.edu designates 131.179.128.66 as permitted sender) smtp.mailfrom=eggert@cs.ucla.edu ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1695154253; 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=rkg9tbxTq6pJj5csNug/eDfUxuv8dlZEs8ZxbrqQ+Bs=; b=tObCDzmNk9pu8slgLezrZ8BCCQ068eKiu1khpZHkoyO1S4/O0cByAOIfZ69+z/DRMEcVTz xZVe4rvXQwa/bguq/P8jQe412BSnPMRE+JuXMyOijZsjtKDLZNogsj/tYkIPOQm5drkULs KRiLmQf15oGfAOX6CxOLoBxObDcWswk= ARC-Authentication-Results: i=1; imf27.hostedemail.com; dkim=pass header.d=cs.ucla.edu header.s=9D0B346E-2AEB-11ED-9476-E14B719DCE6C header.b=e7FwFS1N; dmarc=pass (policy=none) header.from=cs.ucla.edu; spf=pass (imf27.hostedemail.com: domain of eggert@cs.ucla.edu designates 131.179.128.66 as permitted sender) smtp.mailfrom=eggert@cs.ucla.edu ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1695154253; a=rsa-sha256; cv=none; b=4ZybJNAXoomxgWop61LvAhGnhyvvyvC+OtyGLAExnTQfhXiHEid+th5WBisi9v00dcJTBs ehjjQzV1ssK1CQ8nPQYDljxmMPYyR/iaNFlztG3qI36W4306FH4ba73TfIYFyW76drH/pe 75f3cmNLFk5OOk7OlYDc7uK2l+Hx2wQ= Received: from localhost (localhost [127.0.0.1]) by mail.cs.ucla.edu (Postfix) with ESMTP id 7F8E73C00D194; Tue, 19 Sep 2023 13:10:50 -0700 (PDT) Received: from mail.cs.ucla.edu ([127.0.0.1]) by localhost (mail.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id AN80LNh6AqGG; Tue, 19 Sep 2023 13:10:50 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.cs.ucla.edu (Postfix) with ESMTP id ED2803C00D193; Tue, 19 Sep 2023 13:10:49 -0700 (PDT) DKIM-Filter: OpenDKIM Filter v2.10.3 mail.cs.ucla.edu ED2803C00D193 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cs.ucla.edu; s=9D0B346E-2AEB-11ED-9476-E14B719DCE6C; t=1695154250; bh=rkg9tbxTq6pJj5csNug/eDfUxuv8dlZEs8ZxbrqQ+Bs=; h=Message-ID:Date:MIME-Version:To:From; b=e7FwFS1NK+ibkS0cG53EL8AQUGclUFwkekbt01t0RrGTfteamSqMsn/mn3buwjYqP Ss5aVs4mQTQ9vMjU5SbCpefiDChbloDYu1HfklTquHXpMe72pT4M6hvyzCQRVAncyf WVOHo5BHpqQpInzk0XI1vkjThUjzXxG9DeoOO1hJGEZWIEF2xR1lMhg3hNLw6eelH3 vfkIEJZDbK4SvwqlaNARiGG/pYA5z0FuwJeduSFWqHIxx4VzcDeiRS6F9+AWa/lvRd UJDA/fA+mrJldEyknr58vHs/9vvVt/ptANUNnDyTfqTMtd8U29s7w3jEOKzFb4QdS+ p/bV3Yp4QSW6g== X-Virus-Scanned: amavisd-new at mail.cs.ucla.edu Received: from mail.cs.ucla.edu ([127.0.0.1]) by localhost (mail.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id gYfshQpOC6VB; Tue, 19 Sep 2023 13:10:49 -0700 (PDT) Received: from [192.168.254.12] (unknown [47.147.225.57]) by mail.cs.ucla.edu (Postfix) with ESMTPSA id C37643C00D18B; Tue, 19 Sep 2023 13:10:48 -0700 (PDT) Message-ID: Date: Tue, 19 Sep 2023 13:10:47 -0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.15.1 Content-Language: en-US To: Jeff Layton , 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 References: <20230807-mgctime-v7-0-d1dec143a704@kernel.org> <20230919110457.7fnmzo4nqsi43yqq@quack3> <1f29102c09c60661758c5376018eac43f774c462.camel@kernel.org> <4511209.uG2h0Jr0uP@nimes> <08b5c6fd3b08b87fa564bb562d89381dd4e05b6a.camel@kernel.org> From: Paul Eggert Organization: UCLA Computer Science Department Subject: Re: [PATCH v7 12/13] ext4: switch to multigrain timestamps In-Reply-To: <08b5c6fd3b08b87fa564bb562d89381dd4e05b6a.camel@kernel.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: BD63D40026 X-Rspam-User: X-Rspamd-Server: rspam05 X-Stat-Signature: 7shenuri7ubu4jphmhpsbh9s1mcyiqjz X-HE-Tag: 1695154252-746018 X-HE-Meta: U2FsdGVkX18wKydfJeWYakj0sO0t6502H4YWQQTVe/yNavtJBPH36U+3WCajd8eQjY3TLzL2sjybVt2uf7lbmFWalvhmjsy1ezA8mpZfs/fjDw4tOMc233r8xQ/v46An+peVZvfLGbq6NnKA+LIzE8lEm8IP+jnMYTPuYSHE69Kz+EooVYhMy7//6uwE3dksV1xdQx/jpyZ852zDvP0YZ7IhTEXtwkbtCdazsz+of0dgjGOROYKSDAuBh3YpD7AmOl8/40v40g4oZEjBCNUsVTaDWAS3A5k3QH9Caj0CvPcK7utjMsOhZujWL4nkHL+Sh0CyCErU7O79LOLJ4ybTHbi6rw2SScegpDYewdFNxadwfZWMmG6avLHcDkIF9dGPVL5lBE0/3tJjR/XlxOg/dqX3Jgs7fbG8QfDL8b/K0COpnO3obtZThqScnlXxmQGGjaQDNYJ7Qgam/0Z8QQ9tE2L9xneA6yFhp5QJl3ONXF7duGEGLOqUmrmzTVCPsaQNrSIaxxGvegh8bmC0kCWi6dTKO/lwpXF4f6sECjm+njvJYGjSMeGzw/defTvZ1JJRdEzom32LC6UyivRX4q5N8cZ+aGzRvqHKfKN4M/+ym8wdeiVU9kETe4KNOtAgvi7XGf12IU9vQS7tgKWQ9Bp7A4mZvQJ+GgwisVGgDgp4Sc4lPXB3PlfALrIjJNmRZBGfwieWnz/WlMDQCgqQpK1X0wQaAYI2f/nwJ399EjBk3UEhBn4ik5AAnzPQcs7Rrntk2osDU+cobaUYY3I0fjIQnSeEW4UmnIRQ5lqfw9CEWY/iVH+ykDZa2XtWnQiSaE72kuZlWpoIvQZhj2vhUvRcYoxeYQQcUQEYvIJdr7VGSifUvGGzr4H3LdRvFWIJO/aGRrNuQ9tflNLMdrHr7kKu4ccaedLhWVG3T76rUDsurxXgzWbxVNZfzjxtKJjPBNS6nSQud6R0kU3zsbU0oS+ tpSHujnM PdSniDyphbY+eUS/6st0vwPxPyLFjlxb7d7eA3UbKntRqaR2zQOor6JnNbunc8qcz961/QTbUYdHFsUs5NrUXQ1vJ1v/r/TUPiUsTrjhF570S3BgEpjUCs9Dh6MuWeLthXYk8eqUUsa0zd4Jy4/uVUKaQ5Jdrww1LD3pbzuKUrrp2rNcXWpl/pwpQc4aa0D0XBCsMEG2fE0wpC3h6hGgUHPVQtGKc3i25R62EqrI/FExDWpGXqgbjIEnesjLAzkCAo5usOI1y2cZjZLQ= 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 2023-09-19 09:31, Jeff Layton wrote: > 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? I vaguely remember running into problems with 'make' a while ago (perhaps with a BSDish system) when filesystem timestamps were arbitrarily truncated in some cases but not others. These files would look older than they really were, so 'make' would think they were up-to-date when they weren't, and 'make' would omit actions that it should have done, thus screwing up the build. File timestamps can be close together with 'make -j' on fast hosts. Sometimes a shell script (or 'make' itself) will run 'make', then modify a file F, then immediately run 'make' again; the latter 'make' won't work if F's timestamp is mistakenly older than targets that depend on it. Although 'make'-like apps are the biggest canaries in this coal mine, the issue also affects 'find -newer' (as Bruno mentioned), 'rsync -u', 'mv -u', 'tar -u', Emacs file-newer-than-file-p, and surely many other places. For example, any app that creates a timestamp file, then backs up all files newer than that file, would be at risk. > 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? Wouldn't this need to be done globally, that is, not just on a per-file or per-filesystem basis? If so, I don't see how we'd avoid locking performance issues. PS. Although I'm no expert in the Linux inode code I hope you don't mind my asking a question about this part of inode_set_ctime_current: /* * If we've recently updated with a fine-grained timestamp, * then the coarse-grained one may still be earlier than the * existing ctime. Just keep the existing value if so. */ ctime.tv_sec = inode->__i_ctime.tv_sec; if (timespec64_compare(&ctime, &now) > 0) return ctime; Suppose root used clock_settime to set the clock backwards. Won't this code incorrectly refuse to update the file's timestamp afterwards? That is, shouldn't the last line be "goto fine_grained;" rather than "return ctime;", with the comment changed from "keep the existing value" to "use a fine-grained value"?