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;
Message-ID: <b5359d06a57541accbe09172b77b8107678769c0.camel@gmail.com>
Subject: Re: [PATCH v2 4/4] NFSD: handle GETATTR conflict with write
 delegation
From:   Trond Myklebust <trondmy@gmail.com>
To:     Jeff Layton <jlayton@kernel.org>,
        Chuck Lever III <chuck.lever@oracle.com>,
        Dai Ngo <dai.ngo@oracle.com>,
        Olga Kornievskaia <aglo@umich.edu>
Cc:     Linux NFS Mailing List <linux-nfs@vger.kernel.org>,
        linux-fsdevel <linux-fsdevel@vger.kernel.org>
Date:   Mon, 15 May 2023 21:43:04 -0400
In-Reply-To: <927e6aaab9e4c30add761ac6754ba91457c048c7.camel@kernel.org>
References: <1684110038-11266-1-git-send-email-dai.ngo@oracle.com>
         <1684110038-11266-5-git-send-email-dai.ngo@oracle.com>
         <CAN-5tyH0GM8xOnLVDMQMn-tmoE-w_7N9ARmcwHq6ocySeoA1MQ@mail.gmail.com>
         <392379f7-4e28-fae5-a799-00b4e35fe6fd@oracle.com>
         <5318a050cbe6e89ae0949c654545ae8998ff7795.camel@kernel.org>
         <CAN-5tyFE3=DF+48SBGrC2u3y-MNr+1nM+xFM4CXaYv23AMZvew@mail.gmail.com>
         <30df13a02cbe9d7c72d0518c011e066e563bcbc8.camel@kernel.org>
         <17E187C9-60D6-4882-B928-E7826AA68F45@oracle.com>
         <927e6aaab9e4c30add761ac6754ba91457c048c7.camel@kernel.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
User-Agent: Evolution 3.48.1 (3.48.1-1.fc38) 
MIME-Version: 1.0
Precedence: bulk

On Mon, 2023-05-15 at 18:53 -0400, Jeff Layton wrote:
>=20
> Isn't CB_GETATTR the main benefit of a write delegation in the first
> place? A write deleg doesn't really give any benefit otherwise, as
> you
> can buffer writes anyway without one.
>=20
> AIUI, the point of a write delegation is to allow other clients (and
> potentially the server) to get up to date information on file sizes
> and
> change attr when there is a single, active writer.
>=20
> Without CB_GETATTR, your first stat() against the file will give you
> fairly up to date info (since you'll have to recall the delegation),
> but
> then you'll be back to the server just reporting the size and change
> attr that it has at the time.
>=20

The only advantage of CB_GETATTR is that it allows you to determine
whether or not the client holding the delegation is also holding cached
writes. Since we pretty much always rely on close-to-open semantics
anyway, the benefit of implementing it is pretty marginal.

Personally, I see CB_GETATTR as being more useful once servers start
implementing the timestamp/attribute delegations as per
https://datatracker.ietf.org/doc/draft-ietf-nfsv4-delstid/=C2=A0
Since those delegations allow the client to be authoritative for the
atime and mtime timestamps, and to also cache those, then CB_GETATTR
becomes a necessity in order to correctly timestamp writes that have
already been committed to the file.

--=20
Trond Myklebust
Linux NFS client maintainer, Hammerspace
trond.myklebust@hammerspace.com