Date: Sun, 21 Aug 2011 09:24:10 -0400 (EDT) From: Rick Macklem <rmacklem@uoguelph.ca> To: Benjamin Kaduk <kaduk@MIT.EDU> Cc: pjd@freebsd.org, current@freebsd.org Subject: Re: fsid change of ZFS? Message-ID: <917325587.123830.1313933050111.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <alpine.GSO.1.10.1108202308530.7526@multics.mit.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
Benjamin Kaduk wrote: > On Sat, 20 Aug 2011, Rick Macklem wrote: > > >> 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. > > Fixed table sounds like a good plan. > Is there a reason for/against using a hash table for types that are > not in > the fixed table? The advantage would be that out-of-tree filesystems > get > a consistent typenum (modulo hash collisions), but there would be more > overhead in maintaining the table. > Well, the current code maintains maxvfsconf as the largest value of vfc_typenum configured. (vfs_register() increases it and vfs_unregister() shrinks it back down.) Then, vfs_sysctl() returns maxvfsconf for a sysctl. I don't know what uses that sysctl, but it seems that doing a hash on vfc_name (which I think was what you were suggesting?) would result in a large maxvfsconf with sparsely distributed vfc_typenum values. I don't know, but I suspect that wouldn't satisfy the desired sysctl() behaviour? rick > -Ben Kaduk > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to > "freebsd-current-unsubscribe@freebsd.org"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?917325587.123830.1313933050111.JavaMail.root>