On Sun, Sep 12, 2010 at 12:41 AM, Rick Macklem <rmack...@uoguelph.ca> wrote: >> 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]; > };
Isilon would love a generic struct like this, as to fit our filesystem we had to make such a change locally anyways. :-) Cheers, matthew > 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 > _______________________________________________ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"