Re: fsid change of ZFS?

From: Hiroki Sato <hrs_at_FreeBSD.org>
Date: Mon, 22 Aug 2011 10:11:30 +0900 (JST)
Hi Rick,

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

rm> Hiroki, could you please test the attached patch.
rm>
rm> One problem with this patch is that I don't know how to create a fixed
rm> table that matches what systems would already have been getting.
rm> (I got the first 6 entries by booting a GENERIC i386 kernel with a
rm>  printf in vfs_init(), so I suspect those don't change much, although
rm>  I'm not sure if ZFS will usually end up before or after them?)
rm>
rm> Do you guys know what ZFS gets assigned typically? (I realize that
rm> changes w.r.t. when it gets loaded, so the question also becomes
rm> "do you know how it typically gets loaded" so the table can have
rm> that vfc_typenum value assigned to it?)
rm> Maybe you could boot a system with a printf like:
rm>
rm> printf("%s, %d\n", vfc->vfc_name, vfc->vfc_typenum);
rm>
rm> just after vfc->vfc_typenum = maxvfsconf++; in vfs_init() and
rm> then look in dmesg after booting, to see what your tables look like?
rm> (Without the attached patch installed.)
rm>
rm> Thanks, rick
rm> ps: The patch is also at
rm>      http://people.freebsd.org/~rmacklem/fsid.patch for anyone on
rm>     the list interested (if the attachment doesn't make it through.
rm>
rm>
rm> rick

 Yes, we can think the typical number of zfs is 7 on GENERIC.

 However, I checked vfc_typenum in three boxes around me by using the
 attached patch for lsvfs(1), but the results were not consistent:

 Machine A (8-STABLE)
 |
 |Filesystem                       Num  Refs Flags
 |-------------------------------- --- ----- ---------------
 |msdosfs                            1     0
 |procfs                             2     0 synthetic
 |devfs                              3     4 synthetic
 |cd9660                             4     0 read-only
 |nfs                                5     2 network
 |ufs                                6     6

 Machine B (HEAD with newnfs complied)
 |
 |Filesystem                       Num  Refs Flags
 |-------------------------------- --- ----- ---------------
 |msdosfs                            1     0
 |ufs                                2     5
 |nfs                                3     0 network
 |cd9660                             4     0 read-only
 |procfs                             5     0 synthetic
 |devfs                              6     1 synthetic
 |zfs                                7     1 jail, delegated-administration
 |

 Machine C (HEAD with oldnfs compiled)
 |
 |Filesystem                       Num  Refs Flags
 |-------------------------------- --- ----- ---------------
 |ufs                                1     3
 |msdosfs                            3     0
 |procfs                             4     0 synthetic
 |devfs                              5     1 synthetic
 |oldnfs                             6     0 network
 |cd9660                             7     0 read-only
 |zfs                                8     4 jail, delegated-administration
 |nfs                                9     1 network

 I guess the ordering is timing-dependent and consistent only in the
 same box.

 The result of the Machine C was changed like the following after
 applying the patch.  It worked as expected:

 |Filesystem                       Num  Refs Flags
 |-------------------------------- --- ----- ---------------
 |ufs                                2     3
 |oldnfs                            15     0 network
 |zfs                                7     4 jail, delegated-administration
 |devfs                              4     1 synthetic
 |msdosfs                            5     0
 |nfs                                6     0 network
 |cd9660                             1     0 read-only
 |procfs                             3     0 synthetic

 Hmm, based on these results it looks difficult to assign the same
 number to each file system.  Anyway, not fixing them is worse, so we
 may have to accept this as a small upgrade bump in 9.0R.

-- Hiroki

Received on Sun Aug 21 2011 - 23:12:48 UTC

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