Hi Tigran,
On Wed, 2020-11-04 at 11:12 +0100, Mkrtchyan, Tigran wrote:
>
>
> ----- Original Message -----
> > From: trondmy@xxxxxxxxxx
> > To: "linux-nfs" <linux-nfs@xxxxxxxxxxxxxxx>
> > Sent: Tuesday, 3 November, 2020 16:33:29
> > Subject: [PATCH v2 16/16] NFS: Improve handling of directory
> > verifiers
>
> > From: Trond Myklebust <trond.myklebust@xxxxxxxxxxxxxxx>
<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@xxxxxxxxxxxxxxx
