Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 12 Sep 2010 19:14:41 +0300
From:      Kostik Belousov <kostikbel@gmail.com>
To:        Rick Macklem <rmacklem@uoguelph.ca>
Cc:        svn-src-head@freebsd.org, Rick Macklem <rmacklem@freebsd.org>, svn-src-all@freebsd.org, src-committers@freebsd.org
Subject:   Re: svn commit: r212439 - head/sys/fs/nfs
Message-ID:  <20100912161441.GC2465@deviant.kiev.zoral.com.ua>
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

--YjUCIDG0UL7zSTfa
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Sat, Sep 11, 2010 at 08:41:22PM -0400, Rick Macklem wrote:
> > Then, fid_reserved is no more reserved ? Should we rename it ?
> >=20
> > Comment for fid_reserved about longword alignment is wrong.
>=20
> 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.
>=20
> 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.)
>=20
> 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.
>=20
> 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.)
>=20
> Or, you could just rename fid_reserved to fid_pad and not worry about it.
>=20
> Maybe the ZFS folks could decide what they would prefer? rick
Let at least rename the field. And I propose the name like fid_data0
or similar, not the fid_pad, to signify that it is used.

--YjUCIDG0UL7zSTfa
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (FreeBSD)

iEYEARECAAYFAkyM/HEACgkQC3+MBN1Mb4ia1wCghknTOCGYyrBGOXm2fpwRBI6b
tfAAn3OnmFhDJgHNJg3q1dc117Wsx8f0
=4iR1
-----END PGP SIGNATURE-----

--YjUCIDG0UL7zSTfa--



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20100912161441.GC2465>