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 7E6CAC77B75 for ; Fri, 21 Apr 2023 10:13:37 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id E33226B0071; Fri, 21 Apr 2023 06:13:36 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id DE2386B0072; Fri, 21 Apr 2023 06:13:36 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C824E6B0074; Fri, 21 Apr 2023 06:13:36 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id BA0FA6B0071 for ; Fri, 21 Apr 2023 06:13:36 -0400 (EDT) Received: from smtpin03.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 8546D1A06E0 for ; Fri, 21 Apr 2023 10:13:36 +0000 (UTC) X-FDA: 80704986432.03.8FB6EAC Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.220.29]) by imf24.hostedemail.com (Postfix) with ESMTP id 8EA34180007 for ; Fri, 21 Apr 2023 10:13:33 +0000 (UTC) Authentication-Results: imf24.hostedemail.com; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b=Z24b84qa; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b=wluaBxVf; spf=pass (imf24.hostedemail.com: domain of jack@suse.cz designates 195.135.220.29 as permitted sender) smtp.mailfrom=jack@suse.cz; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1682072014; 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=r6wWKx5dDKFmTIcIYNBq1MQUPmJkbAp8f/jd3WbQHMU=; b=ac6hfF4Kn1lEgHA4DVjbQURt5Iqm5f+20lU7E+JBCjNMSpj1d9f8S8XqeZXsLAfsxJ3+EW zAGyd46Yg+xlNLFYRsd4FlZ5c4L1RPhAN3Cg4NQwWIG+Y06hG+1Ix0gy8X7cCtuUvei1ul jSCfKH+jMKkyNwb6uuZuYnklyevbFwQ= ARC-Authentication-Results: i=1; imf24.hostedemail.com; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b=Z24b84qa; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b=wluaBxVf; spf=pass (imf24.hostedemail.com: domain of jack@suse.cz designates 195.135.220.29 as permitted sender) smtp.mailfrom=jack@suse.cz; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1682072014; a=rsa-sha256; cv=none; b=6rdl8l7Wf6YkHk79QVCmh2rYy3IWbFrbjs5wnneA9YCxyUGKgQKzm3wM1N8l8kjOR7VGvf q6j54MsEq1sy9V/tE+enf/PkstTrkU/Eg2DBwelbvkddOMo6U397a/zrOlvw088fiv+3Ox vlcBlKuUcwzO5W5ioagpIVFI2yHuNkM= Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by smtp-out2.suse.de (Postfix) with ESMTPS id 15F091FDDC; Fri, 21 Apr 2023 10:13:32 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_rsa; t=1682072012; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=r6wWKx5dDKFmTIcIYNBq1MQUPmJkbAp8f/jd3WbQHMU=; b=Z24b84qaXsafYxTU01etW0C6yQx+jEUWbuL2ZTAaKXxwRestqLVw4E0xENQSwVPoR09DNQ FaNYM9anVh/Y9fXugiohOGxxhkbQ1viU53UJayzTRsmmfqNFHUjxumkbW9Zo+J1GjStVUg 2GWyv3jHPVOsKnj7NTSlArB4EvZiDsE= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_ed25519; t=1682072012; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=r6wWKx5dDKFmTIcIYNBq1MQUPmJkbAp8f/jd3WbQHMU=; b=wluaBxVfb+rzQ3wrkA8IStKDPvQj84jb9cZ3zM0az/l+GWLEuYDNm0m9jBpORjgAGMABU4 fsTWTgo6EqaZzFCw== Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by imap2.suse-dmz.suse.de (Postfix) with ESMTPS id F37A51390E; Fri, 21 Apr 2023 10:13:31 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id 83RPO8thQmS1ZwAAMHmgww (envelope-from ); Fri, 21 Apr 2023 10:13:31 +0000 Received: by quack3.suse.cz (Postfix, from userid 1000) id 7EE2EA0729; Fri, 21 Apr 2023 12:13:31 +0200 (CEST) Date: Fri, 21 Apr 2023 12:13:31 +0200 From: Jan Kara To: Jeff Layton Cc: Alexander Viro , Christian Brauner , "Darrick J. Wong" , Hugh Dickins , Andrew Morton , linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, linux-xfs@vger.kernel.org, linux-mm@kvack.org, Dave Chinner Subject: Re: [RFC PATCH 1/3] fs: add infrastructure for opportunistic high-res ctime/mtime updates Message-ID: <20230421101331.dlxom6b5e7yds5tn@quack3> References: <20230411142708.62475-1-jlayton@kernel.org> <20230411142708.62475-2-jlayton@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20230411142708.62475-2-jlayton@kernel.org> X-Rspam-User: X-Rspamd-Server: rspam03 X-Stat-Signature: x6sgyk78dfjatu8bqzpcmn36r68iic6s X-Rspamd-Queue-Id: 8EA34180007 X-HE-Tag: 1682072013-598139 X-HE-Meta: U2FsdGVkX1/77g7Q9+lCZETbafOCIgZueyONKFMqAlJQYlFZ71zfdRMkhpQh5sIzatJUT4OReIuY5+ThQIocJzXzmH8yeHsAQsifd4+zJm1ohH4iocJzWmA/JrCYioF01Emo0XfZYVVDZvFqUBzO71WoYcOy6LMnWw+VzTtS8mF8PcN3lsZbvrXInjRZZcdXOv68N2yKuPUfQzCjwg1Yc+klZ6xI7F4BTnp5QrfG6vHnK98F3xy+AgnhMZC4A3Uv3PLieQbSLTL+ESB3W/RoVm/9e81vJb7YbhBzDmldsYF7EZahosIcD2eb5gTS3mdusxX/SQKNa9ypTEPEawNprZuFAXk9bsm5EpmIe77vrO+m//AXk2184gwDQwwW1afospbchM/W0iKjTob9R7RS13CaP6t4prF1Gvoeuw6QW6zGBwaw51j0OjgWSfwtj1oOfJuYwm+TUHd5IA1US24sJvb6bb2pF0uqBlkj7GJTIbURohCQWE4cFwBU/q4MhWLjWhUyoBzLnSshFNcUMLNYdnuTVt2NbwHIhA4JEBoZeIIEz4NWoj0hvCuy3MUO1ipzJoZCa031vm2Rg2pXuaegIgO+WQdvPDFmaVQTLM6ahd1xbnxVcBIcfsPP8rC4+VUs/cfYY8eADsm9zDs5tq04o5tEHHQtoxGiHCSAYzFcjQD1Ah/xBF7u4ezOfKbuVyzSZ2UKuN0qRd/UB39teogNetrkfT33UDP4Yw9VtesLMnCVyLPy3Vkxo+5pOIA7JrnZ7SPv3mgGSs7OSLJ4Pe1rkyLkf0WyMZuiy5kbCLj0h1zSmBFtxXBc1YwT6IoIA93UkSuBPXS5hoCDREMJOHUDBuNnP6CD/XyVqR0QV8AwCTe6AIpK7n8Sk0bOVMULC/nHSNqFU6XxO1vcUmdad3Z3d4kdVq+iecZc4xc3jR0ReaFvd+o1oUonpief5wGLAOctI0AmD81XHrUdczolUfz eKu4nZ/s JC2o4G7oSitHjKM+MIKTpsiExPdTsCkPzM1tcpxlZzPP8h5SS4buhXaBpnPWlafXnrqKICN0HIQ4tIWo7nJn/UoSJJdLOa5vgSMEWkVHSc3GexqLNbXVQvAVMcJE1oKMl9Z0eBx5Z3qX0BjpEZLduMpVllLLCmylRxIeNAu+IFxZ1vd0lDljU7vXp6hlH2p4AlX5b025H1xrFEQjPoB1w+y0PPLsUfyeTwvB5uw1X10hiF557a0UctFg+Vo47Oca49XIFLOVU+EsaN+Lrss5w6lSNSqHo7Pcfi1p1GsXUm8q8He/QSHFFhx/vNkpGT05BBZEA8kQzY8gNxB+PWk5Ef5fHl7FLGziP78vTp+jgBzCuHN2Qbnyjt0or6g== 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 11-04-23 10:27:06, 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)) { I don't think we can have inodes without a superblock. Did you ever hit this? > + 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; Isn't this a bit fragile? If someone does: inode->i_mtime = current_cmtime(inode); inode->i_ctime = current_cmtime(inode); the ctime update will be coarse although it should be fine-grained. > + spin_unlock(&inode->i_lock); > + } else { > + ktime_get_coarse_real_ts64(&now); > + } > + > + return timestamp_truncate(now, inode); I'm a bit confused here. Isn't the point of this series also to give NFS finer grained granularity time stamps than what the filesystem is possibly able to store on disk? Hmm, checking XFS it sets 1 ns granularity (as well as tmpfs) so for these using the coarser timers indeed gives a performance benefit. And probably you've decided not implement the "better NFS support with coarse grained timestamps" yet. > +} > +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); The name could be better here :). Maybe stat_fill_cmtime_and_mark()? Honza -- Jan Kara SUSE Labs, CR