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 6B6BFC7619A for ; Sat, 15 Apr 2023 12:13:25 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id DDDDD6B0072; Sat, 15 Apr 2023 08:13:24 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id D67086B0075; Sat, 15 Apr 2023 08:13:24 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C09B36B0078; Sat, 15 Apr 2023 08:13:24 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id AEA946B0072 for ; Sat, 15 Apr 2023 08:13:24 -0400 (EDT) Received: from smtpin14.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 8EF7FC0129 for ; Sat, 15 Apr 2023 12:13:24 +0000 (UTC) X-FDA: 80683515528.14.11CA13B Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf04.hostedemail.com (Postfix) with ESMTP id C5FA440011 for ; Sat, 15 Apr 2023 12:13:22 +0000 (UTC) Authentication-Results: imf04.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=TIZnNaCc; spf=pass (imf04.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=1681560802; 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=oNggEOIjFPgoC9rxCTwXROJdaYG6kBG1EDQnXC/7JJQ=; b=YqwQoKjDhW61E38hMrTx+eiEfjwhB0FcOgMvychZFfgN6N6uIpKEI4SlJz22JeRjuu5njs iKpmcRKGQ6jx7C8pMKQaHOk8mPIt3uPOKswN1XKgRd1GFXmPZHHHULyxfE4PTKwF/wAPAk PK3uLLw6qe0NeSnDgClXD7+BWvSF/bw= ARC-Authentication-Results: i=1; imf04.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=TIZnNaCc; spf=pass (imf04.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=1681560802; a=rsa-sha256; cv=none; b=jOw2emBgfSj3SpvQrhl5Lp7ECmCL0mUQ8R+rIHucowxOQprg3FdMZHmzNRNH3CuuwPXvZV HZ836WoZhG4+Ft49MUhD+VVjZwg4fXwgaTI7l/62aYZx/G7RE+syYZDauyfEsdOgHxViYN sju6ljV2x8yy6pZeP2eIb/f5rbDA8lg= 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 C4B9660BC8; Sat, 15 Apr 2023 12:13:21 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id D93C6C433EF; Sat, 15 Apr 2023 12:13:19 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1681560801; bh=vISxtwgPDbbPk2EBE4+0qWc3uawfwrv6lg/w51U7c6M=; h=Subject:From:To:Cc:Date:In-Reply-To:References:From; b=TIZnNaCcjQcrtSjP8IynjFI1zOZE3ioOSGp+Xn3NEVkUwUEXcrwHvksQ98DP4NHpW 9Zx2SJ/mlVxxXSTmIGv/qSCXlFMtBnImrVbhnUv0Ur+hMnqUkmhE0Ks0XdjxDTc9uf ceCXE1LxO4OkhkFijr5SUnlAgCAcvKjIsPnx0C4nU1OQDh+fnp1vd6vJ+0WCpvOXiC 3XGbuoH61TENPu8kv3jwKXweUll2mdc/qmkkIq1eUwOZr8dAAnvX7x6Xb2G+K9Qh5F ZNn+GAhUJrngGxyhRHEc154VKiYwXivaxryFgHhYxlWV+B1QI2v2ivKCbTs6PASN7F IhmSdcNSSglqQ== Message-ID: Subject: Re: [RFC PATCH 0/3][RESEND] fs: opportunistic high-res file timestamps From: Jeff Layton To: Amir Goldstein , Dave Chinner Cc: Alexander Viro , Christian Brauner , "Darrick J. Wong" , Hugh Dickins , Andrew Morton , 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, Josef Bacik Date: Sat, 15 Apr 2023 08:13:18 -0400 In-Reply-To: References: <20230411143702.64495-1-jlayton@kernel.org> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.46.4 (3.46.4-1.fc37) MIME-Version: 1.0 X-Rspam-User: X-Rspamd-Server: rspam03 X-Stat-Signature: 83jppk7886qeq38fhwb7brm9sxhp46gz X-Rspamd-Queue-Id: C5FA440011 X-HE-Tag: 1681560802-755148 X-HE-Meta: U2FsdGVkX19RnSAaPC1IrLG5f1X5tUvZTOYrrFDWCycXMV6anRsgKD9tOp8XluClgG9umOjj/iqNpQDbanlmiBWt+VH4s5nQRTZBYrMTyJfXAxuWtm5EXBkAGX/l8KlOs/nPEsHcAdyihYZ6IvrutGao1ffi3kN3azHRdF0278PzXIgEARBeLhQ4O0AkiRwlA8Dcjg5PSLJ9ILftTLOl0I6HSf7/3+1BphOC1TimtCgsNUP7ErGvApZvOfZn0O5p1Gpt8XPGPc5M9xMqsFyAJz6Ta+IaQ0UANhA+b7dgx8HLCFA6eUISlpNsqXDKidyFSvCywUnq5SFrmQy41To9Sf+WCeTnvEK+Dv5++8lDAWmYulmG1JpTwl6vvDFZU73gpaX/wUxHpy3FKwoH56k4tsJkkm6UFlrY+h+X9E3qvOQ1MDsmU3PrECN0yPzajABU+eCVGaHqIrn89KMChKrAu2AJS1RI+LhpWU6pbc5kddNQDtUeyVduLurFk2UqrxyVFpbmGONfEsY4BNrSExRauB7cgNqSBI+2Zqbou0UrR/neB+mv3VwzQanitVdJi1Nza1LtBHhe/WA7Gci9SShR3wNOEu2rQq5Dt+D+OR5sD2g2crdDuta4aY5JM29dXKajsW/6oiMxKJgRh+EJZFSn2H/iWHo1cmraWTCxeJg6uN3Or6SHrT8lE+w2jb2DJMWfSbvK/dIxa6Y17FIw11R5fQxM1HoS0wSUkJQgRoNqNonhmL/KJp6/VcsL0043M5Aah1QYd8eYq2TgZ97gYYzcbLCmBBTOJoMQvRGvKKqh7g6lKTU9YmYjsxm3PC77pFYvJU2DIA6rG/VayM9KEMbsx1pvGpLqal0NEHq6T10WlPeGILy9RN4IBiDRKUBzWWuKhlJryuL5KxkIvTIDElrQ9tBKfilVR+Wv3bpNFDUMi/Jik4PeP90abuvj5mqFQmbDzB0jshlN9Jui00Rw4Vl AVf4xDB0 xkwdvc5KZ2uTlmm/prroW1+pBM2g6uGkK+0MevOKnEOEVKaUg9K/ZzZAFczXIwvQXxXUgTpSaO5s5ry5XMEeqlqah48SUVpJFu8p3jeV83vlOIBwIllEwM7SJ6fMA773oS/Z0+3KmgXA27A4etxnhj0qiZKngKDbAUZD/pbB97OcVEGRAJenOafjG7Ml7j5dtHQ4VYx82NZ0WGefS1Tzp2YH20GzTMt+KmYSedwszjdBQny3U9UijT/HWYNXQYwPzKjgRsZFeActjnL3FauEzDTrL2r3MN18hY9IW9JZotyAsET/pGb0mj/q5KA11vCmjO51znJLdnQf+1xDLz5DqQWojQ8y9jH47J02lLcnhqJfvmAjFANkrKtQmdB58KW4nG5tQQDA2+HIDmnQ= 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 Sat, 2023-04-15 at 14:35 +0300, Amir Goldstein wrote: > On Tue, Apr 11, 2023 at 5:38=E2=80=AFPM Jeff Layton = wrote: > >=20 > > (Apologies for the resend, but I didn't send this with a wide enough > > distribution list originally). > >=20 > > A few weeks ago, during one of the discussions around i_version, Dave > > Chinner wrote this: > >=20 > > "You've missed the part where I suggested lifting the "nfsd sampled > > i_version" state into an inode state flag rather than hiding it in > > the i_version field. At that point, we could optimise away the > > secondary ctime updates just like you are proposing we do with the > > i_version updates. Further, we could also use that state it to > > decide whether we need to use high resolution timestamps when > > recording ctime updates - if the nfsd has not sampled the > > ctime/i_version, we don't need high res timestamps to be recorded > > for ctime...." > >=20 > > While I don't think we can practically optimize away ctime updates > > like we do with i_version, I do like the idea of using this scheme to > > indicate when we need to use a high-res timestamp. > >=20 > > This patchset is a first stab at a scheme to do this. It declares a new > > i_state flag for this purpose and adds two new vfs-layer functions to > > implement conditional high-res timestamp fetching. It then converts bot= h > > tmpfs and xfs to use it. > >=20 > > This seems to behave fine under xfstests, but I haven't yet done > > any performance testing with it. I wouldn't expect it to create huge > > regressions though since we're only grabbing high res timestamps after > > each query. > >=20 > > I like this scheme because we can potentially convert any filesystem to > > use it. No special storage requirements like with i_version field. I > > think it'd potentially improve NFS cache coherency with a whole swath o= f > > exportable filesystems, and helps out NFSv3 too. > >=20 > > This is really just a proof-of-concept. There are a number of things we > > could change: > >=20 > > 1/ We could use the top bit in the tv_sec field as the flag. That'd giv= e > > us different flags for ctime and mtime. We also wouldn't need to use > > a spinlock. > >=20 > > 2/ We could probably optimize away the high-res timestamp fetch in more > > cases. Basically, always do a coarse-grained ts fetch and only fetch > > the high-res ts when the QUERIED flag is set and the existing time > > hasn't changed. > >=20 > > If this approach looks reasonable, I'll plan to start working on > > converting more filesystems. > >=20 > > One thing I'm not clear on is how widely available high res timestamps > > are. Is this something we need to gate on particular CONFIG_* options? > >=20 > > Thoughts? >=20 > Jeff, >=20 > Considering that this proposal is pretty uncontroversial, > do you still want to discuss/lead a session on i_version changes in LSF/M= M? >=20 > I noticed that Chuck listed "timespamt resolution and i_version" as part > of his NFSD BoF topic proposal [1], but I do not think all of these topic= s > can fit in one 30 minute session. >=20 Agreed. I think we'll need an hour for the nfsd BoF. I probably don't need a full 30 min slot for this topic, between the nfsd BoF and hallway track. I've started a TOPIC email for this about 5 times now, and keep deleting it. I think most of the more controversial bits are pretty much settled at this point, and the rest (crash resilience) is still too embryonic for discussion. I might want a lightning talk at some point about what I'd _really_ like to do long term with the i_version counter (basically: I want to be able to do a write that is gated on the i_version not having changed). > Dave, >=20 > I would like to use this opportunity to invite you and any developers tha= t > are involved in fs development and not going to attend LSF/MM in-person, > to join LSF/MM virtually for some sessions that you may be interested in. > See this lore query [2] for TOPICs proposed this year. >=20 > You can let me know privately which sessions you are interested in > attending and your time zone and I will do my best to schedule those > sessions in time slots that would be more convenient for your time zone. >=20 > Obviously, I am referring to FS track sessions. > Cross track sessions are going to be harder to accommodate, > but I can try. >=20 > Thanks, > Amir. >=20 > [1] https://lore.kernel.org/linux-fsdevel/FF0202C3-7500-4BB3-914B-DBAA3E0= EA3D7@oracle.com/ > [2] https://lore.kernel.org/linux-fsdevel/?q=3DLSF+TOPIC+-re+d%3A4.months= .ago.. --=20 Jeff Layton