On May 14, 2008, at 5:38 AM, Frank Batschulat (Home) wrote: > On Wed, 14 May 2008 13:00:13 +0200, Calum Mackay > <Calum.Mackay at Sun.COM> wrote: > >> Frank is absolutely right: for v4 they have both the stable storage >> issue, and the way that v4 constructs its filehandles from ZFS. > > yep, I forgott to mention the other minor quirk involved, namely > that for ZFS > the device id (minor number) can change with every mount, as you've > discovered in zfs_vfsinit(), > ie. the device id is not persistant (as with e.g ufs) and this in > turn has implication to > the FSID attribute (build from the device id (vfs_dev) in the v4 > server) and it is just the FSID > attribute the client uses to determine if it is crossing server file > system boundaries, > for ZFS we'd use the fsid (vfs_fsid) (more on that further down) > instead of the usual stuff we find in va_attr struct, > which may cause additional side effects. Again not an issue for V3. > > and the fact that the ZFS fsid (vfs_fsid) is unique to a given > system and the fsid is embedded into the > filehandle, ZFS does construct the fsid in zfs_init_fs() upon mount > time: > > 314 * The fsid is 64 bits, composed of an 8-bit fs type, which > 315 * separates our fsid from any other filesystem types, and a > 316 * 56-bit objset unique ID. The objset unique ID is unique > to > 317 * all objsets open on this system, provided by > unique_create(). > 318 * The 8-bit fs type must be put in the low bits of fsid[1] > 319 * because that's where other Solaris filesystems put it. > 320 */ > 321 fsid_guid = dmu_objset_fsid_guid(os); > 322 ASSERT((fsid_guid & ~((1ULL<<56)-1)) == 0); > 323 zfsvfs->z_vfs->vfs_fsid.val[0] = fsid_guid; > 324 zfsvfs->z_vfs->vfs_fsid.val[1] = ((fsid_guid>>32) << 8) | > 325 zfsfstype & 0xFF; > > however UFS instead uses vfs_make_fsid() for the same purpose in > mountfs() > > 907 vfs_make_fsid(&vfsp->vfs_fsid, dev, ufsfstype); > > the latter is likely going to be unique on 2 systems with the same > major/minor for the > device hosting a UFS file system, the former for ZFS unlikely. > > Urghh...I hope I got that all straight ;-) > Hi Frank, good description.
The only thing I'll add is a little history. Our NFS server (v2/v3/v4) has always embedded vfs_fsid within file handles. Initially, our NFS4 server built FATTR4_FSID from va_fsid/vfs_dev. Since ZFS changes these values at mount time, they cannot be used to build the FATTR4_FSID attribute. To correct this for sharing ZFS without breaking shares of other FS types (UFS), the VSW_VOLATILEDEV flag was created. Now the NFS4 server checks for the flag, and when set, it builds FATTR4_FSID from vfs_fsid instead of va_fsid/vfs_dev. Jeff
