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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 63A26E728C9 for ; Fri, 29 Sep 2023 16:47:15 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233141AbjI2QrP (ORCPT ); Fri, 29 Sep 2023 12:47:15 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:38286 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232748AbjI2QrO (ORCPT ); Fri, 29 Sep 2023 12:47:14 -0400 Received: from mail-lf1-x12c.google.com (mail-lf1-x12c.google.com [IPv6:2a00:1450:4864:20::12c]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D0928D6 for ; Fri, 29 Sep 2023 09:47:11 -0700 (PDT) Received: by mail-lf1-x12c.google.com with SMTP id 2adb3069b0e04-50337b43ee6so23224276e87.3 for ; Fri, 29 Sep 2023 09:47:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=google; t=1696006030; x=1696610830; darn=vger.kernel.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=1jnYTA/sVS+Z8Orhdi2AQdhdCY0rlD66I6Sde9ZBPos=; b=LPqesg57Z7PdJmAVFjfFM5OVTj5/wbGJ2/3b24ngvcCNEZGknguX50mFJODcJ+2XBE P5LB7HYZ5PNco0gcSRxpJZdfCGiCoNciUq2A0Q3drSE522fIMmHDGJIPshnzjl+XFKuA cIgpkhTu8aL/0EwCoUivy3hWDhuDZfPcan0cY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1696006030; x=1696610830; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=1jnYTA/sVS+Z8Orhdi2AQdhdCY0rlD66I6Sde9ZBPos=; b=dtdozAMqB6X5OvwMlxqyAo4gQ9RwHfVYbZ79a17tMNRqkuVzBfQs/HIHDK7q6WI13V eV7dPvvpy5E68iTBhkL0R8czZrjCpqvf+SUjKDuw3FZ6AuUMB4nJnjcC1QVH7LVpbq2D Pp4xlSCKin7pjtv8dtI0S9Y0f/1rvRdEdFV7fHKhJ6oPoFT9o4AbVVhOZCABe/HUbWlq AHKph9ORsLBTJHgBchd9msJvlLNWkSMcHPPRBey4p095TrTs/REbyIgQNsbZVAjLDx1o pLnSU30VfDdlaU+PxZYAnmSh8S+1N9KOOCBde+VpCmEVTdDd+0S9ix9D0ABmJ49OtMUv bVew== X-Gm-Message-State: AOJu0YwzIUnLSPgQoiYL86LZokHgj2V25GzK1ZR1Sg1J+1/G80c6Dljc P4CiQ8IEV8Z32z/A10sBEBDFPV1aZDAb6ZYwE2oQZDqodMA= X-Google-Smtp-Source: AGHT+IGTQy1TLOMzN+HiN2Wh/a+1/Kvk9rGRHENm44DIcrMokPHn6+XfcTM6b7Bs1v0UPa8t/HcjSQ== X-Received: by 2002:a05:6512:2808:b0:503:2623:7cfa with SMTP id cf8-20020a056512280800b0050326237cfamr4656635lfb.35.1696006029873; Fri, 29 Sep 2023 09:47:09 -0700 (PDT) Received: from mail-lf1-f54.google.com (mail-lf1-f54.google.com. [209.85.167.54]) by smtp.gmail.com with ESMTPSA id b20-20020ac247f4000000b00502d9af34aesm3591176lfp.120.2023.09.29.09.47.09 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 29 Sep 2023 09:47:09 -0700 (PDT) Received: by mail-lf1-f54.google.com with SMTP id 2adb3069b0e04-503056c8195so23217965e87.1 for ; Fri, 29 Sep 2023 09:47:09 -0700 (PDT) X-Received: by 2002:a17:907:2722:b0:9a1:cdf1:ba3 with SMTP id d2-20020a170907272200b009a1cdf10ba3mr4628345ejl.27.1696004552316; Fri, 29 Sep 2023 09:22:32 -0700 (PDT) MIME-Version: 1.0 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> <20230928212656.GC189345@mit.edu> In-Reply-To: From: Linus Torvalds Date: Fri, 29 Sep 2023 09:22:14 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH 86/87] fs: switch timespec64 fields in inode to discrete integers To: Amir Goldstein Cc: "Theodore Ts'o" , Jeff Layton , "Darrick J. Wong" , Arnd Bergmann , Alexander Viro , Christian Brauner , David Sterba , "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?B?QXJ2ZSBIasO4bm5ldsOlZw==?= , 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@telemann.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 Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-xfs@vger.kernel.org On Thu, 28 Sept 2023 at 20:50, Amir Goldstein wrote: > > OTOH, it is perfectly fine if the vfs wants to stop providing sub 100ns > services to filesystems. It's just going to be the fs problem and the > preserved pre-historic/fine-grained time on existing files would only > need to be provided in getattr(). It does not need to be in __i_mtime. Hmm. That sounds technically sane, but for one thing: if the aim is to try to do (a) atomic timestamp access (b) shrink the inode then having the filesystem maintain its own timestamp for fine-grained data will break both of those goals. Yes, we'd make 'struct inode' smaller if we pack the times into one 64-bit entity, but if btrfs responds by adding mtime fields to "struct btrfs_inode", we lost the size advantage and only made things worse. And if ->getattr() then reads those fields without locking (and we definitely don't want locking in that path), then we lost the atomicity thing too. So no. A "but the filesystem can maintain finer granularity" model is not acceptable, I think. If we do require nanoseconds for compatibility, what we could possibly do is say "we guarantee nanosecond values for *legacy* dates", and say that future dates use 100ns resolution. We'd define "legacy dates" to be the traditional 32-bit signed time_t. So with a 64-bit fstime_t, we'd have the "legacy format": - top 32 bits are seconds, bottom 32 bits are ns which gives us that ns format. Then, because only 30 bits are needed for nanosecond resolution, we use the top two bits of that ns field as flags. '00' means that legacy format, and '01' would mean "we're not doing nanosecond resolution, we're doing 64ns resolution, and the low 6 bits of the ns field are actually bits 32-37 of the seconds field". That still gives us some extensibility (unless the multi-grain code still wants to use the other top bit), and it gives us 40 bits of seconds, which is quite a lot. And all the conversion functions will be simple bit field manipulations, so there are no expensive ops here. Anyway, I agree with the "let's introduce the accessor functions first, we can do the 'pack into one word' decisions later". Linus