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 509E8C77B73 for ; Thu, 27 Apr 2023 09:57:52 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id A1CDE6B0071; Thu, 27 Apr 2023 05:57:51 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 9A5546B0072; Thu, 27 Apr 2023 05:57:51 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 86D2F6B0075; Thu, 27 Apr 2023 05:57:51 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 76AF36B0071 for ; Thu, 27 Apr 2023 05:57:51 -0400 (EDT) Received: from smtpin21.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 45B12C025B for ; Thu, 27 Apr 2023 09:57:51 +0000 (UTC) X-FDA: 80726719542.21.B659E8E Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf27.hostedemail.com (Postfix) with ESMTP id 8216A40025 for ; Thu, 27 Apr 2023 09:57:49 +0000 (UTC) Authentication-Results: imf27.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=byAFePc0; spf=pass (imf27.hostedemail.com: domain of jlayton@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=jlayton@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=1682589469; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=USht+Uhb9xZz9unMUb+D4xBAM+5FX4XpLOVJcmQLh1U=; b=uT8wWVfUFsiT6yt8jnGIaZW7hk26eosDh792hP+OHCod6OYXT4kynsEj1a2kIbKXVN+sjf CoAW8GepbMTHT96gFW75mmjTaon9naaK45OFiQvV6P6FcCWyt1s06OL2BXU23m6xj/YzP8 KGm2PPhwoNkKceHx9XXqk0XY6ZePA54= ARC-Authentication-Results: i=1; imf27.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=byAFePc0; spf=pass (imf27.hostedemail.com: domain of jlayton@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=jlayton@kernel.org; dmarc=pass (policy=none) header.from=kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1682589469; a=rsa-sha256; cv=none; b=ka3T3CvReTpm0RLePvXMoZjOsR3Ge7wwFJWvUjUf/TIyxmRuFjBR0jjdw+quat4VHr6zzv oQ4NjG03belaa7/MTafTOF1w+vJKS0dFKG/b1ERsGn89xOiEHAn3zEWhS+zRRR7DUHy9Vq SEd9XZU0z5qi8ZyZIFUtbOae6i1HczA= 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 3A71D63C21; Thu, 27 Apr 2023 09:57:48 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 5FD41C433EF; Thu, 27 Apr 2023 09:57:46 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1682589467; bh=USht+Uhb9xZz9unMUb+D4xBAM+5FX4XpLOVJcmQLh1U=; h=Subject:From:To:Cc:Date:In-Reply-To:References:From; b=byAFePc0ODsjd5aiGO9OPca7OVWAZDPXzpeqUTYbMwvg/LgHb+Nd89oeLryh1Vjs7 mNs4G0c5xvx9hPHhbPbqqb2wXnfj0hssVe3TfUDySJVnk2oJxTiOy1qYOe+28ZFoqc soDJQVIvZDzswir043Ask61bZCvd8O0/7HPCwsjVW+HkiRya/gKcqEv4o7uWYbYNfD UFEJ/AOiPH0ZipnF2tb1U57ShzE0LtqnRotiitK+rYq9zfecX+cG91iThdn1CtqbFB XyDR5aNQJoGNXTu40yuMplZ/vbGv5gH/JngiDbHisrJKKedk7MZ8io8BRU6s3H7C65 Nu/DjCcXdQYug== Message-ID: <0f504cb85005676fdae06d00b276518b6b983986.camel@kernel.org> Subject: Re: [PATCH v2 1/3] fs: add infrastructure for multigrain inode i_m/ctime From: Jeff Layton To: Christian Brauner 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 Date: Thu, 27 Apr 2023 05:57:44 -0400 In-Reply-To: <20230427-rebel-vergibt-99cf6a7838a2@brauner> References: <20230424151104.175456-1-jlayton@kernel.org> <20230424151104.175456-2-jlayton@kernel.org> <20230426-bahnanlagen-ausmusterung-4877cbf40d4c@brauner> <03e91ee4c56829995c08f4f8fb1052d3c6cc40c4.camel@kernel.org> <20230427-rebel-vergibt-99cf6a7838a2@brauner> Content-Type: text/plain; charset="ISO-8859-15" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.48.1 (3.48.1-1.fc38) MIME-Version: 1.0 X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: 8216A40025 X-Stat-Signature: j68i3rw8w9yiaqbg4ka97u7wccobcezr X-Rspam-User: X-HE-Tag: 1682589469-972394 X-HE-Meta: U2FsdGVkX19bfWXEo47UrS/Sf7sWx2zfOXz5GgtxHpKBvTzFa4x+xPqcd40WWh4nSwEz3E22uyOcnNmcvrlepEPgVrwpuDY8UYlm7yaYaWPFdqiO3rJVkAaAmDn7InJMQUPvz7xXKZ80jQZv8G11G1uLnve/LWGz2PHpE8PAm1KYSXblS9oqIlEUqmKTnNVnvzqJrFrCHz0vOPuDVV0pa6Ask7pA0PLV/JgsMxbbWp+ttRtzGeAGaLpH8SYImhNiI25z/ghB7z+/vc0kBZ5X8Apj1JKBUB9CPcZvey6+u9AG7EIKAtkTV+fdl87WlmNGdsgvA3K0Ipq1Ve8crpRIXJno04ag1QK0GH1tlRU7+Ush83iO32fNvAWqk9+1FVwurgYOz28/8n3qcwjq7BhfmbE+Sh+xlpP/ebcwOXoXLW7Pibwl++s+JZhze9EPXoKjWgyjXElCaorbrfpp22gMHVlpngji8yKt3Q8qcG5qTRG2B64IfzUKEkSgiyj8d7q3KS9+k2ucjZNMbCDg5I9mnR0OprqlKl5ZPgACdTlN+N+nYD8kqiW+9bmSCDjhpaFRFm7bhQnnob35pIG3faj2Meh4hZdeNQ5ZobAhsWEx9axTvt2RyfMq2cqkqxXrJzklYuDfPEhr2nOAMexWnz9w3UH8FFqjfWx1Cl50/R3miIljaeiBsYuLsmMf8D+q7rh3APkYyYqZZ7LC+5I3ARJUWUm2U6ndsiH2g14bagfoQM9o4mrGFSmO4D53mdFb2xv3/TxE+hkXXfLEXV1YeOCAnbiO7bMA8dnexrxAgMMyQRRngtZwdgGenBSkZbY0wYpAtF0n4Id3OBYY4ld8SBBm9MRaqXJFgBznO4OO5xQZjuvTlqHp1wNBlwM5h7KZYQvkT78DziGYfpvbBjxIpQ/HHda5FSueQDOzcQL7ne0n1DXFdnl3vZRKeKbHDkX24ADnA61Iq6Uf01SwWFlnJ9y gxnA8G7k l6Q1tupYpKjjhwX3L68HtZjFAFlWh3dwQkv865MaYzphdJyE3eQCcbWj5kg0fTx2aCHi8Ks1ffto3gka33lB7vWOTbk4sLbM3t3N7tGIY9UbitkLcxsByUZmsSQ0ZSXKQUggSs1NuRhnZmRaiIPzA6dI5yg5xOrY0KpIo1FSdB136X9F+/4iF63/TBuz05DQCxQL88rYRxXJ6eAotx70xynfjZo3Ekcky4u1gnBIk5508Icgp+VLKP3Kj+eEZVnMIFqV4oZTy/guMpleuDEfZhGMlrlBWxwBquCILQuhEAUoWlIJiUt6+n+8kAv5U+PMhs4wGfPgNmkXvmR9876NZVMveYqNcBNoYvlF5a6tSSidqOq8T1OVKLUyr7466fqAxtswb4w0/m4QZKuw= 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 Thu, 2023-04-27 at 11:51 +0200, Christian Brauner wrote: > On Wed, Apr 26, 2023 at 05:48:38AM -0400, Jeff Layton wrote: > > On Wed, 2023-04-26 at 09:07 +0200, Christian Brauner wrote: > > > On Mon, Apr 24, 2023 at 11:11:02AM -0400, Jeff Layton wrote: > > > > The VFS always uses coarse-grained timestamp updates for filling ou= t 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. > > > >=20 > > > > Unfortunately, this has always been an issue when we're exporting v= ia > > > > NFSv3, which relies on timestamps to validate caches. Even with NFS= v4, a > > > > lot of exported filesystems don't properly support a change attribu= te > > > > and are subject to the same problems with timestamp granularity. Ot= her > > > > applications have similar issues (e.g backup applications). > > > >=20 > > > > Switching to always using fine-grained timestamps would improve the > > > > situation for NFS, but that becomes rather expensive, as the underl= ying > > > > filesystem will have to log a lot more metadata updates. > > > >=20 > > > > What we need is a way to only use fine-grained timestamps when they= are > > > > being actively queried: > > > >=20 > > > > 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 c= an > > > > use the lowest-order bit of the inode->i_ctime as a flag to indicat= e > > > > that the value has been queried. Then on the next write, we'll fetc= h a > > > > fine-grained timestamp instead of the usual coarse-grained one. > > > >=20 > > > > 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 files= ystems > > > > to opt-in to this behavior. > > >=20 > > > Hm, the patch raises the flag in s_flags. Please at least move this t= o > > > s_iflags as SB_I_MULTIGRAIN and treat this as an internal flag. There= 's > > > no need to give the impression that this will become a mount option. > > >=20 > > > Also, this looks like it's a filesystem property not a superblock > > > property as the granularity isn't changeable. So shouldn't this be an > > > FS_* flag instead? > >=20 > > It could be a per-sb thing if there was some filesystem that wanted to > > do that, but I'm hoping that most will not want to do that. >=20 > Yeah, I'd really hope this isn't an sb thing. >=20 > >=20 > > My initial patches for this actually did use a FS_* flag, but I figured >=20 > Oh, I might've just missed that. >=20 Sorry, I didn't actually post that set. But I did go with a FS_* flag before I made it a SB_* flag. > > that was one more pointer to chase when you wanted to check the flag. >=20 > Hm, unless you have reasons to think that it would be noticable in terms > of perf I'd rather do the correct thing and have it be an FS_* flag. Sure. I'll make the switch before the next posting. Thanks for the review! --=20 Jeff Layton