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.ozlabs.org (lists.ozlabs.org [112.213.38.117]) (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 8502AE9413E for ; Sat, 7 Oct 2023 01:58:14 +0000 (UTC) Authentication-Results: lists.ozlabs.org; dkim=permerror header.d=arndb.de header.i=@arndb.de header.a=rsa-sha1 header.s=fm1 header.b=K2LkXmC6; dkim=permerror header.d=messagingengine.com header.i=@messagingengine.com header.a=rsa-sha1 header.s=fm2 header.b=LuXVyXF9; dkim-atps=neutral Received: from boromir.ozlabs.org (localhost [IPv6:::1]) by lists.ozlabs.org (Postfix) with ESMTP id 4S2T3918bhz3vYG for ; Sat, 7 Oct 2023 12:58:13 +1100 (AEDT) Authentication-Results: lists.ozlabs.org; dkim=pass (2048-bit key; unprotected) header.d=arndb.de header.i=@arndb.de header.a=rsa-sha256 header.s=fm1 header.b=K2LkXmC6; dkim=pass (2048-bit key; unprotected) header.d=messagingengine.com header.i=@messagingengine.com header.a=rsa-sha256 header.s=fm2 header.b=LuXVyXF9; dkim-atps=neutral Authentication-Results: lists.ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=arndb.de (client-ip=66.111.4.224; helo=new2-smtp.messagingengine.com; envelope-from=arnd@arndb.de; receiver=lists.ozlabs.org) Received: from new2-smtp.messagingengine.com (new2-smtp.messagingengine.com [66.111.4.224]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 4RxPyc440yz3cF1; Fri, 29 Sep 2023 06:21:43 +1000 (AEST) Received: from compute6.internal (compute6.nyi.internal [10.202.2.47]) by mailnew.nyi.internal (Postfix) with ESMTP id 9B93D580A36; Thu, 28 Sep 2023 16:21:38 -0400 (EDT) Received: from imap51 ([10.202.2.101]) by compute6.internal (MEProxy); Thu, 28 Sep 2023 16:21:38 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=arndb.de; h=cc :cc:content-type:content-type:date:date:from:from:in-reply-to :in-reply-to:message-id:mime-version:references:reply-to:sender :subject:subject:to:to; s=fm1; t=1695932498; x=1695939698; bh=35 hGd5DtemMMIKF1Zr0cZ5jy7ToQQid1yaZKtlkxNu4=; b=K2LkXmC6yX3ynAE2K5 /mhtV7/yHI27xGtTL+tb9r+L4fdVUWDnu82xAKY2TmrCJ+8HO4u0wsDUyHM7PkX5 RxdaBJScyNKevwE2qHYYl18GwcimEUhy4r91Tgkb1ai7ANg9ePFW9FzWILz3hBzH 4FpDGmn+3FUH1qJhrE81Ndv7iGHOu9ByGhh5m5et3uDzYrsKWdtXhHI4NNqFgHIo cTVFj1LQVzzO4soFR+D9JmeyVxyHdIeDaC4sxvMXh10gvy/OQi7ggSzfD0gMLd+T i3Oz6mkUesPK9mKQQdf0FjtDoLzIKL+H/dqp5n2Cwyrn9TD9leXPWz8ARpjB6ZmH AEvg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:sender:subject :subject:to:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; t=1695932498; x=1695939698; bh=35hGd5DtemMMI KF1Zr0cZ5jy7ToQQid1yaZKtlkxNu4=; b=LuXVyXF9FXe5kBJhaOeaS1uqYK7h7 BcI4Fr0XY/h4GDfVNtYDrCcALYJX8aCQkQpwvubJXgUz+jqnaOdrVFS/QwChYBBE DIzyhrk6oAGoDjuAV/PBO6VodgWy2OI6FZ42RnQ1e2ZaWSX1CLIPYtWyu74lo1lR 2X3qw6Xe9UiToGzRz2GbH9SrpAszmayI6BM/RLK6g4AH8+QLT3Jml1Zy/g0abMBz BrfUrr819af67Qt95mUdz8NarVqJduBWMvpLscrsR25zblIa2hF278ANh73YSnHi A/dC+7wvDk+6OrA7qE1287nIjJSIS4hQtlI5qLZoux6VXsb3XZP0GbNWQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvkedrtddtgdduudejucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvfevufgtsehttdertderredtnecuhfhrohhmpedftehr nhguuceuvghrghhmrghnnhdfuceorghrnhgusegrrhhnuggsrdguvgeqnecuggftrfgrth htvghrnhepffehueegteeihfegtefhjefgtdeugfegjeelheejueethfefgeeghfektdek teffnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomheprg hrnhgusegrrhhnuggsrdguvg X-ME-Proxy: Feedback-ID: i56a14606:Fastmail Received: by mailuser.nyi.internal (Postfix, from userid 501) id 360CCB60089; Thu, 28 Sep 2023 16:21:35 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.9.0-alpha0-958-g1b1b911df8-fm-20230927.002-g1b1b911d MIME-Version: 1.0 Message-Id: In-Reply-To: <6a6f37d16b55a3003af3f3dbb7778a367f68cd8d.camel@kernel.org> References: <20230928110554.34758-1-jlayton@kernel.org> <20230928110554.34758-2-jlayton@kernel.org> <6020d6e7-b187-4abb-bf38-dc09d8bd0f6d@app.fastmail.com> <20230928171943.GK11439@frogsfrogsfrogs> <6a6f37d16b55a3003af3f3dbb7778a367f68cd8d.camel@kernel.org> Date: Thu, 28 Sep 2023 16:21:12 -0400 From: "Arnd Bergmann" To: "Jeff Layton" , "Darrick J. Wong" Subject: Re: [PATCH 86/87] fs: switch timespec64 fields in inode to discrete integers Content-Type: text/plain X-Mailman-Approved-At: Sat, 07 Oct 2023 12:57:55 +1100 X-BeenThere: linux-erofs@lists.ozlabs.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Development of Linux EROFS file system List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Latchesar Ionkov , Konstantin Komarov , "Rafael J . Wysocki" , Hugh Dickins , Anders Larsen , Carlos Llamas , Andrii Nakryiko , Mattia Dongili , John Johansen , Yonghong Song , Alexander Gordeev , Christoph Hellwig , Mike Marshall , Paulo Alcantara , linux-xfs@vger.kernel.org, Michael Ellerman , James Morris , Christophe Leroy , Christoph Hellwig , Christian Borntraeger , devel@lists.orangefs.org, Shyam Prasad N , linux-um@lists.infradead.org, Nicholas Piggin , Alexander Viro , Eric Van Hensbergen , Suren Baghdasaryan , Trond Myklebust , Anton Altaparmakov , Christian Brauner , Greg Kroah-Hartman , Stephen Smalley , linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org, Ronnie Sahlberg , Sergey Senozhatsky , =?UTF-8?Q?Arve_Hj=C3=B8nnev=C3=A5g?= , Chuck Lever , Sven Schnelle , Jiri Olsa , Jan Kara , Tejun Heo , Andrew Morton , linux-trace-kernel@vger.kernel.org, Linus Torvalds , Dave Kleikamp , linux-mm@kvack.org, Joel Fernandes , Eric Dumazet , Stanislav Fomichev , linux-s390@vger.kernel.org, linux-nilfs@vger.kernel.org, Paul Moore , Leon Romanovsky , John Fastabend , Luis Chamberlain , codalist@coda.cs.cmu.edu, Iurii Zaikin , Namjae Jeon , Masami Hiramatsu , Todd Kjos , Vasily Gorbik , selinux@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, reiserfs-devel@vger.kernel.org, Miklos Szeredi , Yue Hu , Jaegeuk Kim , Martijn Coenen , OGAWA Hirofumi , Hao Luo , Tony Luck , Theodore Ts'o , Nicolas Pitre , linux-ntfs-dev@lists.sourceforge.net, Muchun Song , linux-f2fs-devel@lists.sourceforge.net, "Guilherme G. Piccoli" , gfs2@lists.linux.dev, "Eric W. Biederman" , Anna Schumaker , Brad Warrum , Mike Kravetz , linux-efi@vger.kernel.org, Martin Brandenburg , ocfs2-devel@lists.linux.dev, Alexei Starovoitov , platform-driver-x86@vger.kernel.org, Chris Mason , linux-mtd@lists.infradead.org, linux-hardening@vger.kernel.org, Marc Dionne , Jiri Slaby , linux-afs@lists.infradead.org, Ian Kent , Naohiro Aota , Daniel Borkmann , Dennis Dalessandro , linux-rdma@vger.kernel.org, coda@cs.cmu.edu, =?UTF-8?Q?Ilpo_J=C3=A4rvinen?= , Ilya Dryomov , Paolo Abeni , "Serge E. Hallyn" , Christian Schoenebeck , Kees Cook , autofs@vger.kernel.org, Steven Rostedt , Mark Gross , Damien Le Moal , Eric Paris , ceph-devel@vger.kernel.org, Jan Harkes , linux-nfs@vger.kernel.org, linux-ext4@vger.kernel.org, Olga Kornievskaia , Song Liu , samba-technical@lists.samba.org, Steve French , Jeremy Kerr , Netdev , Bob Peterson , linux-fsdevel@vger.kernel.org, bpf@vger.kernel.org, ntfs3@lists.linux.dev, linux-erofs@lists.ozlabs.org, "David S . Miller" , Chandan Babu R , jfs-discussion@lists.sourceforge.net, Jan Kara , Neil Brown , Dominique Martinet , Amir Goldstein , Bob Copeland , KP Singh , linux-unionfs@vger.kernel.org, David Howells , Joseph Qi , Andreas Dilger , Mikulas Patocka , Ard Biesheuvel , Anton Ivanov , Andreas Gruenbacher , Richard Weinberger , Mark Fasheh , Dai Ngo , Jason Gunthorpe , linux-serial@vger.kernel.org, Jakub Kicinski , Salah Triki , Evgeniy Dushistov , linux-cifs@vger.kernel.org, Heiko Carstens , apparmor@lists.ubuntu.com, Josef Bacik , Tom Talpey , Hans de Goede , "Tigran A. Aivazian" , David Sterba , Xiubo Li , Ryusuke Konishi , Johannes Thumshirn , Ritu Agarwal , Luis de Bethencourt , Martin KaFai Lau , v9fs@lists.linux .dev, David Sterba , linux-security-module@vger.kernel.org, Phillip Lougher , Johannes Berg , Sungjong Seo , David Woodhouse , linux-karma-devel@lists.sourceforge.net, linux-btrfs@vger.kernel.org, Joel Becker Errors-To: linux-erofs-bounces+linux-erofs=archiver.kernel.org@lists.ozlabs.org Sender: "Linux-erofs" On Thu, Sep 28, 2023, at 13:40, Jeff Layton wrote: > On Thu, 2023-09-28 at 10:19 -0700, Darrick J. Wong wrote: >> >> > I remember seeing those patches go by. I don't remember that change >> > being NaK'ed, but I wasn't paying close attention at the time >> > >> > Looking at it objectively now, I think it's worth it to recover 8 bytes >> > per inode and open a 4 byte hole that Amir can use to grow the >> > i_fsnotify_mask. We might even able to shave off another 12 bytes >> > eventually if we can move to a single 64-bit word per timestamp. >> >> I don't think you can, since btrfs timestamps utilize s64 seconds >> counting in both directions from the Unix epoch. They also support ns >> resolution: >> >> struct btrfs_timespec { >> __le64 sec; >> __le32 nsec; >> } __attribute__ ((__packed__)); >> > > Correct. We'd lose some fidelity in currently stored timestamps, but as > Linus and Ted pointed out, anything below ~100ns granularity is > effectively just noise, as that's the floor overhead for calling into > the kernel. It's hard to argue that any application needs that sort of > timestamp resolution, at least with contemporary hardware. There are probably applications that have come up with creative ways to use the timestamp fields of file systems that 94 bits of data, with both the MSB of the seconds and the LSB of the nanoseconds carrying information that they expect to be preserved. Dropping any information in the nanoseconds other than the top two bits would trivially change the 'ls -t' output when two files have the same timestamp in one kernel but slightly different timestamps in another one. For large values of 'tv_sec', there are fewer obvious things that break, but if current kernels are able to retrieve arbitrary times that were stored with utimensat(), then we should probably make sure future kernels can see the same. Arnd