Message-ID: <CAOQ4uxjTpPPUa3VXW+DWKy72JABOZBCXD6pjNk-FhJZWnqvNPA@mail.gmail.com>
Date: Fri, 29 Sep 2023 06:27:57 +0300
From: Amir Goldstein <amir73il@...il.com>
To: "Darrick J. Wong" <djwong@...nel.org>
Cc: Jeff Layton <jlayton@...nel.org>, Arnd Bergmann <arnd@...db.de>, 
	Alexander Viro <viro@...iv.linux.org.uk>, Christian Brauner <brauner@...nel.org>, 
	Linus Torvalds <torvalds@...ux-foundation.org>, David Sterba <dsterba@...e.cz>, 
	"Theodore Ts'o" <tytso@....edu>, "Eric W. Biederman" <ebiederm@...ssion.com>, Kees Cook <keescook@...omium.org>, 
	Jeremy Kerr <jk@...abs.org>, Michael Ellerman <mpe@...erman.id.au>, Nicholas Piggin <npiggin@...il.com>, 
	Christophe Leroy <christophe.leroy@...roup.eu>, Heiko Carstens <hca@...ux.ibm.com>, 
	Vasily Gorbik <gor@...ux.ibm.com>, Alexander Gordeev <agordeev@...ux.ibm.com>, 
	Christian Borntraeger <borntraeger@...ux.ibm.com>, Sven Schnelle <svens@...ux.ibm.com>, 
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>, Arve Hjønnevåg <arve@...roid.com>, 
	Todd Kjos <tkjos@...roid.com>, Martijn Coenen <maco@...roid.com>, 
	Joel Fernandes <joel@...lfernandes.org>, Carlos Llamas <cmllamas@...gle.com>, 
	Suren Baghdasaryan <surenb@...gle.com>, Mattia Dongili <malattia@...ux.it>, 
	Dennis Dalessandro <dennis.dalessandro@...nelisnetworks.com>, Jason Gunthorpe <jgg@...pe.ca>, 
	Leon Romanovsky <leon@...nel.org>, Brad Warrum <bwarrum@...ux.ibm.com>, 
	Ritu Agarwal <rituagar@...ux.ibm.com>, Hans de Goede <hdegoede@...hat.com>, 
	Ilpo Järvinen <ilpo.jarvinen@...ux.intel.com>, 
	Mark Gross <markgross@...nel.org>, Jiri Slaby <jirislaby@...nel.org>, 
	Eric Van Hensbergen <ericvh@...nel.org>, Latchesar Ionkov <lucho@...kov.net>, 
	Dominique Martinet <asmadeus@...ewreck.org>, Christian Schoenebeck <linux_oss@...debyte.com>, 
	David Sterba <dsterba@...e.com>, David Howells <dhowells@...hat.com>, 
	Marc Dionne <marc.dionne@...istor.com>, Ian Kent <raven@...maw.net>, 
	Luis de Bethencourt <luisbg@...nel.org>, Salah Triki <salah.triki@...il.com>, 
	"Tigran A. Aivazian" <aivazian.tigran@...il.com>, Chris Mason <clm@...com>, 
	Josef Bacik <josef@...icpanda.com>, Xiubo Li <xiubli@...hat.com>, 
	Ilya Dryomov <idryomov@...il.com>, Jan Harkes <jaharkes@...cmu.edu>, coda@...cmu.edu, 
	Joel Becker <jlbec@...lplan.org>, Christoph Hellwig <hch@....de>, Nicolas Pitre <nico@...xnic.net>, 
	"Rafael J . Wysocki" <rafael@...nel.org>, Ard Biesheuvel <ardb@...nel.org>, Gao Xiang <xiang@...nel.org>, 
	Chao Yu <chao@...nel.org>, Yue Hu <huyue2@...lpad.com>, 
	Jeffle Xu <jefflexu@...ux.alibaba.com>, Namjae Jeon <linkinjeon@...nel.org>, 
	Sungjong Seo <sj1557.seo@...sung.com>, Jan Kara <jack@...e.com>, 
	Andreas Dilger <adilger.kernel@...ger.ca>, Jaegeuk Kim <jaegeuk@...nel.org>, 
	OGAWA Hirofumi <hirofumi@...l.parknet.co.jp>, Christoph Hellwig <hch@...radead.org>, 
	Miklos Szeredi <miklos@...redi.hu>, Bob Peterson <rpeterso@...hat.com>, 
	Andreas Gruenbacher <agruenba@...hat.com>, Richard Weinberger <richard@....at>, 
	Anton Ivanov <anton.ivanov@...bridgegreys.com>, Johannes Berg <johannes@...solutions.net>, 
	Mikulas Patocka <mikulas@...ax.karlin.mff.cuni.cz>, Mike Kravetz <mike.kravetz@...cle.com>, 
	Muchun Song <muchun.song@...ux.dev>, Jan Kara <jack@...e.cz>, 
	David Woodhouse <dwmw2@...radead.org>, Dave Kleikamp <shaggy@...nel.org>, Tejun Heo <tj@...nel.org>, 
	Trond Myklebust <trond.myklebust@...merspace.com>, Anna Schumaker <anna@...nel.org>, 
	Chuck Lever <chuck.lever@...cle.com>, Neil Brown <neilb@...e.de>, 
	Olga Kornievskaia <kolga@...app.com>, Dai Ngo <Dai.Ngo@...cle.com>, Tom Talpey <tom@...pey.com>, 
	Ryusuke Konishi <konishi.ryusuke@...il.com>, Anton Altaparmakov <anton@...era.com>, 
	Konstantin Komarov <almaz.alexandrovich@...agon-software.com>, Mark Fasheh <mark@...heh.com>, 
	Joseph Qi <joseph.qi@...ux.alibaba.com>, Bob Copeland <me@...copeland.com>, 
	Mike Marshall <hubcap@...ibond.com>, Martin Brandenburg <martin@...ibond.com>, 
	Luis Chamberlain <mcgrof@...nel.org>, Iurii Zaikin <yzaikin@...gle.com>, Tony Luck <tony.luck@...el.com>, 
	"Guilherme G. Piccoli" <gpiccoli@...lia.com>, Anders Larsen <al@...rsen.net>, Steve French <sfrench@...ba.org>, 
	Paulo Alcantara <pc@...guebit.com>, Ronnie Sahlberg <lsahlber@...hat.com>, 
	Shyam Prasad N <sprasad@...rosoft.com>, Sergey Senozhatsky <senozhatsky@...omium.org>, 
	Phillip Lougher <phillip@...ashfs.org.uk>, Steven Rostedt <rostedt@...dmis.org>, 
	Masami Hiramatsu <mhiramat@...nel.org>, Evgeniy Dushistov <dushistov@...l.ru>, 
	Chandan Babu R <chandan.babu@...cle.com>, Damien Le Moal <dlemoal@...nel.org>, 
	Naohiro Aota <naohiro.aota@....com>, Johannes Thumshirn <jth@...nel.org>, 
	Alexei Starovoitov <ast@...nel.org>, Daniel Borkmann <daniel@...earbox.net>, 
	Andrii Nakryiko <andrii@...nel.org>, Martin KaFai Lau <martin.lau@...ux.dev>, Song Liu <song@...nel.org>, 
	Yonghong Song <yonghong.song@...ux.dev>, John Fastabend <john.fastabend@...il.com>, 
	KP Singh <kpsingh@...nel.org>, Stanislav Fomichev <sdf@...gle.com>, Hao Luo <haoluo@...gle.com>, 
	Jiri Olsa <jolsa@...nel.org>, Hugh Dickins <hughd@...gle.com>, 
	Andrew Morton <akpm@...ux-foundation.org>, "David S . Miller" <davem@...emloft.net>, 
	Eric Dumazet <edumazet@...gle.com>, Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>, 
	John Johansen <john.johansen@...onical.com>, Paul Moore <paul@...l-moore.com>, 
	James Morris <jmorris@...ei.org>, "Serge E. Hallyn" <serge@...lyn.com>, 
	Stephen Smalley <stephen.smalley.work@...il.com>, Eric Paris <eparis@...isplace.org>, 
	linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org, 
	linux-mm@...ck.org, linuxppc-dev@...ts.ozlabs.org, linux-s390@...r.kernel.org, 
	platform-driver-x86@...r.kernel.org, linux-rdma@...r.kernel.org, 
	linux-serial@...r.kernel.org, linux-usb@...r.kernel.org, v9fs@...ts.linux.dev, 
	linux-afs@...ts.infradead.org, autofs@...r.kernel.org, 
	linux-btrfs@...r.kernel.org, ceph-devel@...r.kernel.org, 
	codalist@...a.cs.cmu.edu, linux-efi@...r.kernel.org, 
	linux-erofs@...ts.ozlabs.org, linux-ext4@...r.kernel.org, 
	linux-f2fs-devel@...ts.sourceforge.net, gfs2@...ts.linux.dev, 
	linux-um@...ts.infradead.org, linux-mtd@...ts.infradead.org, 
	jfs-discussion@...ts.sourceforge.net, linux-nfs@...r.kernel.org, 
	linux-nilfs@...r.kernel.org, linux-ntfs-dev@...ts.sourceforge.net, 
	ntfs3@...ts.linux.dev, ocfs2-devel@...ts.linux.dev, 
	linux-karma-devel@...ts.sourceforge.net, devel@...ts.orangefs.org, 
	linux-unionfs@...r.kernel.org, linux-hardening@...r.kernel.org, 
	reiserfs-devel@...r.kernel.org, linux-cifs@...r.kernel.org, 
	samba-technical@...ts.samba.org, linux-trace-kernel@...r.kernel.org, 
	linux-xfs@...r.kernel.org, bpf@...r.kernel.org, 
	Netdev <netdev@...r.kernel.org>, apparmor@...ts.ubuntu.com, 
	linux-security-module@...r.kernel.org, selinux@...r.kernel.org
Subject: Re: [PATCH 86/87] fs: switch timespec64 fields in inode to discrete integers

On Thu, Sep 28, 2023 at 8:19 PM Darrick J. Wong <djwong@...nel.org> 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 <jlayton@...nel.org>
> > >
> > > 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__));
>
> --D
>

Sure we can.
That's what btrfs_inode is for.
vfs inode also does not store i_otime (birth time) and there is even a
precedent of vfs/btrfs variable size mismatch:

        /* full 64 bit generation number, struct vfs_inode doesn't have a big
         * enough field for this.
         */
        u64 generation;

If we decide that vfs should use "bigtime", btrfs pre-historic
timestamps are not a show stopper.

Thanks,
Amir.

Powered by blists - more mailing lists