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 bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (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 8711BCE7B08 for ; Thu, 28 Sep 2023 17:41:22 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:MIME-Version:References:In-Reply-To: Date:Cc:To:From:Subject:Message-ID:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=s9rKKgl+gbWPrrE2BVTXEjiKqCNZ4t7Kx4S7tylLYpc=; b=Mx/uFIQbZ5178s NaEFs2Tjz1IcwSlymUD5D7mJmmh5RXCzkiFB5wdLtYMAWQdrdkR10pqLs5ipe3sy4sDplqr3Xq5cS jAoeH0zj4SM5AfCgW7Mb/zzl8dtedHWlQgcWSf81Yiwi2QLgIpYKQ28vlqrwMTKaywld2VvsgN8M8 1Y/1hf64kWpqewv/arYC/sYRFxHcjrZUNi2urEGWTaXeYYb5OS6LtgFt5fao0yeCDRcp8O8zwlZZA EyCSvsuHaD0yUgZMG0yKGSmLvUFaiAKdpSkIiP52qyWec4amdg6IYEtbHYCDIF7YWAj5HYsbHwm77 B76qUoa10SKPEgKmp3Nw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1qlv0m-006Rv4-09; Thu, 28 Sep 2023 17:41:16 +0000 Received: from dfw.source.kernel.org ([2604:1380:4641:c500::1]) by bombadil.infradead.org with esmtps (Exim 4.96 #2 (Red Hat Linux)) id 1qlv0i-006Rtt-2W; Thu, 28 Sep 2023 17:41:14 +0000 Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id B374B61D44; Thu, 28 Sep 2023 17:41:11 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id D74F5C433C7; Thu, 28 Sep 2023 17:40:56 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1695922871; bh=q4Y+iRhQNw28trXDtNOjgA21Uv+IbPAACk59LAWJmZQ=; h=Subject:From:To:Cc:Date:In-Reply-To:References:From; b=Pt2knsyPVF5IN2LrEHFDhKXAMR+bUOcTlyAAG093ma8ffe9kH/u7HXG2g+Td0GQbU dj6xCSvBaMeN3dkuuuxcxsY6aAAFekfxMF19xWrooSEMrmsfY/FrKOmIr30Ef9iwhy 6QfDCUZqE6k5rEywc5Ze8K4/SAUL1W/1QDmSbwueKYxqX2aaIVxDcPqg/lhskw8rFh jOw/ARPQHq26NmwE3QZN+kwE0QI6+60XvzrrVfZo0ayZcNh/tBcZ410YuqL9+lmQQb qZZexkDUvIABncMcV2ChnF/ASLiH8NqVr7NTUG7D+At/G4u0PnSWIbaDK60vBHhtw8 vViGtl0HWhtVQ== Message-ID: <6a6f37d16b55a3003af3f3dbb7778a367f68cd8d.camel@kernel.org> Subject: Re: [PATCH 86/87] fs: switch timespec64 fields in inode to discrete integers From: Jeff Layton To: "Darrick J. Wong" Cc: Arnd Bergmann , Alexander Viro , Christian Brauner , Linus Torvalds , David Sterba , Amir Goldstein , Theodore Ts'o , "Eric W. Biederman" , Kees Cook , Jeremy Kerr , Michael Ellerman , Nicholas Piggin , Christophe Leroy , Heiko Carstens , Vasily Gorbik , Alexander Gordeev , Christian Borntraeger , Sven Schnelle , Greg Kroah-Hartman , Arve =?ISO-8859-1?Q?Hj=F8nnev=E5g?= , Todd Kjos , Martijn Coenen , Joel Fernandes , Carlos Llamas , Suren Baghdasaryan , Mattia Dongili , Dennis Dalessandro , Jason Gunthorpe , Leon Romanovsky , Brad Warrum , Ritu Agarwal , Hans de Goede , Ilpo =?ISO-8859-1?Q?J=E4rvinen?= , Mark Gross , Jiri Slaby , Eric Van Hensbergen , Latchesar Ionkov , Dominique Martinet , Christian Schoenebeck , David Sterba , David Howells , Marc Dionne , Ian Kent , Luis de Bethencourt , Salah Triki , "Tigran A. Aivazian" , Chris Mason , Josef Bacik , Xiubo Li , Ilya Dryomov , Jan Harkes , coda@cs.cmu.edu, Joel Becker , Christoph Hellwig , Nicolas Pitre , "Rafael J . Wysocki" , Ard Biesheuvel , Gao Xiang , Chao Yu , Yue Hu , Jeffle Xu , Namjae Jeon , Sungjong Seo , Jan Kara , Andreas Dilger , Jaegeuk Kim , OGAWA Hirofumi , Christoph Hellwig , Miklos Szeredi , Bob Peterson , Andreas Gruenbacher , Richard Weinberger , Anton Ivanov , Johannes Berg , Mikulas Patocka , Mike Kravetz , Muchun Song , Jan Kara , David Woodhouse , Dave Kleikamp , Tejun Heo , Trond Myklebust , Anna Schumaker , Chuck Lever , Neil Brown , Olga Kornievskaia , Dai Ngo , Tom Talpey , Ryusuke Konishi , Anton Altaparmakov , Konstantin Komarov , Mark Fasheh , Joseph Qi , Bob Copeland , Mike Marshall , Martin Brandenburg , Luis Chamberlain , Iurii Zaikin , Tony Luck , "Guilherme G. Piccoli" , Anders Larsen , Steve French , Paulo Alcantara , Ronnie Sahlberg , Shyam Prasad N , Sergey Senozhatsky , Phillip Lougher , Steven Rostedt , Masami Hiramatsu , Evgeniy Dushistov , Chandan Babu R , Damien Le Moal , Naohiro Aota , Johannes Thumshirn , Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , Martin KaFai Lau , Song Liu , Yonghong Song , John Fastabend , KP Singh , Stanislav Fomichev , Hao Luo , Jiri Olsa , Hugh Dickins , Andrew Morton , "David S . Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , John Johansen , Paul Moore , James Morris , "Serge E. Hallyn" , Stephen Smalley , Eric Paris , linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, linuxppc-dev@lists.ozlabs.org, linux-s390@vger.kernel.org, platform-driver-x86@vger.kernel.org, linux-rdma@vger.kernel.org, linux-serial@vger.kernel.org, linux-usb@vger.kernel.org, v9fs@lists.linux.dev, linux-afs@lists.infradead.org, autofs@vger.kernel.org, linux-btrfs@vger.kernel.org, ceph-devel@vger.kernel.org, codalist@coda.cs.cmu.edu, linux-efi@vger.kernel.org, linux-erofs@lists.ozlabs.org, linux-ext4@vger.kernel.org, linux-f2fs-devel@lists.sourceforge.net, gfs2@lists.linux.dev, linux-um@lists.infradead.org, linux-mtd@lists.infradead.org, jfs-discussion@lists.sourceforge.net, linux-nfs@vger.kernel.org, linux-nilfs@vger.kernel.org, linux-ntfs-dev@lists.sourceforge.net, ntfs3@lists.linux.dev, ocfs2-devel@lists.linux.dev, linux-karma-devel@lists.sourceforge.net, devel@lists.orangefs.org, linux-unionfs@vger.kernel.org, linux-hardening@vger.kernel.org, reiserfs-devel@vger.kernel.org, linux-cifs@vger.kernel.org, samba-technical@lists.samba.org, linux-trace-kernel@vger.kernel.org, linux-xfs@vger.kernel.org, bpf@vger.kernel.org, Netdev , apparmor@lists.ubuntu.com, linux-security-module@vger.kernel.org, selinux@vger.kernel.org Date: Thu, 28 Sep 2023 13:40:55 -0400 In-Reply-To: <20230928171943.GK11439@frogsfrogsfrogs> References: <20230928110554.34758-1-jlayton@kernel.org> <20230928110554.34758-2-jlayton@kernel.org> <6020d6e7-b187-4abb-bf38-dc09d8bd0f6d@app.fastmail.com> <20230928171943.GK11439@frogsfrogsfrogs> User-Agent: Evolution 3.48.4 (3.48.4-1.fc38) MIME-Version: 1.0 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20230928_104112_906828_89AD4F53 X-CRM114-Status: GOOD ( 28.48 ) X-BeenThere: linux-mtd@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Linux MTD discussion mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-mtd" Errors-To: linux-mtd-bounces+linux-mtd=archiver.kernel.org@lists.infradead.org On Thu, 2023-09-28 at 10:19 -0700, Darrick J. Wong wrote: > On Thu, Sep 28, 2023 at 01:06:03PM -0400, Jeff Layton wrote: > > On Thu, 2023-09-28 at 11:48 -0400, Arnd Bergmann wrote: > > > On Thu, Sep 28, 2023, at 07:05, Jeff Layton wrote: > > > > This shaves 8 bytes off struct inode, according to pahole. > > > > > > > > Signed-off-by: Jeff Layton > > > > > > FWIW, this is similar to the approach that Deepa suggested > > > back in 2016: > > > > > > https://lore.kernel.org/lkml/1452144972-15802-3-git-send-email-deepa.kernel@gmail.com/ > > > > > > It was NaKed at the time because of the added complexity, > > > though it would have been much easier to do it then, > > > as we had to touch all the timespec references anyway. > > > > > > The approach still seems ok to me, but I'm not sure it's worth > > > doing it now if we didn't do it then. > > > > > > > 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. Doing that would mean that tests that store specific values in the atime/mtime and expect to be able to fetch exactly that value back would break though, so we'd have to be OK with that if we want to try it. The good news is that it's relatively easy to experiment with new ways to store timestamps with these wrappers in place. -- Jeff Layton ______________________________________________________ Linux MTD discussion mailing list http://lists.infradead.org/mailman/listinfo/linux-mtd/