Received: by 2002:a05:6358:9144:b0:117:f937:c515 with SMTP id r4csp364635rwr; Tue, 25 Apr 2023 23:55:07 -0700 (PDT) X-Google-Smtp-Source: AKy350YNGu0amqVxsmqsbiK0kvtj8Ib7dSqmHkKwJgprK8zxZFIURfxGVIKrz2pjnANru5KCzlec X-Received: by 2002:a05:6a00:22c1:b0:63b:86a0:6a37 with SMTP id f1-20020a056a0022c100b0063b86a06a37mr27060892pfj.34.1682492107218; Tue, 25 Apr 2023 23:55:07 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1682492107; cv=none; d=google.com; s=arc-20160816; b=erxoo5wvkFi20hIuMPaXHlfwhVKYm17wVtbgtZXmPWeHGOijA+Dfrj1K4LYlyVLyal UQzwUFz0GXThx5XJhEZRy/vzrNpOpXxXABwopiLP8yvUYOZuL3TVikYX7YSDNu7pUgWd 8oGZqx31hIH6XhBxuliM9aoVyhcN9y6828nuNVo2lbu8qRnDC6Dh4aKAR54SYDSBTPFF fGb6X3UZ+9sII8F0GjbXkEbNunV5Ywa92vnuiKQtXGc65kwhP4w4pAU1jGKpInfykTNG 9t3U2+I+3HjmAvcWxnXlRm+i2skAEL85klnQXcXln5fJnD5wFYNhfJbxV7Vw1kogarb2 6Tag== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=qjvjsnIhqUW2aCiliWWlokX2ZZPAMlVyb5rIdpTd/rI=; b=HTWXpe6JfIZ0rsckTZOvYYC/Kwk2PS7NxC4j/gIYACkoCIRRa49kLp3Ts4hPhUuFrg z5+An+5lgkwJD/y69ynQb6Geynnjst7dWoSy2w6cRekLygb7TRWOf3Lb2+P2DAnVikUv xy9/KAUBLgKXaxF7SwKukFN/ECG4toD9TUhLCAgliJOQn8M70cI2mdj3uOz5lv6kBVxM nD61RX2TRF81M9YOsWBWyW5f1FAcR324A05zlzAQZqvuBVOBBZU8+6Ji6av740Ls+TNN yYbBIjp6EnKB2+NX7bBPI25hPjNPjbjW9O1e8OrOkWKwngCqwiCfgt5pF2Psxv6WIQWG iD1A== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=G8fiQSng; spf=pass (google.com: domain of linux-nfs-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-nfs-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id 134-20020a62188c000000b0063c462e9ff6si15259452pfy.389.2023.04.25.23.54.53; Tue, 25 Apr 2023 23:55:07 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-nfs-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=G8fiQSng; spf=pass (google.com: domain of linux-nfs-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-nfs-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S239463AbjDZGyE (ORCPT + 99 others); Wed, 26 Apr 2023 02:54:04 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:34654 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S239309AbjDZGyD (ORCPT ); Wed, 26 Apr 2023 02:54:03 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 808E42693; Tue, 25 Apr 2023 23:53:53 -0700 (PDT) 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 1F6BB62963; 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-Spam-Status: No, score=-4.6 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_MED, SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-nfs@vger.kernel.org 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.