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 ;-)
---
frankB
