Re: fsid change of ZFS?

Hiroki Sato wrote:
> 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
If anyone thinks using a fixed table to assign vfc_typenum for known
file system types is a bad idea, please let us know.

Otherwise I will make up a patch, rick