Date: Sun, 12 Sep 2010 03:04:22 +0000 From: mdf@FreeBSD.org To: Rick Macklem <rmacklem@uoguelph.ca> Cc: Kostik Belousov <kostikbel@gmail.com>, svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org, Rick Macklem <rmacklem@freebsd.org> Subject: Re: svn commit: r212439 - head/sys/fs/nfs Message-ID: <AANLkTi=9sjFD2-=sZLwGPNcXNtG7hfAVk%2Bbck%2BDSYZMQ@mail.gmail.com> In-Reply-To: <1300087421.776986.1284252082593.JavaMail.root@erie.cs.uoguelph.ca> References: <20100911060111.GT2465@deviant.kiev.zoral.com.ua> <1300087421.776986.1284252082593.JavaMail.root@erie.cs.uoguelph.ca>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, Sep 12, 2010 at 12:41 AM, Rick Macklem <rmacklem@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
> =A0 =A0 =A0 =A0 =A0of the entire structure, including the Xfid_len field.
> =A0 =A0 =A0 =A0 =A0ZFS sets it to the size of the structure - sizeof(uint=
16_t)
> =A0 =A0 =A0 =A0 =A0{ presumably subtracting out the size if Xfid_len? }.
> =A0 =A0 =A0 =A0 =A0And xfs, well, it does weird stuff with it I can't fig=
ure
> =A0 =A0 =A0 =A0 =A0out, but it is definitely not the size of the entire s=
truct.
>
> 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 {
> =A0 =A0 =A0 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 {
> =A0 =A0 =A0 uint16_t fid_len;
> =A0 =A0 =A0 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
>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?AANLkTi=9sjFD2-=sZLwGPNcXNtG7hfAVk%2Bbck%2BDSYZMQ>