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 kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 8B39AC00A8F for ; Tue, 24 Oct 2023 04:10:58 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id D8CF66B0177; Tue, 24 Oct 2023 00:10:57 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id D169E6B0178; Tue, 24 Oct 2023 00:10:57 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id BB64F6B0179; Tue, 24 Oct 2023 00:10:57 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id A92E66B0177 for ; Tue, 24 Oct 2023 00:10:57 -0400 (EDT) Received: from smtpin28.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 79BC0A0C6B for ; Tue, 24 Oct 2023 04:10:57 +0000 (UTC) X-FDA: 81379029354.28.6CC27A8 Received: from mail-ed1-f48.google.com (mail-ed1-f48.google.com [209.85.208.48]) by imf02.hostedemail.com (Postfix) with ESMTP id 7817980008 for ; Tue, 24 Oct 2023 04:10:55 +0000 (UTC) Authentication-Results: imf02.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=google header.b=PsCk7hel; dmarc=none; spf=pass (imf02.hostedemail.com: domain of torvalds@linuxfoundation.org designates 209.85.208.48 as permitted sender) smtp.mailfrom=torvalds@linuxfoundation.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1698120655; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=R/DnLkXKcbtHeIdj2lNteiEcRFjQW0/FCeNT137Lkzs=; b=VVRc+dmeymVXPcO7OBe6KM3WVznMx+OKowuZDfo9kK+I7iG7sbSua7BljaRh9nTRhsiNiY o6kQfw7w/rCGUnfaEXdSOOVZT9BS+OD/Yj5QtUrVDOPdoe155soRwLHH2NEHxVN5An+DcK fbjTG5EXlyNo2+cQsV371h/vMjC9+PE= ARC-Authentication-Results: i=1; imf02.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=google header.b=PsCk7hel; dmarc=none; spf=pass (imf02.hostedemail.com: domain of torvalds@linuxfoundation.org designates 209.85.208.48 as permitted sender) smtp.mailfrom=torvalds@linuxfoundation.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1698120655; a=rsa-sha256; cv=none; b=Brb/uaHz9ROG7S02RFEwulv4KU6Ho88F2Q+8JIgd59tc5JrAuVnQHGXqqn4Jc5TicGFS+H pAaeBi4lsOw2AJYW9tOA8g2K0mBNpf4WhIG7c3aW+obpW1pzC3aLlA9WdhWmbmAQhKdRTx m+eVWAGYgsxhRTeplgjS6VzvLcIUk58= Received: by mail-ed1-f48.google.com with SMTP id 4fb4d7f45d1cf-53e3e7e478bso6019743a12.0 for ; Mon, 23 Oct 2023 21:10:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=google; t=1698120654; x=1698725454; darn=kvack.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=R/DnLkXKcbtHeIdj2lNteiEcRFjQW0/FCeNT137Lkzs=; b=PsCk7hellmCC62ghLrnkj0pzmUWHiII8KWh5Fbx1PyuwMhjAMeEuB699GQhtowuEZK xc7zBkwoFjzJEtsmzoLmBA7GE15+NxUxqABkbAklXd0swdYLLib8Iio4d/QUldXWwZk2 6eP5lZ1UuKAv9VSWALiQEdYaDIvGt+T33le2w= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1698120654; x=1698725454; 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=R/DnLkXKcbtHeIdj2lNteiEcRFjQW0/FCeNT137Lkzs=; b=CMYA7CbmjEH0WClqOBP/epH045IGqcoDPXWiVFicfAODkvPu/PLDYYHqu2PirLhoNE 13LN/1Nd6zLI+XtzGNOiweXCm2f4oIKELKmtsWk+Hd5w+dEwD34PADuhkoEKj/J1C34s hS8w3d1qj7FU4Cb6ctJu1uyL4sSSTVR6ez8ZS1X0z8AWWfU+G5hI5XoSbxGNEw1WVwk1 Y2d36U0yUxgS8HYPGiS+insKyjm3HskxTsG8tinRACfnmZumBBmXTKXF3cml40ov5P8O /9yxj/GjBG6taYlCbT2aTwy4ZPON33V2x8g3gYRwRfozQvJLfa/oVjc6gm3oxtNAeTs4 Ar+A== X-Gm-Message-State: AOJu0YyrmmEIoT2WYh1I/nP5V5dTFUPJCPbcyOCV0Q6OUBvmVaUrHhdS zp7gVlIelK8oInlof7z1KOvMzeehFgtGG2j8O8+bMnu1 X-Google-Smtp-Source: AGHT+IENSW6YCgeWnOGSP0qGcgjE6Hc1tm0AcGbh439ZUsqO0kNWOHIO5k6Ta1OJCxcnbVPdZnRNsg== X-Received: by 2002:a50:d556:0:b0:53e:7ba3:9b1b with SMTP id f22-20020a50d556000000b0053e7ba39b1bmr8297519edj.8.1698120653749; Mon, 23 Oct 2023 21:10:53 -0700 (PDT) Received: from mail-wr1-f47.google.com (mail-wr1-f47.google.com. [209.85.221.47]) by smtp.gmail.com with ESMTPSA id 23-20020a508e17000000b0053df23511b0sm7305494edw.29.2023.10.23.21.10.53 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 23 Oct 2023 21:10:53 -0700 (PDT) Received: by mail-wr1-f47.google.com with SMTP id ffacd0b85a97d-32da7ac5c4fso2763694f8f.1 for ; Mon, 23 Oct 2023 21:10:53 -0700 (PDT) X-Received: by 2002:a05:6402:274e:b0:53e:8e09:524d with SMTP id z14-20020a056402274e00b0053e8e09524dmr2329463edd.5.1698120632873; Mon, 23 Oct 2023 21:10:32 -0700 (PDT) MIME-Version: 1.0 References: <5f96e69d438ab96099bb67d16b77583c99911caa.camel@kernel.org> <20231019-fluor-skifahren-ec74ceb6c63e@brauner> <0a1a847af4372e62000b259e992850527f587205.camel@kernel.org> <61b32a4093948ae1ae8603688793f07de764430f.camel@kernel.org> In-Reply-To: From: Linus Torvalds Date: Mon, 23 Oct 2023 18:10:15 -1000 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH RFC 2/9] timekeeping: new interfaces for multigrain timestamp handing To: Dave Chinner Cc: Jeff Layton , Kent Overstreet , Christian Brauner , Alexander Viro , John Stultz , Thomas Gleixner , Stephen Boyd , Chandan Babu R , "Darrick J. Wong" , "Theodore Ts'o" , Andreas Dilger , Chris Mason , Josef Bacik , David Sterba , Hugh Dickins , Andrew Morton , Amir Goldstein , Jan Kara , David Howells , linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, linux-xfs@vger.kernel.org, linux-ext4@vger.kernel.org, linux-btrfs@vger.kernel.org, linux-mm@kvack.org, linux-nfs@vger.kernel.org Content-Type: text/plain; charset="UTF-8" X-Rspam-User: X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: 7817980008 X-Stat-Signature: ffy5circstccmdn99b5yaux3yctoduyc X-HE-Tag: 1698120655-31013 X-HE-Meta: U2FsdGVkX1+1mk3lQphSZItuIkQwhzX5K/Vf4uqet7/IODL/5UFJHR63F6aWZFEjHIAfxhITjzhWDiZ6zoGtLGUOI9A3DEJJIl6RykKGSgLSGpJDpogtXp46ySBBPcJhnracB4U4aD5hMP6C4utNg4DfG0SvWlOThSYmnj+48/5XrCfQlH3AVd4pcAyCj/TPe+zrcflU5icqh45uupNlIgEC1pOJO6JCUP8A2BMaFuT1N7i09vvAw3p6yFtyzc3ezxEHzpNUx6xS8sLxdhkn2cqZsw3+qPdWz5QPeEZ/4v24+fZiZcHtfOhXv8HA2zTnLrpi6jA6PIuWTnuaCSLoV07TGynOp11om8GeGqKUu9MH8tStQCG5hTMcf0mtD1rEUDdtsotr/tbwa31vbKA0uH5tM2fPfL9OIsBu/yTyapAlmx6Aj4ZFAyX2o0yPaIt60a9m8EAtgYjZLLm1oylx5+DlaJ+UThSufi3ua+nGKOY7y94PcLrn3A5/m8k1OpM/NaosKGwAFbRGb3avNzu5c94dc06v1SSJI8BwxF7N9wZo2CAcLF5t9KLEyx5eYDEvBT+F1wA6AWPhZqDxK4q7nmwihAFi0zZrZDZvXnC3TWYy/Qs7MCZgYxrb+jslnr/fYztW++ysVeX5t1xfrWd8RgVJWyouuUAVPxHgKjeQTE2xeyZE2T8QKt/Jr8p7qEib2GnHEI5AEiaW4P7TxPwuOAKgxfotHKjP85HB4+cERDnobLnvCV/zdAOetv7yfvE8/ldL1+6ZqOkvUQDqAC3KXmq27OnUikpLJplQ63lmjlHQpkXAqG2T+4VNJXgr7Vi0IxFg/+c80lj+Of2rzemtjschIpssJDVHITPqkqUIY+tCt9oDtqYC26KRdytG9h2+K/Ww9wQWtIyLQuYUCLbZSFxITqd83zeZ60w3/Vv18V/Naqiij3Vx4bCijsZM80Xn+fMoIRcERgB+4j7/DS+ +f6pk1Kx qvx5m97stYHLIJjzCHRX5j1lp1hh9dk/7XGNZ7q4NyBT3bN1trC4Uam3A/zugnQhzj/Ut7RRgITd9tF4Qa6bEcTZFWg6/LUq5w7VCuk/vnoomP/rsS7DiwgPrztWgKEAJj8ZpKDKj8lOul3uA5YRcfznjfSbbcO+hCTXrdBgFbX4Pxi/W5hvj/tFl/QZ4kvpAUW/aeIfs2lYc+JboHJ0yUXYIk67kn4h7Y1Wjxg8xyipIdeMHdsEH4y1id+72Kq0zHEkGz7rGtEx2w7yhvTZcEp4P3rW8ZMXHSbzaPwBRIgpjZ9UXsSFrn3E7doYXoH9TIaYuM12WyAZXc2lZw58g0KQvaoYT9ZQwZ+pHR92a+Mzh5v4v0jY4xJLvFmK1mAwKhygD7r/cg0JDVBXj8Acpr6DDshKHZvY1LXo1VwkoqeBMG2FOqP/tsWZ1KlfkXEIV5XvM0mD0h8WybarFOdrpy+S2JNSfgZhmQSrRL5g2xzPaZRgeYjfDyT/ciDXdixMuCj9rDjQFoD6MIk7VusW/u48oNxmbcgV/Qxqbn07ezHrvBmBhb8V53OVkPA== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On Mon, 23 Oct 2023 at 17:40, Dave Chinner wrote: > > > > Maybe we don't even need a mode, and could just decide that atime > > updates aren't i_version updates at all? > > We do that already - in memory atime updates don't bump i_version at > all. The issue is the rare persistent atime update requests that > still happen - they are the ones that trigger an i_version bump on > XFS, and one of the relatime heuristics tickle this specific issue. Yes, yes, but that's what I kind of allude to - maybe people still want the on-disk atime updates, but do they actually want the i_version updates just because they want more aggressive atime updates? > > Or maybe i_version can update, but callers of getattr() could have two > > bits for that STATX_CHANGE_COOKIE, one for "I care about atime" and > > one for others, and we'd pass that down to inode_query_version, and > > we'd have a I_VERSION_QUERIED and a I_VERSION_QUERIED_STRICT, and the > > "I care about atime" case ould set the strict one. > > This makes correct behaviour reliant on the applicaiton using the > query mechanism correctly. I have my doubts that userspace > developers will be able to understand the subtle difference between > the two options and always choose correctly.... I don't think we _have_ a user space interface. At least the STATX_CHANGE_COOKIE bit isn't exposed to user space at all. Not in the uapi headers, but not even in xstat(): /* STATX_CHANGE_COOKIE is kernel-only for now */ tmp.stx_mask = stat->result_mask & ~STATX_CHANGE_COOKIE; So the *only* users of STATX_CHANGE_COOKIE seem to be entirely in-kernel, unless there is something I'm missing where somebody uses i_version through some other interface (random ioctl?). End result: splitting STATX_CHANGE_COOKIE into a "I don't care about atime" and a "give me all change events" shouldn't possibly break anything that I can see. The only other uses of inode_query_iversion() seem to be the explicit directory optimizations (ie the "I'm caching the offset and don't want to re-check that it's valid unless required, so give me the inode version for the directory as a way to decide if I need to re-check" thing). And those *definitely* don't want i_version updates on any atime updates. There might be some other use of inode_query_iversion() that I missed, of course. But from a quick look, it really looks to me like we can relax our i_version updates. Linus