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 CE090C77B60 for ; Wed, 26 Apr 2023 09:48:45 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 3127E6B00AB; Wed, 26 Apr 2023 05:48:45 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 29CE46B00AC; Wed, 26 Apr 2023 05:48:45 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 13E166B00AD; Wed, 26 Apr 2023 05:48:45 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id F35D26B00AB for ; Wed, 26 Apr 2023 05:48:44 -0400 (EDT) Received: from smtpin11.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id BB99F1601F1 for ; Wed, 26 Apr 2023 09:48:44 +0000 (UTC) X-FDA: 80723067768.11.2DB45E5 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf03.hostedemail.com (Postfix) with ESMTP id 073FC20012 for ; Wed, 26 Apr 2023 09:48:42 +0000 (UTC) Authentication-Results: imf03.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=MnriBQOs; spf=pass (imf03.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=1682502523; 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=fKAn3JdJz49gxav6mu33xI+JofckAtfi3Qw86pQyVsI=; b=mbfbARqI9fmXAgP0YYGS4CmmIS3BQRnB5zGeFZ3tbe687w7Wn6doxQwDiWMtPViN9cI4R0 k+U8wAhuEBKzPIGugrGOGRpBTlVC9c+cvD276eZ6DpFyGVmFDOuuq1PMTJUkzkWVj2s9DU yorSEdZUce2znpmQsZDyhx11w9s1UZU= ARC-Authentication-Results: i=1; imf03.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=MnriBQOs; spf=pass (imf03.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=1682502523; a=rsa-sha256; cv=none; b=g39FD1ej+crJ7bF5yeV8aBLnyN/etw7zILWC1MYSWuHbF/sW3jgtsO908JTQfwsma7gvgu jwSNJ/1mlxWunLGax2kXiCZf26ld/7Bo8lWVAaroIiN2OUrwCkvGAcNwx/IIdiZP0vDdZb USxMFhsM7mLgcmNFYhDAiJND0dI36IU= 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 152DC62C60; Wed, 26 Apr 2023 09:48:42 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 36850C433D2; Wed, 26 Apr 2023 09:48:40 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1682502521; bh=fKAn3JdJz49gxav6mu33xI+JofckAtfi3Qw86pQyVsI=; h=Subject:From:To:Cc:Date:In-Reply-To:References:From; b=MnriBQOsgstN1FHD7i/bvml1n93a5Q9WpM5q1PApF1KwiQ9ZETmc/XzUgNPJojGyi RzlzHFzgyaGQK3lRhSm/KIu7SRZx+yWVG4SMY1DVi6S/tr0f5DxvajgStflDZUkRlt EY+AVfZKNq9Rd+Hy4SJaH2EdTR6TlPDyweAxZhI9Sf0u5gt8sESBCMWEcqcYnVxzYl Uw/dw99iWYXuEam6NyMcON3IQ6TjyKMxAjRGEYGJ06nkqZKly0a6fRx9szLSjQWWrJ OLCJwPRLHOZ3HZ4sfiuaMUQ7OMUHmWBlTyfwtec7no4LFkCJidf3lGEILaToEnVzg8 iqosu2u0Otc+Q== Message-ID: <03e91ee4c56829995c08f4f8fb1052d3c6cc40c4.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: Wed, 26 Apr 2023 05:48:38 -0400 In-Reply-To: <20230426-bahnanlagen-ausmusterung-4877cbf40d4c@brauner> References: <20230424151104.175456-1-jlayton@kernel.org> <20230424151104.175456-2-jlayton@kernel.org> <20230426-bahnanlagen-ausmusterung-4877cbf40d4c@brauner> Content-Type: text/plain; charset="ISO-8859-15" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.48.0 (3.48.0-1.fc38) MIME-Version: 1.0 X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: 073FC20012 X-Rspam-User: X-Stat-Signature: keytjhcr3a91ct9w7j8kurc19ujx1ziw X-HE-Tag: 1682502522-370413 X-HE-Meta: U2FsdGVkX18WCpj5OY1VGdG/tCId0r46AyTuPaeYtzG4MLzp+I51E3HDTOtG71zLcTj0QcTL4Dih70fCfa8FUHTgkedqv/d4Slw/gs0jh8LY8T7ON6fFJo5ghS5eIYj6gTyaedm43QIom0HSeIXJcsZ9tdFUAb3RSW1g1k7L4fHBxdn/V2Bn4TQdP/EwMImZp88H3NVf1Y4t1CBHYx2K1L2Daay+H9gZ5gZhvEKK/dmFHzIjlBq4OciUjTXkf8ESVY4TCZxcNWkHPxnO2TTLozoQQYzaUL3lYgjhCLkdcoK6MhPFOMXFI0Fi614HEAJQ9kfgH8651Z3ExskMcEG5GL5qktHZ3UEk8uCPmDvy2GL4cqL2VxdBDMiQo1KiksygTgxbfBEqFWk10dIto/N8Ookc7tKP7fToySNmg4O6nY8foHxwf/tIE41LztosTcmbKG4jE+fWpRvZNqLPoCSwpzgf+OF9wcDZDbdCCJP00VVM1BHitaSAYy3oRtoLIl3hIiBvDfxj1GRnIKlGtd1BYIeCK28wTXWLSybR+t8UyOaWGR+L2vxOFDv3yljHyJLZPNwEoMJ6E0tvEJD6gIRG8uEL6EZwYYyCFx8tHmDv4hi1R7tx2bgRdiSxhcbWxXmMST2GYJrwLtjoJeAyGOggzT0OCGgdqsmma+qiHilKJh9uhHJkavnmtB9QHGZgSJy/GJ8RoGcIBk0V6A4ljIxSTwuQk7nJG8mUDxqxl+kC0l/ttC1jEDvtko+6S2AK9TNcYyGtCDGefgWlGGAHpBNfNkvZp2OSa5e276HwBfg3Bgq8oEr6Mqb6vXUD7n6rk9Mxo30AcZG35Sru2ytNYwaiaaA7UsfiCgQDW3xg8iWpjg9mZzPe/PwZC2wxrbLux7kcN4skYDkUXwfO0VtBqaktnJ2XMJg2Wy1dC6sxl9QioIKQTf/mhN89F/6/5/r/Gjnwx9GhWC5V2txU5Y0LbK0 NCBtM5nf Cv6wD0eYVFO0HuqiTJmTBUWmtgBuji6hr34+zijcKHimhbgJlLl3jS1eX152ttGJalrMiFug9qWRrGRYQAwx062eItT6M+nQx3cmtG+ituEUjldbJyzMjtYsqOsJgJezJ/oiPg3X7d6TygYaovj9FF+3YoBOMGGYILifFm4PXuPV3PmRvgjgvIpnU4v2Tj+h0npUGdP+OJp2A9bMsOUMz/goBYEmLtHbFZaKRjGQT5z5vWMNZcbjpeRg1/GmR1hUKuUQ5GkjdIP2CpzAaCVjuiIBIYhl7Q1uRQNR45RaD5EbRsremOrGZRF5hfXYRZUwt3h47XXfAsUpNbTb6tErTZwMn+n6xnsOgaCb65y2QdFMNQRMN8Hp8fGif/05hQ90JOnLsAuaKB3/pQnM= 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, 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 th= e > > 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 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). > >=20 > > 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. > >=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 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. > >=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 filesyste= ms > > to opt-in to this behavior. >=20 > 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. >=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? 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. My initial patches for this actually did use a FS_* flag, but I figured that was one more pointer to chase when you wanted to check the flag. I can change it back to that though. Let me know what you'd prefer. --=20 Jeff Layton