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 B6DD7C7618E for ; Wed, 26 Apr 2023 06:53:56 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 241266B0082; Wed, 26 Apr 2023 02:53:56 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 1F17E6B0083; Wed, 26 Apr 2023 02:53:56 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 0B9E76B0085; Wed, 26 Apr 2023 02:53:56 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id EF9B96B0082 for ; Wed, 26 Apr 2023 02:53:55 -0400 (EDT) Received: from smtpin03.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id B2F30A01A6 for ; Wed, 26 Apr 2023 06:53:55 +0000 (UTC) X-FDA: 80722627230.03.9D7432C Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf15.hostedemail.com (Postfix) with ESMTP id 0F7D0A000F for ; Wed, 26 Apr 2023 06:53:53 +0000 (UTC) Authentication-Results: imf15.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=G8fiQSng; spf=pass (imf15.hostedemail.com: domain of brauner@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=brauner@kernel.org; dmarc=pass (policy=none) header.from=kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1682492034; 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=qjvjsnIhqUW2aCiliWWlokX2ZZPAMlVyb5rIdpTd/rI=; b=kiJ7GOjRN27eVKEwFx8rFlT+Dw9H3bZAO9c0e2rMJhqezYpIIAArxRY+eEzYisMyk34ECv p9sy1TnXrmL3GNY2X8RaEin57YS4QgnE60IFKFBJb3B7Pv+Ep+XYekRmp0OALyP95Kwxs8 BNy6J12bACALtLVHH+sQ4EV8K5phds0= ARC-Authentication-Results: i=1; imf15.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=G8fiQSng; spf=pass (imf15.hostedemail.com: domain of brauner@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=brauner@kernel.org; dmarc=pass (policy=none) header.from=kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1682492034; a=rsa-sha256; cv=none; b=LzaOuzF2lywNBjNoq2z1bBuXyOQ5g8ALMDJRGsWuPyKoINorvOd2dv2TInhS48fUTvVQsj L67vQN59dTsoky9nTlFXmZDLk6J84LopZvTI7A/vQq3NfyCdkf07nCB89CdZxNRNpa2Cjn v0wk3McbRDhZvCd1OoaPYoCcxPTtQXg= Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 1CAEA61CE4; Wed, 26 Apr 2023 06:53:53 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 219EDC433D2; Wed, 26 Apr 2023 06:53:48 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1682492032; bh=QIhBfq3ajoFrTFgvdAxQ5iAO7C3Q5qspZKjzhdSkFDw=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=G8fiQSngd2qR//FFL6mNV7TiZ0hHExG3DHtksT8WRTQ2IEiiKvj+87IE8fz1JCSPk 90pfbu1IicetwgG1l3aeiX9kJjBtMjGh1LXIqVpFrDM8aGqCoY8i1gBQU6gX3U32v+ p8ukg9m7oelvw396eLvBAvui7OT7Mp5GBk02ebdaHLPQa1L2e6mP0pm64b5PO6XIoq V1sYIBnXBSv7l646PNYYrpOpUAZfrlZXdPcBZNiy4dv+J3MjQi1Kz6ThTJ456rw0SM GF6+JDokL6O9FnKDuLQi0zOhbeOeaFwXbZEICIku8KX9fFBatJSDz5eLozlDnJNEft CpWXdnfqp2WkA== Date: Wed, 26 Apr 2023 08:53:45 +0200 From: Christian Brauner To: Jeff Layton Cc: Alexander Viro , "Darrick J. Wong" , Hugh Dickins , Andrew Morton , Dave Chinner , Chuck Lever , Jan Kara , Amir Goldstein , linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, linux-xfs@vger.kernel.org, linux-mm@kvack.org, linux-nfs@vger.kernel.org Subject: Re: [PATCH v2 1/3] fs: add infrastructure for multigrain inode i_m/ctime Message-ID: <20230426-meerblick-tortur-c6606f6126fa@brauner> References: <20230424151104.175456-1-jlayton@kernel.org> <20230424151104.175456-2-jlayton@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20230424151104.175456-2-jlayton@kernel.org> X-Stat-Signature: 9i8moahe7gbebwi7w57edb8u4d9fje54 X-Rspam-User: X-Rspamd-Queue-Id: 0F7D0A000F X-Rspamd-Server: rspam06 X-HE-Tag: 1682492033-350418 X-HE-Meta: U2FsdGVkX19pR7Wo2a/phdhTli/fIR2YqJEoJSWYb3aAvBF8uqNTjB6i3YlK7wr7gF8SAziogDaF1dkOFeqpgB0ifafBwbHJN8VXor6xxxiTp+QQZBOhKxNnYCDB9/pbV7jhUx9DA3sUKwbMvjQDh3RryX/PZQ0INY0Mfz/QoJy6JLvR3PljtQ9d5dosjaBCp+WEmUWIiVvCVfryyvRuvmx9C7+4V04tWqBJLMvBWyHeKuBPOPV6xdf3gQc7UlCHcQtZZN5+5FpMwty9uwr1LJwworkkosaV+xqfCs4QCYwHojczR44s3sEO3evWaJSQinzztzZvwdc12+7/7udZcaBx860IB82V5j4DxBArqZOpa38rabgOl8QQ0L7ZjYB/o5I5HcWGmjFT7bcWbmMd3QyDYQebnSoAbLCC7u9kufx2diKc7tFXQJWK/Kquuc/r25nn+oc6cz6yikWBfasLtqMbgZqmaPIbAmqGhaZyaUkPGX+YkZPAwwkz4sVqQBqUwtc+9amzT3tIjs2jVKvMRpbq/eVRjcGhxJW7vaahDEauuyXGgFEfXK38kYh/GIFhmQLTpIzfNQlDrfmZwRC916Tn/vyv1CHcKaPsp/8zNajnXuMqY2XC5+7SeNm+yfKgVFkLhhe9G83GgDHgoeNzcbXro6cjHiLCIS64JtNJPs35K6Cc352iNlnNd5Xj19FmLllgMmVY3lAj9C1cw5u1k+iONdUEWy2qix9e+67WhT4cuYxOmA8yrOkNbdFa+pjC0xC6+ige7ypcIi7R9SC34PTI5u4Q/gteKUuJ5Z6Y31O5SdpSswG5bTeb+DO0BZTnE1xZtB/LVgHA8G8Wt75xNSBLiZzM3vmLfVN14n18QTxVaGnf6B31QnkmN1pkBMSxmh7TxiKIfDDbO2Wy7zRfSAN6gM14v7kxPP50lk9nleyjlaTAva9BmeCr8qeUDftkBdd4ydCRPuO9SXmh6gG f4HlJFNG QBBqX//HZCunWCLl4m6ANRIVRs5ebjQiuxwHl4lveuIkD1XWVF6MTPRKBvFV7EGrBAAQphkJRsrgxiMWgcOcMxuL4IIRtofhzOocCjZHy5utpK/968y73LPkwhoYdFxEfYNCKNXXTOnV0LJ+RVsAw3YaFeOBkMEH7SFmtzu/7JyfLoIUk1YhGI7+SWskPULiN8aFoWi/UIs2LRcEn/taoVpWHbIL+3xcAGXwCQWwOrxpNoHIapUPjC413uMaIbAjCSvTom+0XYIZtz86tzY53BDSVEH3FSCAU9c4GUZtmouLe/+LX4r2cje3/bv+qVilIShX7v8FxmD3063pn9uKCwYLrXrNrGSA4MLbtP5tVF7kzJH4/8QJUAjcNk4ZxfvlFSn395MTNFR41DeU= 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: On Mon, Apr 24, 2023 at 11:11:02AM -0400, Jeff Layton wrote: > The VFS always uses coarse-grained timestamp updates for filling out the > ctime and mtime after a change. This has the benefit of allowing > filesystems to optimize away a lot metaupdates, to around once per > jiffy, even when a file is under heavy writes. > > Unfortunately, this has always been an issue when we're exporting via > NFSv3, which relies on timestamps to validate caches. Even with NFSv4, a > lot of exported filesystems don't properly support a change attribute > and are subject to the same problems with timestamp granularity. Other > applications have similar issues (e.g backup applications). > > Switching to always using fine-grained timestamps would improve the > situation for NFS, but that becomes rather expensive, as the underlying > filesystem will have to log a lot more metadata updates. > > What we need is a way to only use fine-grained timestamps when they are > being actively queried: > > Whenever the mtime changes, the ctime must also change since we're > changing the metadata. When a superblock has a s_time_gran >1, we can > use the lowest-order bit of the inode->i_ctime as a flag to indicate > that the value has been queried. Then on the next write, we'll fetch a > fine-grained timestamp instead of the usual coarse-grained one. > > We could enable this for any filesystem that has a s_time_gran >1, but > for now, this patch adds a new SB_MULTIGRAIN_TS flag to allow filesystems > to opt-in to this behavior. > > It then adds a new current_ctime function that acts like the > current_time helper, but will conditionally grab fine-grained timestamps > when the flag is set in the current ctime. Also, there is a new > generic_fill_multigrain_cmtime for grabbing the c/mtime out of the inode > and atomically marking the ctime as queried. > > Later patches will convert filesystems over to this new scheme. > > Signed-off-by: Jeff Layton > --- > fs/inode.c | 57 +++++++++++++++++++++++++++++++++++++++--- > fs/stat.c | 24 ++++++++++++++++++ > include/linux/fs.h | 62 ++++++++++++++++++++++++++++++++-------------- > 3 files changed, 121 insertions(+), 22 deletions(-) > > diff --git a/fs/inode.c b/fs/inode.c > index 4558dc2f1355..4bd11bdb46d4 100644 > --- a/fs/inode.c > +++ b/fs/inode.c > @@ -2030,6 +2030,7 @@ EXPORT_SYMBOL(file_remove_privs); > static int inode_needs_update_time(struct inode *inode, struct timespec64 *now) > { > int sync_it = 0; > + struct timespec64 ctime = inode->i_ctime; > > /* First try to exhaust all avenues to not sync */ > if (IS_NOCMTIME(inode)) > @@ -2038,7 +2039,9 @@ static int inode_needs_update_time(struct inode *inode, struct timespec64 *now) > if (!timespec64_equal(&inode->i_mtime, now)) > sync_it = S_MTIME; > > - if (!timespec64_equal(&inode->i_ctime, now)) > + if (is_multigrain_ts(inode)) > + ctime.tv_nsec &= ~I_CTIME_QUERIED; > + if (!timespec64_equal(&ctime, now)) > sync_it |= S_CTIME; > > if (IS_I_VERSION(inode) && inode_iversion_need_inc(inode)) > @@ -2062,6 +2065,50 @@ static int __file_update_time(struct file *file, struct timespec64 *now, > return ret; > } > > +/** > + * current_ctime - Return FS time (possibly high-res) > + * @inode: inode. > + * > + * Return the current time truncated to the time granularity supported by > + * the fs, as suitable for a ctime/mtime change. > + * > + * For a multigrain timestamp, if the timestamp is flagged as having been > + * QUERIED, then get a fine-grained timestamp. > + */ > +struct timespec64 current_ctime(struct inode *inode) > +{ > + struct timespec64 now; > + long nsec = 0; > + bool multigrain = is_multigrain_ts(inode); > + > + if (multigrain) { > + atomic_long_t *pnsec = (atomic_long_t *)&inode->i_ctime.tv_nsec; > + > + nsec = atomic_long_fetch_and(~I_CTIME_QUERIED, pnsec); > + } > + > + if (nsec & I_CTIME_QUERIED) { > + ktime_get_real_ts64(&now); > + } else { > + ktime_get_coarse_real_ts64(&now); > + > + if (multigrain) { > + /* > + * If we've recently fetched a fine-grained timestamp > + * then the coarse-grained one may be earlier than the > + * existing one. Just keep the existing ctime if so. > + */ > + struct timespec64 ctime = inode->i_ctime; > + > + if (timespec64_compare(&ctime, &now) > 0) > + now = ctime; > + } > + } > + > + return timestamp_truncate(now, inode); > +} > +EXPORT_SYMBOL(current_ctime); > + > /** > * file_update_time - update mtime and ctime time > * @file: file accessed > @@ -2080,7 +2127,7 @@ int file_update_time(struct file *file) > { > int ret; > struct inode *inode = file_inode(file); > - struct timespec64 now = current_time(inode); > + struct timespec64 now = current_ctime(inode); > > ret = inode_needs_update_time(inode, &now); > if (ret <= 0) > @@ -2109,7 +2156,7 @@ static int file_modified_flags(struct file *file, int flags) > { > int ret; > struct inode *inode = file_inode(file); > - struct timespec64 now = current_time(inode); > + struct timespec64 now = current_ctime(inode); > > /* > * Clear the security bits if the process is not being run by root. > @@ -2419,9 +2466,11 @@ struct timespec64 timestamp_truncate(struct timespec64 t, struct inode *inode) > if (unlikely(t.tv_sec == sb->s_time_max || t.tv_sec == sb->s_time_min)) > t.tv_nsec = 0; > > - /* Avoid division in the common cases 1 ns and 1 s. */ > + /* Avoid division in the common cases 1 ns, 2 ns and 1 s. */ > if (gran == 1) > ; /* nothing */ > + else if (gran == 2) > + t.tv_nsec &= ~1L; Is that trying to mask off I_CTIME_QUERIED? If so, can we please use that constant as raw constants tend to be confusing in the long run.