Skip site navigation (1)Skip section navigation (2)
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>