Message-Id: <ded0ef74-bdad-42f2-b0a7-5d867e446c19@app.fastmail.com>
Date: Thu, 28 Sep 2023 16:21:12 -0400
From: "Arnd Bergmann" <arnd@...db.de>
To: "Jeff Layton" <jlayton@...nel.org>, "Darrick J. Wong" <djwong@...nel.org>
Cc: "Alexander Viro" <viro@...iv.linux.org.uk>,
 "Christian Brauner" <brauner@...nel.org>,
 "Linus Torvalds" <torvalds@...ux-foundation.org>,
 "David Sterba" <dsterba@...e.cz>, "Amir Goldstein" <amir73il@...il.com>,
 "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 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

Powered by blists - more mailing lists