Date: Sat, 20 Aug 2011 14:28:59 +0900 (JST) From: Hiroki Sato <hrs@FreeBSD.org> To: rmacklem@uoguelph.ca Cc: pjd@FreeBSD.org, current@FreeBSD.org Subject: Re: fsid change of ZFS? Message-ID: <20110820.142859.319295417241413417.hrs@allbsd.org> In-Reply-To: <1565511281.69213.1313764157732.JavaMail.root@erie.cs.uoguelph.ca> <1623060518.69434.1313764367817.JavaMail.root@erie.cs.uoguelph.ca> References: <20110819.224310.740411147168584392.hrs@allbsd.org> <1565511281.69213.1313764157732.JavaMail.root@erie.cs.uoguelph.ca>
next in thread | previous in thread | raw e-mail | index | archive | help
----Security_Multipart(Sat_Aug_20_14_28_59_2011_946)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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 ----Security_Multipart(Sat_Aug_20_14_28_59_2011_946)-- Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEABECAAYFAk5PRhwACgkQTyzT2CeTzy05OgCgg+cc8WedeU1yStBv1tj+Tu50 a+YAnjCz/s/kWr+lg2tOrNZANgmZlXw/ =5Ck0 -----END PGP SIGNATURE----- ----Security_Multipart(Sat_Aug_20_14_28_59_2011_946)----
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20110820.142859.319295417241413417.hrs>