Date: Mon, 22 Aug 2011 00:27:23 -0400 (EDT) From: Benjamin Kaduk <kaduk@MIT.EDU> To: Rick Macklem <rmacklem@uoguelph.ca> Cc: pjd@freebsd.org, current@freebsd.org Subject: Re: fsid change of ZFS? Message-ID: <alpine.GSO.1.10.1108220019120.7526@multics.mit.edu> In-Reply-To: <917325587.123830.1313933050111.JavaMail.root@erie.cs.uoguelph.ca> References: <917325587.123830.1313933050111.JavaMail.root@erie.cs.uoguelph.ca>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 21 Aug 2011, Rick Macklem wrote:
> Benjamin Kaduk wrote:
>> On Sat, 20 Aug 2011, Rick Macklem wrote:
>>
>>> 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.)
Yes; I assume this is just so that it can keep track of how to efficiently
allocate an id to the next filesystem that is registered. It still walks
the whole list in vfs_unregister, though, so there is some amount of
overhead involved.
>
> Then, vfs_sysctl() returns maxvfsconf for a sysctl. I don't know what uses
vfs_sysctl() also starts off with:
printf("WARNING: userland calling deprecated sysctl, "
"please rebuild world\n");
I don't know where (if anywhere) it is legitimately used, but it is
plausible that it could safely be deprecated.
> 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?
I don't think tracking maxvfsconf would be useful with a hash table
approach -- fxr seems to indicate that it is only used so as to give a
unique number to a new filesystem, and a hash table with collision
detection could perform that role.
But, I don't have a good assessment of the tradeoffs involved. It may not
be worth the code churn just for the sake of a couple of out-of-tree
filesystems that never get exported over NFS; I just don't know.
-Ben
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?alpine.GSO.1.10.1108220019120.7526>