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