svn commit: r212439 - head/sys/fs/nfs

[Rick Macklem]

> Then, fid_reserved is no more reserved ? Should we rename it ?
> 
> Comment for fid_reserved about longword alignment is wrong.

Well, it's actually more broken than that.
fid_len - Most file systems set it to the size of their variant
          of the entire structure, including the Xfid_len field.
          ZFS sets it to the size of the structure - sizeof(uint16_t)
          { presumably subtracting out the size if Xfid_len? }.
          And xfs, well, it does weird stuff with it I can't figure
          out, but it is definitely not the size of the entire struct.

As such, exposing fid_len above the VOP_xxx() doesn't make much sense.
(After my commit yesterday, nothing above the VOP_VPTOFH() uses it.)

Personally, I'd lean towards a generic struct fid like...
struct fid {
       uint8_t fid_data[MAXFIDSZ];
};
with MAXFIDSZ increased appropriately, but this will require changes
to xfs and zfs, since they both set the generic fid_len.

If you go with...
struct fid {
       uint16_t fid_len;
       uint8_t fid_data[MAXFIDSZ];
};
then the hash functions in the two NFS servers need to be changed
(they assume 32bit alignment of fid_data), but they should be fixed
anyhow, since they mostly hash to 0 for ZFS at this time. (From what
I see ZFS file handles looking like.)

Or, you could just rename fid_reserved to fid_pad and not worry about it.

Maybe the ZFS folks could decide what they would prefer? rick