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 35A71C77B73 for ; Thu, 27 Apr 2023 09:51:22 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 9A8CE6B0075; Thu, 27 Apr 2023 05:51:21 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 9592E900003; Thu, 27 Apr 2023 05:51:21 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 81FE76B007B; Thu, 27 Apr 2023 05:51:21 -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 717396B0075 for ; Thu, 27 Apr 2023 05:51:21 -0400 (EDT) Received: from smtpin21.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 3A5CD80249 for ; Thu, 27 Apr 2023 09:51:21 +0000 (UTC) X-FDA: 80726703162.21.A1C3DA4 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf21.hostedemail.com (Postfix) with ESMTP id 932E21C000A for ; Thu, 27 Apr 2023 09:51:19 +0000 (UTC) Authentication-Results: imf21.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=hAeaNsUl; spf=pass (imf21.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=1682589079; 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=4rK0q/jJlt39KNPIBOSGjo6K68wi43DN18U940kuFIk=; b=Q2x1jK6rgZPmVjejlgZHw4kxQilvVg2000RM8Vme1W/jzo95ULeDRAz19swlz0nd0DPmIY Ey8tES0/iioP80AmCshvPXoZwniOMA+Y1V6ldX8nsBor93qNWCa8+2nydrPslK7d7hHkiC rWK4CUMxYCNkY5ARsPX0Ga0KvZp0Eqk= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1682589079; a=rsa-sha256; cv=none; b=HxbOiwzshgI72sTxrZk5dfThX/RthcB0YT/noK/O4Mw/dorUBpZram11bxR6lTClDu1kfQ UkA6E/CAiADRzn0Ewd2iFPDay10kklC+oHnhOzu+U8cSvBPMp3OygEP80O5Q8l9hlaDNCY iCVCFFFxRjzgOHIUszqrYG6I3LFmzm8= ARC-Authentication-Results: i=1; imf21.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=hAeaNsUl; spf=pass (imf21.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 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 7843863C28; Thu, 27 Apr 2023 09:51:18 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id A43E0C433D2; Thu, 27 Apr 2023 09:51:14 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1682589077; bh=OKqC/Fnsu1vsusVxdSXuCgCvwxyUCqw4izqcT+HNaXM=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=hAeaNsUlLsGE6JMyqcbDRHusNAJCTXy7GhM0ol00rJtWeNKG023/SBrlPWeP+n9/C l18lgbscTr5KK3s5jScZKOXqaxr+4epdOWPQwfeE0T4We84Vb5aIp2kdExOo0UwWmn aPZJrVIQsdmz6aHQywpL9ZU8K1OlvFAPwFM4g2cKFCumkf9G/7mffElH2yxOHNlcNN l6OEWQjoGs6gl97UrUIyx9Y+wRSRYIu+HGRtxaFv3NDeEHV3ReZavAHuG3TikufKSI 2TAM+VtWJ3LRvz6AKHuQIZgH8wl7EMM200WwUclIfuajnhYnSbTu9Rn5AA5o2SHd4P Yh5hH1sRL+LHg== Date: Thu, 27 Apr 2023 11:51:11 +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: <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> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <03e91ee4c56829995c08f4f8fb1052d3c6cc40c4.camel@kernel.org> X-Rspam-User: X-Rspamd-Queue-Id: 932E21C000A X-Rspamd-Server: rspam09 X-Stat-Signature: kfp7ns9fq4fixpnp67aqjpjx45qy3i67 X-HE-Tag: 1682589079-228896 X-HE-Meta: U2FsdGVkX1+5j54a62JaQRh627ysm5TV73+xae1hf2C5xz36qBRNaTw6r+BbCMaigOvc50q5lIxrxfDvpeYA/QZgRvTtH6EAiYSp/b9cJ1rMhExTZ5xX/6QygZrM+aaHdVjENpt2J+BB4aeEP1kKBY9DsGDp2TG6MGfj99uWXFYBFPUjs5Q4AO/6fzN6A5Mzt8ht0B1kFrTLEqVoWretHwe7IPSD18KG7sGWqIzVk3cUiThcd2F/zegyK880umvCMZDIX5TE+qx3tuHFLoADFz+C2kIxm0gqsZh1cEQ0NvRl+PH7kIqcOgr8wvq1d9vVFDsWvX3kT2pImxNUOSA6WoLcZI//SQjGefq2aQR+1E6kL9MPvHB6FhGCFGnlU0yLUqpPOhanAlWAnZ+7pfb8ApRHRVyOcM/OYIYHzUQMnnnSXbxTmbISdTP9THzmFDDMMlzXFuvaigf+5YNhq5vOBp/mMOzTbRlsvPzlfcADbCarG68nC9LSEjIZ5FVn91E2KR9sNsMa2jMmy75t+OGZRPbzdVN12t6EsHyr3DldZV3NMVhCMsCTAC8GKAreCLw/suSNWYsNQ72iG83q4sQ5kPPpPd21c2jj0gwhZI8Ci2aoXZVNATktZ3/+9zd5y/dJNsxSVDg7rUCD7EOBu+uSBWNALovO7osieF33bOmKYJBknjEXMTupPuMz9eoe82sdynMoFVg82185juR6W+qqYS8VdfEvdgpFay0fftHYSy8a1Qdu0g6eDEqKk9sykg/+nHSSSzxMNW3htg0LBGikJpxq6p2zLuvRZekX3wCU4d/Gr7ELFymWEuvIBqqN56Y7ZhuJz9qVF3zx/SAFcRxUxFrJsp6bI22/Asq7/zHyEJgIG2Eg9ycrQ1DlEMEY9mpZD5MepUyNn/bNK2PyBTuN7GqFU8BrB5e7YSB9a0Toryd523wsG4cvLeopDuWGHEAV84Tni9XQMt9tfRPBKRx 0BDHUy1M zz3i4wSPqnMbmipLd2WjVBryLIBaWJfLkL/2UozxmtN2Dr/BcorLsUHRUJOvm/vF6oBSCbeTBlfDduGhVPWZUHfqTdmA0QnbysPQMRue3gD2OlhVBy5CcKwajhBa3Z5NpQy3ABKy0A+jgP+AIQ5OFyDEEuFOU4HAONQtX7mDJs6F1jyocUOOZ+X6XvEZyPw/TMGrTo079RiY285MZtQoqR1ZnH5EMrB98n3CmdKq68+SAgxcgBNGGg3t/rT0g3KbbP/ycbVUi+bCQcraLgq6NhJMRmcL05GnFZy3kuC4JT9wdubB6JcCTCxFwUVqrSz4MHZi4VXhXuDFZoAOOhqZ3DNeQmg== 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 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 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. > > > > Hm, the patch raises the flag in s_flags. Please at least move this to > > 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. > > > > 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? > > 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. Yeah, I'd really hope this isn't an sb thing. > > My initial patches for this actually did use a FS_* flag, but I figured Oh, I might've just missed that. > that was one more pointer to chase when you wanted to check the flag. 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.