Date: Sat, 20 Aug 2011 18:07:40 -0400 (EDT) From: Rick Macklem <rmacklem@uoguelph.ca> To: Hiroki Sato <hrs@FreeBSD.org> Cc: pjd@FreeBSD.org, current@FreeBSD.org Subject: Re: fsid change of ZFS? Message-ID: <1522286016.115315.1313878060040.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <20110820.142859.319295417241413417.hrs@allbsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Hiroki Sato wrote: > Rick Macklem <rmacklem@uoguelph.ca> wrote > in <1565511281.69213.1313764157732.JavaMail.root@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1522286016.115315.1313878060040.JavaMail.root>