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 CE81DC77B73 for ; Tue, 11 Apr 2023 14:42:37 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 3C4EA900002; Tue, 11 Apr 2023 10:42:37 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 375866B0075; Tue, 11 Apr 2023 10:42:37 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 23C97900002; Tue, 11 Apr 2023 10:42:37 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 13EFD6B0072 for ; Tue, 11 Apr 2023 10:42:37 -0400 (EDT) Received: from smtpin11.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id D1C86804F0 for ; Tue, 11 Apr 2023 14:42:36 +0000 (UTC) X-FDA: 80669376312.11.09BD3D8 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf26.hostedemail.com (Postfix) with ESMTP id 148DB140003 for ; Tue, 11 Apr 2023 14:42:34 +0000 (UTC) Authentication-Results: imf26.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=JI1AF4x4; spf=pass (imf26.hostedemail.com: domain of djwong@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=djwong@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=1681224155; 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=yOVMrbIJdGuM+VUwZlbTAWocD1ReDb2Sm1Y+LDNfrJU=; b=jPhwAac3ubSMJP/sdvjDqd7m4hFhnTO1fNwmJEIYtOuXrWCGX3Lq+2VjEGf9HdV5nVk7xH Nex+8/Miq92Tm+iNnVewAidgfPXLVSqLfQgOGAYO99HITEIwdohQn0eQ4xl+JeUywQBCE6 JDMBnUt8nYIg5eGbVd+PjBwnRNTrZRs= ARC-Authentication-Results: i=1; imf26.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=JI1AF4x4; spf=pass (imf26.hostedemail.com: domain of djwong@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=djwong@kernel.org; dmarc=pass (policy=none) header.from=kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1681224155; a=rsa-sha256; cv=none; b=0iKEa+PwSvnu43Yrb+pKNKizQJbNKOUzs8BaUfb4sIWPgVxKw7nMnMMPXRoahu9V83dMEK 4iPDm5ai0eW9dwOfKAuv9hAtt+48uMsRlY+k6vYuKCxmb7ueCgVBswoyaLeLR0dFmc49wi WbSeLLxd1qkLF1MQ6qpNZUYkvtKt1Wk= 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 251CE627EB; Tue, 11 Apr 2023 14:42:34 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 85391C433EF; Tue, 11 Apr 2023 14:42:33 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1681224153; bh=WHyqUQZ68TMjpuSBNPWt7SXYNo4dZVW4aLHnbDWvhH4=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=JI1AF4x4T9YzejP/SdIgB4Zt07TgPCqQqt+KoCva/IJH/tQDKiYbfluRjt7wietRh +2/Dl5gAeSlyA/IGasaFLceW1BaENcKxfSEw1qaX82cmKpu1YydO3B4G0gOqbS1oTC DCMBMvBnagjs4RcJ15nUCoGDxtCviL6Zf3el8nPts2I4tCSpBMLrzYltMD3UrA//0d kCi1bou3C7Xi3IjXhvNkjHy3u+jKX8n8joP+JmK6cH9nL7Y4TwLCD8Z9YBABcIpMY8 uwGbIph0AtY8UN13xyFFMwAjQebj5yvdATnWTLPymQfjurlROzMxOmbK30F2DiFBky mtjoNdmiU4H4w== Date: Tue, 11 Apr 2023 07:42:32 -0700 From: "Darrick J. Wong" To: Jeff Layton Cc: Alexander Viro , Christian Brauner , Hugh Dickins , Andrew Morton , Dave Chinner , Chuck Lever , 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: [RFC PATCH 1/3][RESEND] fs: add infrastructure for opportunistic high-res ctime/mtime updates Message-ID: <20230411144232.GF360895@frogsfrogsfrogs> References: <20230411143702.64495-1-jlayton@kernel.org> <20230411143702.64495-2-jlayton@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20230411143702.64495-2-jlayton@kernel.org> X-Rspamd-Queue-Id: 148DB140003 X-Stat-Signature: hc9uo3odwq4zpwcnk8eppzxybf7k9e3u X-Rspam-User: X-Rspamd-Server: rspam08 X-HE-Tag: 1681224154-625586 X-HE-Meta: U2FsdGVkX1/A2P4pSdh07dxSw4Yc/Jnhz5zn4dvfc9BfDpJtVkCKngYehFWWU24dfJpaJkR//7UIAOJVSz7vh9OdEKghUsxW48ut9r3rs3bHvjkTfugmL/lXOQBJK+YAyZLVha5bKNGHpilXyLIOB0T3k+O52hq/4XniQswDr+CPnhkBKg7e5OBt+5eZEgYgj4FQQRBfG4Zg7YAtts6BniEp3SJWym0Az59lJOKm3LRIkOIey7Em+uk5Ha4Au9TmkvPioqWDfrA8MqAHw4Hfy0uImEl6eaUzRtvzOQxIny/YNHT5Co0n80dhFKzu4dOdMPZXOkZ8qX/b3RKk5YhG/41juVkxOTsRJODBWSv6mcm447qoxoCpZQGE48/qrO/nLEUjsCm6SZNUKH3S8vLXO2UJrB6Dbg1ZKYkDvYnPgz3PKU8gI6gjuZh6Ja1XF9aDJu13FdGMx1EBnMBbFpRQe3+oq17eU5vlLZPCcAVg/iUo0YayvIkhcwPAattVLA17ZuT2796pHr1fXZgAimvo7BHGsYd0NHhUaR2eyzAQQcA/9YvhGgUOjVAbm4HJltrTaA8UjE0+rYqzooKrLfyCGv4gBUqgJFkZu0Xt/KZIl+cAR+5HfqqF0xrIYYQAJrtr0U/VEuLOkcqf68A/N5D3h32O7OXTh4wT6I88QtX2Ofozh7Yf0mTjMTHIeDUGzJNj8aU87WvftJ9DUKjMGqd4Jh98uvooVkYoSrKzKadXeD1ApRlYp54TfHRHSi2fMuYZ3YN7GAJjvPHSyjbNLEetDOZ6IwzpdQKI2B5DRP8eBviAmD//Zzxl3wl6FLLBbV1rKL2l+TvD5/3EKF84iLo+IRTVY07L9qUsJB9quYjqU55BS8hTGAzjopS7u3UxmsdKlIYEP0mLI2Oc2qpCWiW5YBteKYBalTbW2ixEsEiYHRJu8L+sxmN1Iuh3x25+i/slXSoDsTA9oYxBswjghQl mpV8E9Bw cVaaUPhX3uE2oh73dKGW2WluW39QVAaKZkZVoY7FlZTBEcAu6rm24LsksGwTE38/ojTLIld6nGxy+PdA2YCUSom1DIqb1QrYVNxDsZpONoxPcyNEf3W+ZnvY4xrMebWNlmCsi0g5LnUXrDonGctcmTMEv+Y+vdutBiTKHpy5Hcrzg9G7TWNH2VGTAuH/+W3UIpUQOpdG6yREAEIY6AmoDsLz7e8aiQDwlvZdcCY66ohllLwwH/194f5htbx9iKs9j8dkcIEA0fge6WXSUUhqpibf6TCbZevc4rGYz9R+bRfKcN85GsX8LcKriAHC4JBh0nLPb5Jr9/LFUeVVMWmAZ8QZ3D/42sSWx6q92oR4qYJXFTCoqHGOybp08fPz8ngG3lu9mXVFWPX6uNMWe8INcIfSCSUA5NjJIrePuJz9d9GtyGPk= 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 Tue, Apr 11, 2023 at 10:37:00AM -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 metadata updates. > > 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 problem of timestamp granularity. Other > applications have similar issues (e.g backup applications). > > Switching to always using high resolution timestamps would improve the > situation for NFS, but that becomes rather expensive, as we'd have to > log a lot more metadata updates. > > This patch grabs a new i_state bit to use as a flag that filesystems can > set in their getattr routine to indicate that the mtime or ctime was > queried since it was last updated. > > It then adds a new current_cmtime function that acts like the > current_time helper, but will conditionally grab high-res timestamps > when the i_state flag is set in the inode. > > This allows NFS and other applications to reap the benefits of high-res > ctime and mtime timestamps, but at a substantially lower cost than > fetching them every time. > > Cc: Dave Chinner > Signed-off-by: Jeff Layton > --- > fs/inode.c | 40 ++++++++++++++++++++++++++++++++++++++-- > fs/stat.c | 10 ++++++++++ > include/linux/fs.h | 5 ++++- > 3 files changed, 52 insertions(+), 3 deletions(-) > > diff --git a/fs/inode.c b/fs/inode.c > index 4558dc2f1355..3630f67fd042 100644 > --- a/fs/inode.c > +++ b/fs/inode.c > @@ -2062,6 +2062,42 @@ static int __file_update_time(struct file *file, struct timespec64 *now, > return ret; > } > > +/** > + * current_cmtime - 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 or mtime change. If something recently > + * fetched the ctime or mtime out of the inode via getattr, then get a > + * high-resolution timestamp. > + * > + * Note that inode and inode->sb cannot be NULL. > + * Otherwise, the function warns and returns coarse time without truncation. > + */ > +struct timespec64 current_cmtime(struct inode *inode) > +{ > + struct timespec64 now; > + > + if (unlikely(!inode->i_sb)) { > + WARN(1, "%s() called with uninitialized super_block in the inode", __func__); > + ktime_get_coarse_real_ts64(&now); > + return now; > + } > + > + /* Do a lockless check for the flag before taking the spinlock */ > + if (READ_ONCE(inode->i_state) & I_CMTIME_QUERIED) { > + ktime_get_real_ts64(&now); > + spin_lock(&inode->i_lock); > + inode->i_state &= ~I_CMTIME_QUERIED; > + spin_unlock(&inode->i_lock); > + } else { > + ktime_get_coarse_real_ts64(&now); > + } > + > + return timestamp_truncate(now, inode); I wonder, under which conditions (arch+fs) would it be worth the effort to check s_time_gran as part of deciding whether or not to sample a high res timestamp? I suppose that would only help us for the situation where "ktime sampling is not fast" and "fs timestamp granularity is awful"? (Mechanically, the function body looks ok to me...) --D > +} > +EXPORT_SYMBOL(current_cmtime); > + > /** > * file_update_time - update mtime and ctime time > * @file: file accessed > @@ -2080,7 +2116,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_cmtime(inode); > > ret = inode_needs_update_time(inode, &now); > if (ret <= 0) > @@ -2109,7 +2145,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_cmtime(inode); > > /* > * Clear the security bits if the process is not being run by root. > diff --git a/fs/stat.c b/fs/stat.c > index 7c238da22ef0..d8b80a2e36b7 100644 > --- a/fs/stat.c > +++ b/fs/stat.c > @@ -64,6 +64,16 @@ void generic_fillattr(struct mnt_idmap *idmap, struct inode *inode, > } > EXPORT_SYMBOL(generic_fillattr); > > +void fill_cmtime_and_mark(struct inode *inode, struct kstat *stat) > +{ > + spin_lock(&inode->i_lock); > + inode->i_state |= I_CMTIME_QUERIED; > + stat->ctime = inode->i_ctime; > + stat->mtime = inode->i_mtime; > + spin_unlock(&inode->i_lock); > +} > +EXPORT_SYMBOL(fill_cmtime_and_mark); > + > /** > * generic_fill_statx_attr - Fill in the statx attributes from the inode flags > * @inode: Inode to use as the source > diff --git a/include/linux/fs.h b/include/linux/fs.h > index c85916e9f7db..7dece4390979 100644 > --- a/include/linux/fs.h > +++ b/include/linux/fs.h > @@ -1457,7 +1457,8 @@ static inline bool fsuidgid_has_mapping(struct super_block *sb, > kgid_has_mapping(fs_userns, kgid); > } > > -extern struct timespec64 current_time(struct inode *inode); > +struct timespec64 current_time(struct inode *inode); > +struct timespec64 current_cmtime(struct inode *inode); > > /* > * Snapshotting support. > @@ -2116,6 +2117,7 @@ static inline void kiocb_clone(struct kiocb *kiocb, struct kiocb *kiocb_src, > #define I_DONTCACHE (1 << 16) > #define I_SYNC_QUEUED (1 << 17) > #define I_PINNING_FSCACHE_WB (1 << 18) > +#define I_CMTIME_QUERIED (1 << 19) > > #define I_DIRTY_INODE (I_DIRTY_SYNC | I_DIRTY_DATASYNC) > #define I_DIRTY (I_DIRTY_INODE | I_DIRTY_PAGES) > @@ -2839,6 +2841,7 @@ extern int page_symlink(struct inode *inode, const char *symname, int len); > extern const struct inode_operations page_symlink_inode_operations; > extern void kfree_link(void *); > void generic_fillattr(struct mnt_idmap *, struct inode *, struct kstat *); > +void fill_cmtime_and_mark(struct inode *inode, struct kstat *stat); > void generic_fill_statx_attr(struct inode *inode, struct kstat *stat); > extern int vfs_getattr_nosec(const struct path *, struct kstat *, u32, unsigned int); > extern int vfs_getattr(const struct path *, struct kstat *, u32, unsigned int); > -- > 2.39.2 >