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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 20FEDECAAD5 for ; Fri, 9 Sep 2022 20:45:02 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231540AbiIIUo4 (ORCPT ); Fri, 9 Sep 2022 16:44:56 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:37656 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229890AbiIIUou (ORCPT ); Fri, 9 Sep 2022 16:44:50 -0400 X-Greylist: delayed 613 seconds by postgrey-1.37 at lindbergh.monkeyblade.net; Fri, 09 Sep 2022 13:44:35 PDT Received: from mail.stoffel.org (li1843-175.members.linode.com [172.104.24.175]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id B6AD518E3C; Fri, 9 Sep 2022 13:44:28 -0700 (PDT) Received: from quad.stoffel.org (068-116-170-226.res.spectrum.com [68.116.170.226]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by mail.stoffel.org (Postfix) with ESMTPSA id 7A8FB270B5; Fri, 9 Sep 2022 16:34:14 -0400 (EDT) Received: by quad.stoffel.org (Postfix, from userid 1000) id 2733AA7E79; Fri, 9 Sep 2022 16:34:14 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <25371.41798.87576.861659@quad.stoffel.home> Date: Fri, 9 Sep 2022 16:34:14 -0400 From: "John Stoffel" To: Jeff Layton Cc: "J. Bruce Fields" , Theodore Ts'o , Jan Kara , NeilBrown , adilger.kernel@dilger.ca, djwong@kernel.org, david@fromorbit.com, trondmy@hammerspace.com, viro@zeniv.linux.org.uk, zohar@linux.ibm.com, xiubli@redhat.com, chuck.lever@oracle.com, lczerner@redhat.com, brauner@kernel.org, fweimer@redhat.com, linux-man@vger.kernel.org, linux-api@vger.kernel.org, linux-btrfs@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, ceph-devel@vger.kernel.org, linux-ext4@vger.kernel.org, linux-nfs@vger.kernel.org, linux-xfs@vger.kernel.org Subject: Re: [man-pages RFC PATCH v4] statx, inode: document the new STATX_INO_VERSION field In-Reply-To: <44efe219dbf511492b21a653905448d43d0f3363.camel@kernel.org> References: <79aaf122743a295ddab9525d9847ac767a3942aa.camel@kernel.org> <20220907125211.GB17729@fieldses.org> <771650a814ab1ff4dc5473d679936b747d9b6cf5.camel@kernel.org> <20220907135153.qvgibskeuz427abw@quack3> <166259786233.30452.5417306132987966849@noble.neil.brown.name> <20220908083326.3xsanzk7hy3ff4qs@quack3> <02928a8c5718590bea5739b13d6b6ebe66cac577.camel@kernel.org> <20220908155605.GD8951@fieldses.org> <9e06c506fd6b3e3118da0ec24276e85ea3ee45a1.camel@kernel.org> <20220908182252.GA18939@fieldses.org> <44efe219dbf511492b21a653905448d43d0f3363.camel@kernel.org> X-Mailer: VM 8.2.0b under 27.1 (x86_64-pc-linux-gnu) Precedence: bulk List-ID: X-Mailing-List: linux-btrfs@vger.kernel.org >>>>> "Jeff" == Jeff Layton writes: > On Thu, 2022-09-08 at 14:22 -0400, J. Bruce Fields wrote: >> On Thu, Sep 08, 2022 at 01:40:11PM -0400, Jeff Layton wrote: >> > Yeah, ok. That does make some sense. So we would mix this into the >> > i_version instead of the ctime when it was available. Preferably, we'd >> > mix that in when we store the i_version rather than adding it afterward. >> > >> > Ted, how would we access this? Maybe we could just add a new (generic) >> > super_block field for this that ext4 (and other filesystems) could >> > populate at mount time? >> >> Couldn't the filesystem just return an ino_version that already includes >> it? >> > Yes. That's simple if we want to just fold it in during getattr. If we > want to fold that into the values stored on disk, then I'm a little less > clear on how that will work. I wonder if this series should also include some updates to the various xfstests to hopefully document in code what this statx() call will do in various situations. Or at least document how to test it in some manner? Especially since it's layers on top of layers to make this work. My assumption is that if the underlying filesystem doesn't support the new values, it just returns 0 or c_time? John