fsid change of ZFS?

[Hiroki Sato]

Rick Macklem <rmacklem at uoguelph.ca> wrote
  in <1565511281.69213.1313764157732.JavaMail.root at erie.cs.uoguelph.ca>:

rm> Hiroki Sato wrote:
rm> > fsid_guid = dmu_objset_fsid_guid(zfsvfs->z_os);
rm> > ASSERT((fsid_guid & ~((1ULL<<56)-1)) == 0);
rm> > vfsp->vfs_fsid.val[0] = fsid_guid;
rm> > vfsp->vfs_fsid.val[1] = ((fsid_guid>>32) << 8) |
rm> > vfsp->mnt_vfc->vfc_typenum & 0xFF;
rm> >
rm> > Since the vfc_typenum variable is incremented every time a new vfs is
rm> > installed, loading order of modules that call vfs_register() affects
rm> > ZFS's fsid.
rm> >
rm> > Anyway, possibility of fsid change is troublesome especially for an
rm> > NFS server with a lot of clients running. Can zeroing or setting a
rm> > fixed value to the lowest 8-bit of vfs_fsid.val[1] be harmful?
rm> >
rm> > -- Hiroki
rm> Well, the problem is that the fsid needs to be unique among all mounts.
rm> The vfs_typenum field is used to try and ensure that it does not end up
rm> the same value as a non-ZFS file system.
rm>
rm> (A) I think making that field a fixed constant should be ok, if the function
rm> checks for a conflict by calling vfs_getvfs() to check for one.
rm> See vfs_getnewfsid() for how this is done. (There is a mutex lock that
rm> needs to be held while doing it.) Alternately, if ZFS can call vfs_getnewfsid()
rm> instead of doing its own, that might be nicer?
rm>
rm> (B) Another way to fix this would be to modify vfs_register() to look up
rm> file systems in a table (by vfc_name) and used a fixed, assigned value
rm> from the table for vfc_typenum for entries found in the table. Only do
rm> the "maxvfsconf++" when there isn't an entry for the fstype in the table.
rm> (VFS_GENERIC can be set to the size of the table. That's what happened
rm>  in the bad old days when vfsconf was a table built at kernel config time.)
rm>
rm> If you guys think (B) is preferred, I could come up with a patch. I don't
rm> know enough about ZFS to do (A).

rm> Oh, and I think other fs types will suffer the same fate, except that
rm> they usually avoid it, because they are compiled into the kernel and
rm> the assignment of vfs_typenum happens in the same order-->same value.

 Yes, using vfs_getnewfsid() does not solve the issue.

 I noticed that Solaris looked up a fixed array vfssw[] exactly for
 the purpose.  I think a table like it is a good solution for fixing
 fsid for each file system.

-- Hiroki
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20110820/ff599acd/attachment.pgp