Received: by 2002:a05:7412:2a8c:b0:e2:908c:2ebd with SMTP id u12csp3618564rdh; Thu, 28 Sep 2023 18:27:50 -0700 (PDT) X-Google-Smtp-Source: AGHT+IHdv2fwdrsPtEn8o5e/HnbWcCGZZjqcJfgZ+aCjf/v2vxvLxDXU/oc8LnugK4itmKMVNVt0 X-Received: by 2002:a05:6e02:1561:b0:350:fa39:168f with SMTP id k1-20020a056e02156100b00350fa39168fmr2784202ilu.32.1695950869601; Thu, 28 Sep 2023 18:27:49 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1695950869; cv=none; d=google.com; s=arc-20160816; b=x6tFNKWeOa6RTcmSMAS2yvs0QKbUCxYLfhbA9quNT/0N7Fs1Dcf0pecxnaqAL6ShHJ YIFHTHqAiHJC8yscJsJE4IMfvnS2zQ5I2LSk4+szfHqYiAWrgH7jCYzLM9j6uYxnIPxc qLHCJBnkw1NXprxzkAt99zelic6yrGFSjQQVsNvgFuSO9RS1X3veTcPSc7Ox4+l62b/v 7wfGhkK+fy6GDmzHqJHGihbV8ECPrlVfuEPYm1KKoPZSrP/tj2Ih/A5ltMuv4WgcCuCt Jm367bqiThMJYq0K1eDMrdysNkoEbkJjteX+D9Jo9tiTQceUb8zuud3P2k+SLKJeRfco Z8GQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:subject:cc:to:from:date:references:in-reply-to :message-id:mime-version:user-agent:feedback-id:dkim-signature :dkim-signature; bh=35hGd5DtemMMIKF1Zr0cZ5jy7ToQQid1yaZKtlkxNu4=; fh=Sse54EolDxVFOznb4GbCm1tnb3Fgu77NK1iT4+O8cQg=; b=sTJ5ofL1Eds1Ib72S16Qe7E9wQHrEcJn9t20PgCrSRdfx2/A8JhNx05YkIlGv/C4Q3 COiRyAneCsUXMq2omgm3Wiwvq+ASt6KLUM8JgscWQ5KtePkN7Jhz8uLJkkUTfabLfG58 f9Fx/Hc0yZ40tWKs9qi7Fzu+IYXFsBC8HwR7au8eyof1yRjsGgV28/xW6lSLY9D7CgVQ 9b+m+XRJ6YBXeinxRCUzBZ3cxZRKPakvsGAA3iDoydXWaNp7hJyKkKc0ZCrI7zGnC/aO 5Kg8r6XirVUZpqNyUTfcgylxZAZS65JIlD8xhemQ/xh4rrSBjgrSx/SHq2P8OtSm17na cFng== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@arndb.de header.s=fm1 header.b=kYePS9tb; dkim=pass header.i=@messagingengine.com header.s=fm2 header.b=Mi38mWEo; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.31 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from morse.vger.email (morse.vger.email. [23.128.96.31]) by mx.google.com with ESMTPS id m187-20020a633fc4000000b005854ee6b62asi6038011pga.543.2023.09.28.18.27.49 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 28 Sep 2023 18:27:49 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.31 as permitted sender) client-ip=23.128.96.31; Authentication-Results: mx.google.com; dkim=pass header.i=@arndb.de header.s=fm1 header.b=kYePS9tb; dkim=pass header.i=@messagingengine.com header.s=fm2 header.b=Mi38mWEo; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.31 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by morse.vger.email (Postfix) with ESMTP id 36D5080A5B76; Thu, 28 Sep 2023 13:22:24 -0700 (PDT) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.10 at morse.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232183AbjI1UVo (ORCPT + 99 others); Thu, 28 Sep 2023 16:21:44 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:54108 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230246AbjI1UVl (ORCPT ); Thu, 28 Sep 2023 16:21:41 -0400 Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 8728219F; Thu, 28 Sep 2023 13:21:38 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 10FFD5C010B; Thu, 28 Sep 2023 16:21:36 -0400 (EDT) Received: from imap51 ([10.202.2.101]) by compute6.internal (MEProxy); Thu, 28 Sep 2023 16:21:36 -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=1695932496; x=1696018896; bh=35 hGd5DtemMMIKF1Zr0cZ5jy7ToQQid1yaZKtlkxNu4=; b=kYePS9tb7iX4DfdsrP KSG5kIGZHZ6II373RLg/R6yievFf5ZYxGwh2bHABIynK2hkA52tpJp3Oqt6Z3WOr EqKj++ONhEZxtgYMqLWXCzvXzNYTY67C+FNTS8BO7KmsYa1dEu2LxNvTTGge5dTC 98J8ERH0LgbaCs96bDreSwTyXJA52oIcXMJdWw5N86IHuBkNDy0oNr/0YRW4bAe/ 0M4666MlVq40oMzm+hOyKlTRfSVgmNV/d/3Ff0cJaJ0SNIaaJnTv2IECtjx7okcZ 2oTzttml5wZkULDWHm+AqgNYcCGYK4B55B9Z6uwZLoNIrGvBjakjMQdqnYhny59X c+DA== 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=1695932496; x=1696018896; bh=35hGd5DtemMMI KF1Zr0cZ5jy7ToQQid1yaZKtlkxNu4=; b=Mi38mWEo6Tol35uWyjeJmmWCT6PhB HqHdQW8+/vTI7Qw8Bqjnf4yascDSnQ3TwDDgcbk0sbZbyRT57QkzfpVhTvQ8tyG/ LToaN9PzpBS9QrAj9YMndKxYandOQbuYzjXUqBNmiENTlTffglDnwu2iuDr2TsU+ /NNGLhQAXePxiL0pEdoLHMSXcoqi6N/AkRauYrgRvDxZcWexBs/kQpWi1R5l+oVf it+YrCNEgaozEQG8vQeVMxdjNU22qXU18zXjjUwBmzzgDSvsRTJJPv6DyBI9Pzys O8qdOCiu0Uk7vB8Y73BLyFXAFOIxbyg1bikunx6mKyaqpJQGWudajkQ0A== 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" Cc: "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" , =?UTF-8?Q?Arve_Hj=C3=B8nnev=C3=A5g?= , "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" , =?UTF-8?Q?Ilpo_J=C3=A4rvinen?= , "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 Subject: Re: [PATCH 86/87] fs: switch timespec64 fields in inode to discrete integers Content-Type: text/plain X-Spam-Status: No, score=-0.9 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on morse.vger.email Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (morse.vger.email [0.0.0.0]); Thu, 28 Sep 2023 13:22:24 -0700 (PDT) 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