Re: [PATCH v2 16/16] NFS: Improve handling of directory verifiers

[Trond Myklebust <trondmy@hammerspace.com>]

Hi Tigran,

On Wed, 2020-11-04 at 11:12 +0100, Mkrtchyan, Tigran wrote:
> 
> 
> ----- Original Message -----
> > From: trondmy@kernel.org
> > To: "linux-nfs" <linux-nfs@vger.kernel.org>
> > Sent: Tuesday, 3 November, 2020 16:33:29
> > Subject: [PATCH v2 16/16] NFS: Improve handling of directory
> > verifiers
> 
> > From: Trond Myklebust <trond.myklebust@hammerspace.com>
<snip>
> > @@ -89,6 +94,7 @@ struct nfs_open_context {
> > struct nfs_open_dir_context {
> >         struct list_head list;
> >         unsigned long attr_gencount;
> > +       __be32  verf[NFS_DIR_VERIFIER_SIZE];
> >         __u64 dir_cookie;
> >         __u64 dup_cookie;
> >         signed char duped;
> > @@ -156,7 +162,7 @@ struct nfs_inode {
> >          * This is the cookie verifier used for NFSv3 readdir
> >          * operations
> >          */
> > -       __be32                  cookieverf[2];
> > +       __be32                  cookieverf[NFS_DIR_VERIFIER_SIZE];
> 
> Just for my education. Why we use 2x32 bit BE encoded ints instead of
> raw 8 bytes?
> And if it's treaded as a number, as spec sometimes does ("The
> request's cookieverf
> field should be set to 0"), then why it's not then __be64?

The main reason for often using __be32 on these identifiers is to tag
them as being opaque RPC objects (since RPC objects are always in units
of 32-bits and are big endian encoded).

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