Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 26 Aug 2011 06:30:17 +0900 (JST)
From:      Hiroki Sato <hrs@FreeBSD.org>
To:        rmacklem@uoguelph.ca
Cc:        kostikbel@gmail.com, pjd@FreeBSD.org, current@FreeBSD.org, kaduk@MIT.EDU
Subject:   Re: fsid change of ZFS?
Message-ID:  <20110826.063017.934842008473299966.hrs@allbsd.org>
In-Reply-To: <468764384.310026.1314219682612.JavaMail.root@erie.cs.uoguelph.ca>
References:  <20110824200813.GC1688@garage.freebsd.pl> <468764384.310026.1314219682612.JavaMail.root@erie.cs.uoguelph.ca>

next in thread | previous in thread | raw e-mail | index | archive | help
----Security_Multipart(Fri_Aug_26_06_30_17_2011_258)--
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Rick Macklem <rmacklem@uoguelph.ca> wrote
  in <468764384.310026.1314219682612.JavaMail.root@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@ 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@.

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

-- Hiroki

----Security_Multipart(Fri_Aug_26_06_30_17_2011_258)--
Content-Type: application/pgp-signature
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (FreeBSD)

iEYEABECAAYFAk5WvukACgkQTyzT2CeTzy1MBwCgiwegt+ORXMY7/dz0GwP9v2k0
eKkAn1nlk7i8JUvvyTK+i0mE4huKcffa
=Onxk
-----END PGP SIGNATURE-----

----Security_Multipart(Fri_Aug_26_06_30_17_2011_258)----



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20110826.063017.934842008473299966.hrs>