Date: Sat, 20 Aug 2011 20:15:34 -0400 (EDT) From: Rick Macklem <rmacklem@uoguelph.ca> To: Hiroki Sato <hrs@FreeBSD.org> Cc: pjd@FreeBSD.org, current@FreeBSD.org Subject: Re: fsid change of ZFS? Message-ID: <59520805.118597.1313885734529.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <20110820.142859.319295417241413417.hrs@allbsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
------=_Part_118596_867455584.1313885734527
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Hiroki Sato wrote:
> Rick Macklem <rmacklem@uoguelph.ca> wrote
> in <1565511281.69213.1313764157732.JavaMail.root@erie.cs.uoguelph.ca>:
>
> rm> Hiroki Sato wrote:
> rm> > fsid_guid = dmu_objset_fsid_guid(zfsvfs->z_os);
> rm> > ASSERT((fsid_guid & ~((1ULL<<56)-1)) == 0);
> rm> > vfsp->vfs_fsid.val[0] = fsid_guid;
> rm> > vfsp->vfs_fsid.val[1] = ((fsid_guid>>32) << 8) |
> rm> > vfsp->mnt_vfc->vfc_typenum & 0xFF;
> rm> >
> rm> > Since the vfc_typenum variable is incremented every time a new
> vfs is
> rm> > installed, loading order of modules that call vfs_register()
> affects
> rm> > ZFS's fsid.
> rm> >
> rm> > Anyway, possibility of fsid change is troublesome especially for
> an
> rm> > NFS server with a lot of clients running. Can zeroing or setting
> a
> rm> > fixed value to the lowest 8-bit of vfs_fsid.val[1] be harmful?
> rm> >
> rm> > -- Hiroki
> rm> Well, the problem is that the fsid needs to be unique among all
> mounts.
> rm> The vfs_typenum field is used to try and ensure that it does not
> end up
> rm> the same value as a non-ZFS file system.
> rm>
> rm> (A) I think making that field a fixed constant should be ok, if
> the function
> rm> checks for a conflict by calling vfs_getvfs() to check for one.
> rm> See vfs_getnewfsid() for how this is done. (There is a mutex lock
> that
> rm> needs to be held while doing it.) Alternately, if ZFS can call
> vfs_getnewfsid()
> rm> instead of doing its own, that might be nicer?
> rm>
> rm> (B) Another way to fix this would be to modify vfs_register() to
> look up
> rm> file systems in a table (by vfc_name) and used a fixed, assigned
> value
> rm> from the table for vfc_typenum for entries found in the table.
> Only do
> rm> the "maxvfsconf++" when there isn't an entry for the fstype in the
> table.
> rm> (VFS_GENERIC can be set to the size of the table. That's what
> happened
> rm> in the bad old days when vfsconf was a table built at kernel
> config time.)
> rm>
> rm> If you guys think (B) is preferred, I could come up with a patch.
> I don't
> rm> know enough about ZFS to do (A).
>
> rm> Oh, and I think other fs types will suffer the same fate, except
> that
> rm> they usually avoid it, because they are compiled into the kernel
> and
> rm> the assignment of vfs_typenum happens in the same order-->same
> value.
>
> 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
Hiroki, could you please test the attached patch.
One problem with this patch is that I don't know how to create a fixed
table that matches what systems would already have been getting.
(I got the first 6 entries by booting a GENERIC i386 kernel with a
printf in vfs_init(), so I suspect those don't change much, although
I'm not sure if ZFS will usually end up before or after them?)
Do you guys know what ZFS gets assigned typically? (I realize that
changes w.r.t. when it gets loaded, so the question also becomes
"do you know how it typically gets loaded" so the table can have
that vfc_typenum value assigned to it?)
Maybe you could boot a system with a printf like:
printf("%s, %d\n", vfc->vfc_name, vfc->vfc_typenum);
just after vfc->vfc_typenum = maxvfsconf++; in vfs_init() and
then look in dmesg after booting, to see what your tables look like?
(Without the attached patch installed.)
Thanks, rick
ps: The patch is also at
http://people.freebsd.org/~rmacklem/fsid.patch for anyone on
the list interested (if the attachment doesn't make it through.
rick
------=_Part_118596_867455584.1313885734527
Content-Type: text/x-patch; name=fsid.patch
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename=fsid.patch
LS0tIGtlcm4vdmZzX2luaXQuYy5zYXYJMjAxMS0wNi0xMSAxODo1ODozMy4wMDAwMDAwMDAgLTA0
MDAKKysrIGtlcm4vdmZzX2luaXQuYwkyMDExLTA4LTIwIDIwOjAxOjMxLjAwMDAwMDAwMCAtMDQw
MApAQCAtNTQsOSArNTQsMzggQEAgc3RhdGljIGludAl2ZnNfdW5yZWdpc3RlcihzdHJ1Y3QgdmZz
Y29uZgogTUFMTE9DX0RFRklORShNX1ZOT0RFLCAidm5vZGVzIiwgIkR5bmFtaWNhbGx5IGFsbG9j
YXRlZCB2bm9kZXMiKTsKIAogLyoKKyAqIFRoaXMgdGFibGUgYXNzaWducyBzdGF0aWMgdmZjX3R5
cGVudW0gdmFsdWVzIGZvciBmaWxlIHN5c3RlbXMgdGhhdAorICogYXJlIHdlbGwga25vd24gdG8g
dGhlIHN5c3RlbS4gVGhpcyBhdm9pZHMgdGhlIHByb2JsZW0gb2YgYSBmaWxlIHN5c3RlbSdzCisg
KiBmc2lkIGFuZCwgdGhlcmVmb3JlLCBpdHMgTkZTIGZpbGUgaGFuZGxlLCBmcm9tIGNoYW5naW5n
IGJhc2VkIG9uCisgKiB3aGVuIHRoZSBmaWxlIHN5c3RlbSBpcyBsb2FkZWQgaW50byB0aGUga2Vy
bmVsLgorICogRmlsZSBzeXN0ZW0gdHlwZXMgbm90IGluIHRoaXMgbGlzdCB3aWxsIGJlIGFzc2ln
bmVkIHZhbHVlcyBiYXNlZAorICogb24gbWF4dmZzY29uZi4KKyAqLworc3RhdGljIHN0cnVjdCB2
ZnN0eXBlbnVtcyB7CisJY2hhcgkqdHlwZW5hbWU7CisJaW50CXR5cGVudW07Cit9IHZmc3R5cGVu
dW1zW10gPSB7CisJeyAiY2Q5NjYwIiwJMQl9LAorCXsgInVmcyIsCTIJfSwKKwl7ICJwcm9jZnMi
LAkzCX0sCisJeyAiZGV2ZnMiLAk0CX0sCisJeyAibXNkb3NmcyIsCTUJfSwKKwl7ICJuZnMiLAk2
CX0sCisJeyAiemZzIiwJNwl9LAorCXsgInJlaXNlcmZzIiwJOAl9LAorCXsgInRtcGZzIiwJOQl9
LAorCXsgImhwZnMiLAkxMAl9LAorCXsgIm50ZnMiLAkxMQl9LAorCXsgImV4dDJmcyIsCTEyCX0s
CisJeyAidWRmIiwJMTMJfSwKKwl7ICJ4ZnMiLAkxNAl9LAorCXsgIiIsCQkwCX0JLyogTXVzdCBi
ZSBsYXN0LiAqLworfTsKKworLyoKICAqIFRoZSBoaWdoZXN0IGRlZmluZWQgVkZTIG51bWJlci4K
ICAqLwotaW50IG1heHZmc2NvbmYgPSBWRlNfR0VORVJJQyArIDE7CitpbnQgbWF4dmZzY29uZiA9
IHNpemVvZih2ZnN0eXBlbnVtcykgLyBzaXplb2Yoc3RydWN0IHZmc3R5cGVudW1zKTsKIAogLyoK
ICAqIFNpbmdsZS1saW5rZWQgbGlzdCBvZiBjb25maWd1cmVkIFZGU2VzLgpAQCAtMTM4LDYgKzE2
Nyw3IEBAIHZmc19yZWdpc3RlcihzdHJ1Y3QgdmZzY29uZiAqdmZjKQogCXN0cnVjdCBzeXNjdGxf
b2lkICpvaWRwOwogCXN0cnVjdCB2ZnNvcHMgKnZmc29wczsKIAlzdGF0aWMgaW50IG9uY2U7CisJ
aW50IGk7CiAKIAlpZiAoIW9uY2UpIHsKIAkJdmF0dHJfbnVsbCgmdmFfbnVsbCk7CkBAIC0xNTIs
NyArMTgyLDE4IEBAIHZmc19yZWdpc3RlcihzdHJ1Y3QgdmZzY29uZiAqdmZjKQogCWlmICh2ZnNf
YnluYW1lKHZmYy0+dmZjX25hbWUpICE9IE5VTEwpCiAJCXJldHVybiBFRVhJU1Q7CiAKLQl2ZmMt
PnZmY190eXBlbnVtID0gbWF4dmZzY29uZisrOworCS8qIEZpcnN0LCBzZWFyY2ggZm9yIGEgbWF0
Y2ggaW4gdmZzdHlwZW51bXNbXS4gKi8KKwlmb3IgKGkgPSAwOyB2ZnN0eXBlbnVtc1tpXS50eXBl
bnVtICE9IDA7IGkrKykgeworCQlpZiAoc3RybmNtcCh2ZnN0eXBlbnVtc1tpXS50eXBlbmFtZSwg
dmZjLT52ZmNfbmFtZSwgTUZTTkFNRUxFTikKKwkJICAgID09IDApIHsKKwkJCXZmYy0+dmZjX3R5
cGVudW0gPSB2ZnN0eXBlbnVtc1tpXS50eXBlbnVtOworcHJpbnRmKCJmbmQgJXMsICVkXG4iLHZm
Yy0+dmZjX25hbWUsdmZjLT52ZmNfdHlwZW51bSk7CisJCQlicmVhazsKKwkJfQorCX0KKwlpZiAo
dmZzdHlwZW51bXNbaV0udHlwZW51bSA9PSAwKQorCQkvKiBOb3QgZm91bmQsIHNvIGFzc2lnbiBp
dCBkeW5hbWljYWxseS4gKi8KKwkJdmZjLT52ZmNfdHlwZW51bSA9IG1heHZmc2NvbmYrKzsKIAlU
QUlMUV9JTlNFUlRfVEFJTCgmdmZzY29uZiwgdmZjLCB2ZmNfbGlzdCk7CiAKIAkvKgo=
------=_Part_118596_867455584.1313885734527--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?59520805.118597.1313885734529.JavaMail.root>