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 BEF57C25B6B for ; Tue, 24 Oct 2023 03:40:45 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 363236B0175; Mon, 23 Oct 2023 23:40:45 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 313EB6B0176; Mon, 23 Oct 2023 23:40:45 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1DAEF6B0177; Mon, 23 Oct 2023 23:40:45 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 0E8446B0175 for ; Mon, 23 Oct 2023 23:40:45 -0400 (EDT) Received: from smtpin14.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 51B82120C6C for ; Tue, 24 Oct 2023 03:40:44 +0000 (UTC) X-FDA: 81378953208.14.A202336 Received: from mail-pl1-f177.google.com (mail-pl1-f177.google.com [209.85.214.177]) by imf20.hostedemail.com (Postfix) with ESMTP id 5DB341C0007 for ; Tue, 24 Oct 2023 03:40:41 +0000 (UTC) Authentication-Results: imf20.hostedemail.com; dkim=pass header.d=fromorbit-com.20230601.gappssmtp.com header.s=20230601 header.b=awJArH9X; spf=pass (imf20.hostedemail.com: domain of david@fromorbit.com designates 209.85.214.177 as permitted sender) smtp.mailfrom=david@fromorbit.com; dmarc=pass (policy=quarantine) header.from=fromorbit.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1698118841; 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=oWeGYZJ7Zqr0SZ51s3Tlaj8JTzPWhfxnA67l062INq8=; b=HQL94DSS3dIjpBp6HX9RrGSjI/QQwXrElVZCJBtdI8A0qatvYWmujQo5uLO67Y7r/luNIw pmo+2ETUShr/Prj5mzUHXDq11ZOmGeSzGB7GP8gI27K98q4ZBqRy0IvJXr2qF6T0fUsU1f 4blQ9iNzQ61pIM+V2G4qCVMUZksCSa4= ARC-Authentication-Results: i=1; imf20.hostedemail.com; dkim=pass header.d=fromorbit-com.20230601.gappssmtp.com header.s=20230601 header.b=awJArH9X; spf=pass (imf20.hostedemail.com: domain of david@fromorbit.com designates 209.85.214.177 as permitted sender) smtp.mailfrom=david@fromorbit.com; dmarc=pass (policy=quarantine) header.from=fromorbit.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1698118841; a=rsa-sha256; cv=none; b=hFR+35q59lc3ziKnh///NnQCQ+9xMgqKXgx7ZMmwirgemWFLWSFFE3m5hpQyiHvJW5XFbg MDCdDoNISAbYUGhsdk1Pgy9XZojbzyoDhubEnn2Ah2nERDVt27h77+inCzgbU/I3Rpi/yg DkhDGKJOFHocanxgtrUzjypFsdlcpgw= Received: by mail-pl1-f177.google.com with SMTP id d9443c01a7336-1cab2c24ecdso24555955ad.0 for ; Mon, 23 Oct 2023 20:40:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fromorbit-com.20230601.gappssmtp.com; s=20230601; t=1698118840; x=1698723640; darn=kvack.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=oWeGYZJ7Zqr0SZ51s3Tlaj8JTzPWhfxnA67l062INq8=; b=awJArH9XOgxMBNSiBo6mShX3fyKCACvHF2f0scybvUZEjqjXyKndaJOsG9geskKr9f U85lvKYAejEVf2pV9QX7M4csbP0/HbNhuRjLA+CJVYxUUaG7vivxfqERW4XjVSiCqvPC thAUtUfYccOdT8aZRS+jqEsksOSPf307mdd5QEXGZtRN5HxDWKTU+iUZ5Z9XxImwQ9Bu ZsZ9EyJtqhmp+BscOaHUHKlgxtuKr6hERAyfac26tzaDwgq3HapHCah1EoZkGbqFIO/o SLJvZ96CMfvDAOoIJTOH1F5U9OrHVc2W1ik9V3AD4PTJiO5IDd7auyKfpNm+4EBrMFrq GbDg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1698118840; x=1698723640; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=oWeGYZJ7Zqr0SZ51s3Tlaj8JTzPWhfxnA67l062INq8=; b=FnNSL1wtZmS5cuuVsRfKapg8iSX2c6shvY8JpI33Sy30bnBWFXnzd5/9JCDL3e9vHB W+2E6WdyjzeyfYYWRHGLrI/rA+72S+dk9MRLHsO7SI1h2ArybPwGl7GPPrAIz95lYz6s jYcxvqee51YvnS2BrQnZEWgJxUeSAvs0n81uUo/DgWxGaMlqH2t7IbhrmYa//Q4n0R3j ns5T5KLSQ428WZmAsCcunkjhVTnqXWN7/PHoMyXtZ4cEo5lf3AFkruktY7UE6TyyN4KM M4qg4CuQ782OdUe/NhrBeybGALrblpMtgcunZIwvs3PYvOHEAhnKkQuSZ0cfnt6jHq1N tHzw== X-Gm-Message-State: AOJu0Yxb+AwLNMEYyPpvZrQhtkyTHugfoyz+AY72880DBoXq1Reg3xwh NKcSl8rUGUk+hv9gyquwyueqEQ== X-Google-Smtp-Source: AGHT+IHBoF+8WS2RfetzLDwdufPuai+lmlctVilCrpXxsuy5LNKEo/W+GvWNVlLVD0/hEfe7bag85w== X-Received: by 2002:a17:903:84f:b0:1c9:d25c:17c6 with SMTP id ks15-20020a170903084f00b001c9d25c17c6mr8511411plb.1.1698118840059; Mon, 23 Oct 2023 20:40:40 -0700 (PDT) Received: from dread.disaster.area (pa49-180-20-59.pa.nsw.optusnet.com.au. [49.180.20.59]) by smtp.gmail.com with ESMTPSA id n14-20020a170902d2ce00b001c739768214sm6668917plc.92.2023.10.23.20.40.39 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 23 Oct 2023 20:40:39 -0700 (PDT) Received: from dave by dread.disaster.area with local (Exim 4.96) (envelope-from ) id 1qv8HU-0039F0-1Z; Tue, 24 Oct 2023 14:40:36 +1100 Date: Tue, 24 Oct 2023 14:40:36 +1100 From: Dave Chinner To: Linus Torvalds 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 Subject: Re: [PATCH RFC 2/9] timekeeping: new interfaces for multigrain timestamp handing Message-ID: References: <5f96e69d438ab96099bb67d16b77583c99911caa.camel@kernel.org> <20231019-fluor-skifahren-ec74ceb6c63e@brauner> <0a1a847af4372e62000b259e992850527f587205.camel@kernel.org> <61b32a4093948ae1ae8603688793f07de764430f.camel@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 5DB341C0007 X-Rspam-User: X-Stat-Signature: etkjpaofrtgzn7kbtynsauw9pdki4ju6 X-Rspamd-Server: rspam01 X-HE-Tag: 1698118841-9850 X-HE-Meta: U2FsdGVkX1/aUuGj4Ww4XjVsWZhQu+/P5dLhtL54FUw8KiMPQhKY+i01icj8MC4nzsK2j9atGbc0d8zumQnUouU1+QF9HH9z8Xblkm2gSE7IffPJZyfmEkuF3/mdjYi0YOkVng9zHF40myCg5DfrkOw/i09hjqigqTkg6LGpE5Y0vLRsMNMXEDzOeFke4JEsydKdNpTmEcEAgF/FpJygPODDl2id3tbrYEUirVQEctci2vVm1SUVwY7lvj2qeT9XLf7lguavkIaFE2JS3axwq4Cjw2IrIa1iEXeECEajTAF8T5nfLSUEAQXyBs6CXufjDsj4Q7Uin6tWTniH1/YqGAfUZp1ehqX6DB/4nRWD+MyZjaNwUCXpiU5S9wAXNAfI1jUR5Y2rRWyHUZqCdEuL32C072MDuhuQ+YLT9Mj0GFXKCLpeGsRHw193yaHXcPbRNnqare3HQ9f1gdeTmjSCgna7CGe1//HkuKcbCQzWLtbIeUgDh39jX5O4H8y7c55Yois+b0OtjrnLrFNZcOXzwJFRAFYaE3+wfScQUm7howVFzBU7IygT8sUqKGXynSEgGY5/yzQDCL0o5Qcwp01f+jBNl316FHh+PM9vFWmhlS8Te5W1KqODevuXnY8zbsb3vQnYH+NRnsKSO/J1OvXuigCHnHsSXdYK6rnFspMUUyLN5odf41m/CfycgUd8tz7nswrOi8+W8oZhDLFOquWMqWkyEsFG0n5pTpUN0X1atG1JASyniGlO68DlIDVePm71AQFGCAur2OeCFzTRkUb+rwZeDgAwQSqWa9a6kQW1m6ksI7+YqRAROSUW6FIGc00OlR6tbjiIeWqLWgWyg+wZVOiKXwKDpxm5HisOwLtvaNfqoO5HNvMktSQcva0zSKKTcLcl5Gu7HnmYguWeRvZW3FI3HjSTD/GTNrelo//Hl/p6FRV6/m/iXUkztvNEQEqpoiKy31csgf9c+1vB51V tiRKpl9K TRFNXHBp7EHFenNI/CNnR45VHgXDZLnHQdwazmzwJ4kWdxXQvdVWhShQZPpapEspSfGgI3Y5TPPEFgBV7lmjQ34kayHUpaw8dM5+15MS9J35HxOy5DzpEX5W2YRWZ8dM4EfevQYbvZfu6WKBuJFQqnOy6ND7byVaYjgEP7zsPppiOFFcIep+rnBQyRsvks8EVWcecaQmyWU9UrWVzOdAI/Z+vCzP8qSkDKqAxJmnvtyB9BFGS/Uknl2WGJorAkveBMc1z2dPgQ/RudmcSAsxvl/eZNmeJs/1Ux3kSRvAFStn8vPrrWraZvF6pBhzDvqiZGU4GtaY8Alzz+Xkt8T9MuTRJC6e8stAcrvZYlTxPGc6xxH5sZ9mJsQl/S1xMAOKdR3ndLp3RZ2GROR5bOqoqQQhcfUHtBqeRlIFToO6GV8vbX1ii4+EIZQ8d32HpMKbz9ymN 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, Oct 23, 2023 at 02:18:12PM -1000, Linus Torvalds wrote: > On Mon, 23 Oct 2023 at 13:26, Dave Chinner wrote: > > > > The problem is the first read request after a modification has been > > made. That is causing relatime to see mtime > atime and triggering > > an atime update. XFS sees this, does an atime update, and in > > committing that persistent inode metadata update, it calls > > inode_maybe_inc_iversion(force = false) to check if an iversion > > update is necessary. The VFS sees I_VERSION_QUERIED, and so it bumps > > i_version and tells XFS to persist it. > > Could we perhaps just have a mode where we don't increment i_version > for just atime updates? > > 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. If we push the problematic persistent atime updates to be in-memory updates only, then the whole problem with i_version goes away.... > Yes, yes, it's obviously technically a "inode modification", but does > anybody actually *want* atime updates with no actual other changes to > be version events? Well, yes, there was. That's why we defined i_version in the on disk format this way well over a decade ago. It was part of some deep dark magical HSM beans that allowed the application to combine multiple scans for different inode metadata changes into a single pass. atime changes was one of the things it needed to know about for tiering and space scavenging purposes.... > 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.... And then there's always the issue that we might end up with both flags set and we get conflicting bug reports about how atime is not behaving the way the applications want it to behave. > Then inode_maybe_inc_iversion() could - for atome updates - skip the > version update *unless* it sees that I_VERSION_QUERIED_STRICT bit. > > Does that sound sane to people? I'd much prefer we just do the right thing transparently at the filesystem level; all we need is for the inode to be flagged that it should be doing in memory atime updates rather than persistent updates. Perhaps the nfs server should just set a new S_LAZYTIME flag on inodes it accesses similar to how we can set S_NOATIME on inodes to elide atime updates altogether. Once set, the inode will behave that way until it is reclaimed from memory.... Cheers, Dave. -- Dave Chinner david@fromorbit.com