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
Hiroki, could you please test the attached patch.

One problem with this patch is that I don't know how to create a fixed
table that matches what systems would already have been getting.
(I got the first 6 entries by booting a GENERIC i386 kernel with a
 printf in vfs_init(), so I suspect those don't change much, although
 I'm not sure if ZFS will usually end up before or after them?)

Do you guys know what ZFS gets assigned typically? (I realize that
changes w.r.t. when it gets loaded, so the question also becomes
"do you know how it typically gets loaded" so the table can have
that vfc_typenum value assigned to it?)
Maybe you could boot a system with a printf like:

printf("%s, %d\n", vfc->vfc_name, vfc->vfc_typenum);

just after vfc->vfc_typenum = maxvfsconf++; in vfs_init() and
then look in dmesg after booting, to see what your tables look like?
(Without the attached patch installed.)

Thanks, rick
ps: The patch is also at
     http://people.freebsd.org/~rmacklem/fsid.patch for anyone on
    the list interested (if the attachment doesn't make it through.


rick