Date: Sun, 4 Nov 2018 23:57:30 +0000 From: Rick Macklem <rmacklem@uoguelph.ca> To: Andriy Gapon <avg@FreeBSD.org>, Julian Elischer <julian@freebsd.org>, Konstantin Belousov <kostikbel@gmail.com> Cc: FreeBSD Filesystems <freebsd-fs@freebsd.org> Subject: Re: How to fill in the fsid for file systems? Message-ID: <YTOPR0101MB116276DDB031C76E1F8B0560DDC90@YTOPR0101MB1162.CANPRD01.PROD.OUTLOOK.COM> In-Reply-To: <03f24451-c0d0-0701-0e00-b2ce0f946887@FreeBSD.org> References: <YTOPR0101MB11620BAF0E206EE36E927A5ADDF30@YTOPR0101MB1162.CANPRD01.PROD.OUTLOOK.COM> <20181030012240.GM5335@kib.kiev.ua> <YTOPR0101MB11621427AF47133A93311E16DDCD0@YTOPR0101MB1162.CANPRD01.PROD.OUTLOOK.COM> <e7813a64-59c2-67a1-3471-b32a6ca42ef8@FreeBSD.org> <YTOPR0101MB116207BA89FB66EE9B1AAF01DDCD0@YTOPR0101MB1162.CANPRD01.PROD.OUTLOOK.COM> <a831d660-1ed9-ef21-f457-8e1e986b96f2@FreeBSD.org> <YTOPR0101MB11621C0D5F4F4D9BED169110DDCF0@YTOPR0101MB1162.CANPRD01.PROD.OUTLOOK.COM> <c98b999c-c4b8-55fe-adef-ac53e439487b@freebsd.org> <YTOPR0101MB1162A8CA4B3AAF230E73158DDDC90@YTOPR0101MB1162.CANPRD01.PROD.OUTLOOK.COM>, <03f24451-c0d0-0701-0e00-b2ce0f946887@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--_002_YTOPR0101MB116276DDB031C76E1F8B0560DDC90YTOPR0101MB1162_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Andriy Gapon wrote:
>On 04/11/2018 17:38, Rick Macklem wrote:
>> That leaves ZFS, which is what I was asking.
>> I don't understand the ZFS code well enough to understand what
>> dmu_objset_fsid_guid() is doing to get the fsid. I also don't know if th=
e value
>> changes for snaphots of the same file system?
>> - If it does ever change, then that is the usage case for this option.
>
>A good ZFS example is this.
>A filesystem is duplicated using zfs send + zfs recv. The content would b=
e
>exactly the same (provided no modification of the source and the target af=
ter
>the duplication), but GUIDs of the source and target would be different. =
The
>latter is required because the source and the target could be in the same =
pool.
>But even if they are in different pools (and different machines), the GUID=
s
>would still be different.
Cool. Assuming the duplicated file system created via zfs send + zfs recv s=
till
has the same fid for any given file (the stuff used by zfs_fid() stays the =
same
for any given file in the file system), then this would be good use case.
It will need some ZFS magic to make a generic fs mount option work for ZFS.
Maybe you can do that?
The current patch I have for adding a generic "fsid=3DN" mount option is in
D17839. I've also attached it to this message in case that is easier.
(It currently doesn't allow fsid=3DN to be used during an update "mount -u"=
.
This made sense to me, since an fsid shouldn't change, but if others think
it should be changeable via "mount -u" the patch can easily be changed.)
rick
ps: I did notice the code is "slightly racy" in that there is a period of t=
ime between
when VFS_MOUNT() sets the mnt_stat.f_fsid and when the mount structur=
e is=20
entered in the mountlist, where another mount could happen using the=
same
mnt_stat.f_fsid value, but that has been there for a long time and wo=
uldn't be
easy to fix.
--_002_YTOPR0101MB116276DDB031C76E1F8B0560DDC90YTOPR0101MB1162_
Content-Type: application/octet-stream; name="setfsid.patch"
Content-Description: setfsid.patch
Content-Disposition: attachment; filename="setfsid.patch"; size=2608;
creation-date="Sun, 04 Nov 2018 23:54:10 GMT";
modification-date="Sun, 04 Nov 2018 23:54:10 GMT"
Content-Transfer-Encoding: base64
LS0tIGtlcm4vdmZzX21vdW50LmMubm9mc2lkCTIwMTgtMDktMjkgMDE6MTM6MzQuNTIzMjQwMDAw
IC0wNDAwCisrKyBrZXJuL3Zmc19tb3VudC5jCTIwMTgtMTEtMDQgMjI6NDk6NDYuNjE0MDA3MDAw
IC0wNTAwCkBAIC0xMTAsNiArMTEwLDcgQEAgc3RhdGljIGNvbnN0IGNoYXIgKmdsb2JhbF9vcHRz
W10gPSB7CiAJInJ3IiwKIAkibm9zdWlkIiwKIAkibm9leGVjIiwKKwkiZnNpZCIsCiAJTlVMTAog
fTsKIApAQCAtODM4LDYgKzgzOSw5IEBAIHZmc19kb21vdW50X2ZpcnN0KAogCXN0cnVjdCBtb3Vu
dCAqbXA7CiAJc3RydWN0IHZub2RlICpuZXdkcDsKIAlpbnQgZXJyb3I7CisJdWludDY0X3QgZnNp
ZHZhbDsKKwljaGFyICpmc2lkc3RyLCAqZnNpZGVuZDsKKwlpbnQgZnNpZGxlbjsKIAogCUFTU0VS
VF9WT1BfRUxPQ0tFRCh2cCwgX19mdW5jX18pOwogCUtBU1NFUlQoKGZzZmxhZ3MgJiBNTlRfVVBE
QVRFKSA9PSAwLCAoIk1OVF9VUERBVEUgc2hvdWxkbid0IGJlIGhlcmUiKSk7CkBAIC04OTAsNiAr
ODk0LDI4IEBAIHZmc19kb21vdW50X2ZpcnN0KAogCSAqIGdldC4gIE5vIGZyZWVpbmcgb2YgY25f
cG5idWYuCiAJICovCiAJZXJyb3IgPSBWRlNfTU9VTlQobXApOworCisJLyoKKwkgKiBTZXQgdGhl
IGZzaWQgaWYgdGhlIG1vdW50IG9wdGlvbiB3YXMgc3BlY2lmaWVkLgorCSAqLworCWlmIChlcnJv
ciA9PSAwKSB7CisJCWZzaWRsZW4gPSAwOworCQllcnJvciA9IHZmc19nZXRvcHQobXAtPm1udF9v
cHRuZXcsICJmc2lkIiwgKHZvaWQgKiopJmZzaWRzdHIsCisJCSAgICAmZnNpZGxlbik7CisJCWlm
IChlcnJvciA9PSAwKSB7CisJCQlpZiAoZnNpZGxlbiA9PSAwIHx8IGZzaWRzdHJbZnNpZGxlbiAt
IDFdICE9ICdcMCcpCisJCQkJZXJyb3IgPSBFSU5WQUw7CisJCQlpZiAoZXJyb3IgPT0gMCkgewor
CQkJCWZzaWR2YWwgPSBzdHJ0b3VxKGZzaWRzdHIsICZmc2lkZW5kLCAwKTsKKwkJCQlpZiAoKmZz
aWRlbmQgIT0gJ1wwJykKKwkJCQkJZXJyb3IgPSBFSU5WQUw7CisJCQl9CisJCQlpZiAoZXJyb3Ig
PT0gMCkKKwkJCQllcnJvciA9IHZmc19zZXRmc2lkKG1wLCBmc2lkdmFsKTsKKwkJfSBlbHNlCisJ
CQllcnJvciA9IDA7CisJfQorCiAJaWYgKGVycm9yICE9IDApIHsKIAkJdmZzX3VuYnVzeShtcCk7
CiAJCW1wLT5tbnRfdm5vZGVjb3ZlcmVkID0gTlVMTDsKLS0tIGtlcm4vdmZzX3N1YnIuYy5ub2Zz
aWQJMjAxOC0wOS0yOSAwMjozOToyNy4zMTI2NzcwMDAgLTA0MDAKKysrIGtlcm4vdmZzX3N1YnIu
YwkyMDE4LTExLTAyIDIwOjM3OjQwLjAwMDAwMDAwMCAtMDQwMApAQCAtNzY5LDYgKzc2OSwzNyBA
QCB2ZnNfZ2V0bmV3ZnNpZChzdHJ1Y3QgbW91bnQgKm1wKQogfQogCiAvKgorICogU2V0IHRoZSBm
X2ZzaWQgdG8gdGhlIGFyZ3VtZW50LCBpZiBwb3NzaWJsZS4KKyAqLworaW50Cit2ZnNfc2V0ZnNp
ZChzdHJ1Y3QgbW91bnQgKm1wLCB1aW50NjRfdCB2YWwpCit7CisJc3RydWN0IG1vdW50ICpubXA7
CisJZnNpZF90IHRmc2lkOworCisJQ1RSMihLVFJfVkZTLCAiJXM6IG1wICVwIiwgX19mdW5jX18s
IG1wKTsKKwkvKgorCSAqIEZpbGwgaW4gdGhlIHR3byAzMmJpdCBmaWVsZHMgb2YgdGhlIGZzaWQg
dG8gInZhbCIuCisJICovCisJdGZzaWQudmFsWzBdID0gdmFsOworCXRmc2lkLnZhbFsxXSA9IHZh
bCA+PiAzMjsKKwltdHhfbG9jaygmbW50aWRfbXR4KTsKKwlpZiAoKG5tcCA9IHZmc19nZXR2ZnMo
JnRmc2lkKSkgIT0gTlVMTCkgeworCQl2ZnNfcmVsKG5tcCk7CisJCW10eF91bmxvY2soJm1udGlk
X210eCk7CisJCWlmIChubXAgIT0gbXApCisJCQlyZXR1cm4gKEVJTlZBTCk7CisJCXJldHVybiAo
MCk7CisJfQorCU1OVF9JTE9DSyhtcCk7CisJbXAtPm1udF9zdGF0LmZfZnNpZC52YWxbMF0gPSB0
ZnNpZC52YWxbMF07CisJbXAtPm1udF9zdGF0LmZfZnNpZC52YWxbMV0gPSB0ZnNpZC52YWxbMV07
CisJTU5UX0lVTkxPQ0sobXApOworCW10eF91bmxvY2soJm1udGlkX210eCk7CisJcmV0dXJuICgw
KTsKK30KKworLyoKICAqIEtub2IgdG8gY29udHJvbCB0aGUgcHJlY2lzaW9uIG9mIGZpbGUgdGlt
ZXN0YW1wczoKICAqCiAgKiAgIDAgPSBzZWNvbmRzIG9ubHk7IG5hbm9zZWNvbmRzIHplcm9lZC4K
LS0tIHN5cy9tb3VudC5oLm5vZnNpZAkyMDE4LTA5LTI5IDAxOjEzOjA0LjY1OTQxNzAwMCAtMDQw
MAorKysgc3lzL21vdW50LmgJMjAxOC0xMS0wMyAwMTowNjozNy44NTQ5NDgwMDAgLTA0MDAKQEAg
LTkxOCw2ICs5MTgsNyBAQCB2b2lkCXZmc19kZWFsbG9jYXRlX3N5bmN2bm9kZShzdHJ1Y3QgbW91
bnQgKik7CiBpbnQJdmZzX2Rvbm1vdW50KHN0cnVjdCB0aHJlYWQgKnRkLCB1aW50NjRfdCBmc2Zs
YWdzLAogCSAgICBzdHJ1Y3QgdWlvICpmc29wdGlvbnMpOwogdm9pZAl2ZnNfZ2V0bmV3ZnNpZChz
dHJ1Y3QgbW91bnQgKik7CitpbnQJdmZzX3NldGZzaWQoc3RydWN0IG1vdW50ICosIHVpbnQ2NF90
KTsKIHN0cnVjdCBjZGV2ICp2ZnNfZ2V0cm9vdGZzaWQoc3RydWN0IG1vdW50ICopOwogc3RydWN0
CW1vdW50ICp2ZnNfZ2V0dmZzKGZzaWRfdCAqKTsgICAgICAvKiByZXR1cm4gdmZzIGdpdmVuIGZz
aWQgKi8KIHN0cnVjdAltb3VudCAqdmZzX2J1c3lmcyhmc2lkX3QgKik7Cg==
--_002_YTOPR0101MB116276DDB031C76E1F8B0560DDC90YTOPR0101MB1162_--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?YTOPR0101MB116276DDB031C76E1F8B0560DDC90>