Date: Tue, 23 Aug 2011 10:09:41 -0400 (EDT) From: Rick Macklem <rmacklem@uoguelph.ca> To: Pawel Jakub Dawidek <pjd@FreeBSD.org> Cc: Hiroki Sato <hrs@FreeBSD.org>, current@FreeBSD.org, Benjamin Kaduk <kaduk@MIT.EDU> Subject: Re: fsid change of ZFS? Message-ID: <1965813445.219973.1314108581091.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <20110823113044.GB1662@garage.freebsd.pl>
next in thread | previous in thread | raw e-mail | index | archive | help
Pawel Jakub Dawidek wrote:
> On Sat, Aug 20, 2011 at 08:15:34PM -0400, Rick Macklem wrote:
> > 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.)
>
> Rick, I'm sorry to arrive so late, but in my opinion hardcoding list
> of
> file systems in the kernel is a step in wrong direction, really.
> We are trying to keep things modularized, so there are no such things
> laying around that have to be cleaned up when file system goes away or
> updated when new file system arrives.
>
> I remember for example fts code where I found that it keeps list of
> file
> systems that can be handled faster. ZFS could have been handled
> faster,
> but I found this after few years.
> For this case there should be VFCF_* flag that fts shuld recognize and
> not
> hardcore file system names.
>
> This was also the reason that when I added support for "jail-friendly"
> file systems and support for file systems with delegated
> administration
> I haven't created list of file system types that support it, but added
> VFCF_JAIL and VFCF_DELEGADMIN flags.
>
> Here you cannot use those flags to solve the problem, but hardcoding
> file system types in an array is really not the way to go.
>
> I much prefer Ben's idea of calculating a hash from file system name
> and
> detecting collisions.
>
Ok, I'll admit I wasn't very fond of a fixed table that would inevitably
get out of date someday, either.
I didn't think hashing for the cases not in the table was worth the effort,
but doing a hash instead of a table seems reasonable.
I see that ZFS only uses the low order 8 bits, so I'll try and come up
with an 8bit hash solution and will post a patch for testing/review soon.
I don't think the vfs_sysctl() is that great a concern, given that it
appears to be deprecated already anyhow. (With an 8bit hash, vfs_typenum
won't be that sparse.) I'll also make sure that whatever hash I use
doesn't collide for the current list of file names (although I will include
code that handles a collision in the patch).
Thanks for the comments, rick
> --
> Pawel Jakub Dawidek http://www.wheelsystems.com
> FreeBSD committer http://www.FreeBSD.org
> Am I Evil? Yes, I Am! http://yomoli.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1965813445.219973.1314108581091.JavaMail.root>