Re: fsid change of ZFS?

Rick Macklem <rmacklem_at_uoguelph.ca> wrote
  in <468764384.310026.1314219682612.JavaMail.root_at_erie.cs.uoguelph.ca>:

rm> Pawel Jakub Dawidek wrote:
rm> > On Wed, Aug 24, 2011 at 04:41:25PM +0300, Kostik Belousov wrote:
rm> > > On Wed, Aug 24, 2011 at 09:36:37AM -0400, Rick Macklem wrote:
rm> > > > Well, doesn't this result in the same issue as the fixed table?
rm> > > > In other words, the developer has to supply the "suggested byte"
rm> > > > for
rm> > > > fsid and make sure that it doesn't conflict with other "suggested
rm> > > > byte"
rm> > > > values or suffer the same consequence as forgetting to update the
rm> > > > fixed
rm> > > > table. (ie. It just puts the fixed value in a different place,
rm> > > > from what
rm> > > > I see, for in-tree modules. Also, with a fixed table, they are all
rm> > > > in
rm> > > > one place, so it's easy to choose a non-colliding value?)
rm> > > The reason for my proposal was Pawel note that a porter of the
rm> > > filesystem
rm> > > should be aware of some place in kern/ where to register, besides
rm> > > writing
rm> > > the module.
rm> >
rm> > Well, he has to be aware, but we should do all we can to minimize the
rm> > number of place he needs to update, as it is easy to forget some.
rm> >
rm> > I agree with Rick that what you proposed is similar to fixed table of
rm> > file system names and I'd prefer to avoid that. If we can have
rm> > name-based hash that produces no collision for in-tree file systems
rm> > and
rm> > know current 3rd party file systems plus collision detection for the
rm> > future then it is good enough, IMHO. And this is what Rick proposed
rm> > with
rm> > his patch.
rm> >
rm> Ok, here is the list of file system names I've been checking and there
rm> haven't been any collisions (either hash function). If you know of other
rm> well known file type names, please email and I'll add them to the list
rm> and check for collisions again.
rm>
rm> "cd9660"
rm> "ufs"
rm> "procfs"
rm> "devfs"
rm> "msdosfs"
rm> "nfs"
rm> "xfs"
rm> "reiserfs"
rm> "tmpfs"
rm> "hpfs"
rm> "ntfs"
rm> "ext2fs"
rm> "udf"
rm> "zfs"
rm> "afs"
rm>
rm> and here is my current rendition of the patch. (I took Gleb's suggestion
rm> and switched to fnv_32_str(). I'll leave it that way unless there is a
rm> collision after adding any names people post to the above list.)
rm>
rm> It sounds like people have agreed that this is a reasonable solution.
rm> If hrs_at_ can confirm that testing shows it fixes the original problem
rm> (the ZFS file handles don't change when it's loaded at different times),
rm> I'll pass it along to re_at_.

 Thank you!  I will try the latest patch by Saturday.

-- Hiroki