Re: fsid change of ZFS?

From: Rick Macklem <rmacklem_at_uoguelph.ca>
Date: Sun, 21 Aug 2011 09:24:10 -0400 (EDT)
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_at_freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to
> "freebsd-current-unsubscribe_at_freebsd.org"
Received on Sun Aug 21 2011 - 11:24:11 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:16 UTC