Received: by 2002:a05:6358:e9c4:b0:b2:91dc:71ab with SMTP id hc4csp2195598rwb; Fri, 5 Aug 2022 15:27:28 -0700 (PDT) X-Google-Smtp-Source: AA6agR5JsncKIqubQNN87Ro2nore8T+RPazB/d5Ra+Fun3paPAyVsKTWdlZYAMT96QBWPZSYEwnc X-Received: by 2002:a50:ff13:0:b0:43e:76d3:63e1 with SMTP id a19-20020a50ff13000000b0043e76d363e1mr8322355edu.271.1659738448099; Fri, 05 Aug 2022 15:27:28 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1659738448; cv=none; d=google.com; s=arc-20160816; b=JCOoqIdrN2PK91jffm0gXn48A4knAMiVx0ul+/FC+ALy2dlTUCG2T0UIz/RdFw8Mys 9IqgFYgD8fvNIkvpqecQXTtxgZ0kmIDur4GDo/xFddrrFywoasOZQhV9J41yL1rLKdsj sWEFN95RoGvUaKZL5MB1nWrU4GmhQWlKY+AnKfko44Fyd1Df9gq6xaOBc5TnwMYG5J3i 1Y6PbwsqdOkFhnLbVFEnV+3GO+dB1DFwDBRCDgY9SgceE3/YlS15GD+OGT1y7PXr2ZzM BsfIPKbVCSXziJ3f7ctcswz1H6i2jJC8Eubbj+mruTePwgdSc8HAEQJrvct26EW5lfL6 9DVg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:user-agent :content-transfer-encoding:references:in-reply-to:date:cc:to:from :subject:message-id:dkim-signature; bh=zlDrYXgDCUthUhiy73M1xjmezLFpu3vi4ADVmnqoFtM=; b=by0XM8dO26ihOPaLwtrwoeOn+ffnSsMZH/Ui+MjX+mrPrHroUo44LwXZg6OwMD3Wbc mSSUPrXq5cuvkXNlzn9+cBOCqPuKLFk2sfiHo92QGuCbVP5Oo0BAMVQpNWmoCqLxU6DX PgYUbKGn8VilaHk2DI3kSqrAma9XrD6ke725ybk6drCly+TEQZauZxPA5nxWkPfPvDnr SP4LDDLIr7fxaR5Mcb6owB9DGCkeznYnHu6X+E/fQZ1IsunCWwSL9G6vgwhB2zf4tNpW Oy5ko0JIp7Fu+b4uQSwbVU+iEWzmBn0xqlAqBqZUoKRAiVRih9NXv90X0fD01IL1Jt+K WSIg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=IZZ179FP; spf=pass (google.com: domain of linux-nfs-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-nfs-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id nd12-20020a170907628c00b007304f4611e6si2954815ejc.719.2022.08.05.15.27.02; Fri, 05 Aug 2022 15:27:28 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-nfs-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=IZZ179FP; spf=pass (google.com: domain of linux-nfs-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-nfs-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S241670AbiHEWGo (ORCPT + 99 others); Fri, 5 Aug 2022 18:06:44 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:57124 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S241632AbiHEWGn (ORCPT ); Fri, 5 Aug 2022 18:06:43 -0400 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id E69571209B for ; Fri, 5 Aug 2022 15:06:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1659737199; h=from:from: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; bh=zlDrYXgDCUthUhiy73M1xjmezLFpu3vi4ADVmnqoFtM=; b=IZZ179FP/9ItWRAObFFeQllCWkBijN1zarTlzOSekT8m1c3A8iTVUmVaq6T5F7iDd3PmTb avuzWnfr3EWEru75w6hpPOONLYmtIZMJBYkkUKxndsoiko79gOZyrc2zPbaS+/0Crwpt9o StmUl+KbQGTVG1O0yGhpdxAnAfcClWo= Received: from mail-qv1-f69.google.com (mail-qv1-f69.google.com [209.85.219.69]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-135-ckWTE2zxNqqdAAa9enyXSA-1; Fri, 05 Aug 2022 18:06:38 -0400 X-MC-Unique: ckWTE2zxNqqdAAa9enyXSA-1 Received: by mail-qv1-f69.google.com with SMTP id o9-20020a0cecc9000000b0047491274bb1so2114934qvq.19 for ; Fri, 05 Aug 2022 15:06:38 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=mime-version:user-agent:content-transfer-encoding:references :in-reply-to:date:cc:to:from:subject:message-id:x-gm-message-state :from:to:cc; bh=zlDrYXgDCUthUhiy73M1xjmezLFpu3vi4ADVmnqoFtM=; b=myZjWiBKbv/LbcJB62ZsC0bZ48aYOobVKFYNWvFvU522wwQY0XG3a0BsUwoIZmK5is 5D69KBNLAGo5iz9BNHNLvuY+bZlWNOWHEb35fMePPVzzB2SMeW4Z1A2mDPj14s1A81F3 b51x60tUgMtyInvZLR1PzCUzBB1uRVbPH+A9zCC6gcFVxG7pwVz/ZogtFNsImoCbtpfX tAGPrw9/tuFxMTlzqiJRy5P05szA5wwEFb10UZnKTIpMFJ2c/S8DyusLWc8s3ULp9D4i /hpsOnNjeBNNQzzEMN5oCIpmPGLMbOJnA+3DWTH29qGpbo+tLHNwWHrbBfJk6jdQ52bq Iz8g== X-Gm-Message-State: ACgBeo3zHu3ItBq4k/WUC9CzM4y5qeGXauJ3sgIU94sQ3m1Pl0rltAoY 8Pygzdma1I/dK33d40jkcgQKKCsBm2Yk+IdjeVPP92beH9GG/em41iDFr0KWz/Xrcu5y2S4DgjG Ijx/ovWsT1Kz1oZ61l/G+ X-Received: by 2002:a05:620a:170e:b0:6b8:fa02:6110 with SMTP id az14-20020a05620a170e00b006b8fa026110mr6704344qkb.184.1659737198077; Fri, 05 Aug 2022 15:06:38 -0700 (PDT) X-Received: by 2002:a05:620a:170e:b0:6b8:fa02:6110 with SMTP id az14-20020a05620a170e00b006b8fa026110mr6704322qkb.184.1659737197860; Fri, 05 Aug 2022 15:06:37 -0700 (PDT) Received: from [192.168.1.3] (68-20-15-154.lightspeed.rlghnc.sbcglobal.net. [68.20.15.154]) by smtp.gmail.com with ESMTPSA id g18-20020a05620a40d200b006b5f9b7ac87sm4514981qko.26.2022.08.05.15.06.37 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 05 Aug 2022 15:06:37 -0700 (PDT) Message-ID: Subject: Re: [RFC PATCH 1/4] vfs: report change attribute in statx for IS_I_VERSION inodes From: Jeff Layton To: Dave Chinner Cc: linux-fsdevel@vger.kernel.org, dhowells@redhat.com, lczerner@redhat.com, bxue@redhat.com, ceph-devel@vger.kernel.org, linux-nfs@vger.kernel.org, linux-afs@lists.infradead.org, linux-ext4@vger.kernel.org, linux-xfs@vger.kernel.org, linux-btrfs@vger.kernel.org Date: Fri, 05 Aug 2022 18:06:36 -0400 In-Reply-To: <20220805220136.GG3600936@dread.disaster.area> References: <20220805183543.274352-1-jlayton@kernel.org> <20220805183543.274352-2-jlayton@kernel.org> <20220805220136.GG3600936@dread.disaster.area> Content-Type: text/plain; charset="ISO-8859-15" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.44.3 (3.44.3-1.fc36) MIME-Version: 1.0 X-Spam-Status: No, score=-3.4 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_LOW, SPF_HELO_NONE,SPF_NONE,T_SCC_BODY_TEXT_LINE autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-nfs@vger.kernel.org On Sat, 2022-08-06 at 08:01 +1000, Dave Chinner wrote: > On Fri, Aug 05, 2022 at 02:35:40PM -0400, Jeff Layton wrote: > > From: Jeff Layton > >=20 > > Claim one of the spare fields in struct statx to hold a 64-bit change > > attribute. When statx requests this attribute, do an > > inode_query_iversion and fill the result in the field. > >=20 > > Also update the test-statx.c program to fetch the change attribute as > > well. > >=20 > > Signed-off-by: Jeff Layton > > --- > > fs/stat.c | 7 +++++++ > > include/linux/stat.h | 1 + > > include/uapi/linux/stat.h | 3 ++- > > samples/vfs/test-statx.c | 4 +++- > > 4 files changed, 13 insertions(+), 2 deletions(-) > >=20 > > diff --git a/fs/stat.c b/fs/stat.c > > index 9ced8860e0f3..976e0a59ab23 100644 > > --- a/fs/stat.c > > +++ b/fs/stat.c > > @@ -17,6 +17,7 @@ > > #include > > #include > > #include > > +#include > > =20 > > #include > > #include > > @@ -118,6 +119,11 @@ int vfs_getattr_nosec(const struct path *path, str= uct kstat *stat, > > stat->attributes_mask |=3D (STATX_ATTR_AUTOMOUNT | > > STATX_ATTR_DAX); > > =20 > > + if ((request_mask & STATX_CHGATTR) && IS_I_VERSION(inode)) { > > + stat->result_mask |=3D STATX_CHGATTR; > > + stat->chgattr =3D inode_query_iversion(inode); > > + } >=20 > If you're going to add generic support for it, shouldn't there be a > generic test in fstests that ensures that filesystems that advertise > STATX_CHGATTR support actually behave correctly? Including across > mounts, and most importantly, that it is made properly stable by > fsync? >=20 > i.e. what good is this if different filesystems have random quirks > that mean it can't be relied on by userspace to tell it changes have > occurred? Absolutely. Being able to better test the i_version field for consistent behavior is a primary goal. I haven't yet written any yet, but we'd definitely want something in xfstests if we decide this is worthwhile. --=20 Jeff Layton