Date: Fri, 2 Nov 2018 02:24:18 +0000 From: Rick Macklem <rmacklem@uoguelph.ca> To: Andriy Gapon <avg@FreeBSD.org>, Konstantin Belousov <kostikbel@gmail.com> Cc: FreeBSD Filesystems <freebsd-fs@freebsd.org>, Josh Paetzel <josh@tcbug.org> Subject: Re: How to fill in the fsid for file systems? Message-ID: <YTOPR0101MB11621C0D5F4F4D9BED169110DDCF0@YTOPR0101MB1162.CANPRD01.PROD.OUTLOOK.COM> In-Reply-To: <a831d660-1ed9-ef21-f457-8e1e986b96f2@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>
next in thread | previous in thread | raw e-mail | index | archive | help
Andriy Gapon wrote
>On 31/10/2018 17:50, Rick Macklem wrote:
>> I alluded to this option in my last post. I think both fsids will need t=
o be in the
>> mount structure, since finding the correct mount point via the fsid is t=
he first
>> step in translating a file handle to a vnode. (After that VFS_FHTOVP() d=
oes the rest.)
>>
>> And I think it will get messy. A couple of examples.
>> There are some syscalls that use file handles. fhopen(2), fhstat(2), fhs=
tatfs(2),
>> getfh(2), lgetfh(2)
>> I had assumed that the "file handles" used by these should be the same f=
ile
>> handles that NFS uses (ie. file handles are a generic VFS component and =
not NFS
>> specific) but I can see the argument either way. I actually don't know w=
hat
>> apps/utilities use fhopen/fhstat/fhstatfs, but getfh(2) is used by mount=
d.
>> Since mountd uses getfh(2) to get a file handle for NFS mounts, it needs=
to
>> return the NFS fsid to keep the old binaries working, even if you add a
>> new getnfsfh(2) function for mountd to use.
>> - Now you have some file handle system calls using file handles with the=
NFS
>> fsid in them and some using file handles with the "true" fsid in them.
>> (Sounds confusing to me.)
>>
>> Since the first step in turning a file handle into a vnode is looking up=
the fsid
>> in the mount list, if you had two fsids, I think they both would end up =
in the
>> mount structure so that lookup could be done easily.
>> This lookup is normally done by vfs_busyfs() { that appears to be the on=
ly use
>> of vfs_busyfs() in sys/kern. I haven't looked in the various file system=
s }.
>> With two fsids, you need two functions and need to be careful which one =
you use.
>
>I originally thought about having a separate filesystem list for NFS that =
would
>contain only exported filesystems. But I suspect that managing it could b=
e
>problematic.
>
>An alternative idea is to use osd(9) framework to attach NFS specific data=
to
>struct mount without modifying the structure and without exposing the NFS =
data
>to other consumers.
I have two comments. The first is related to the above and the second is a =
big
picture question related to doing this.
Specifically w.r.t. the above. I probably rambled and didn't make what I wa=
s
trying to say clear, so I'll try again...
- getfh(2) returns a file handle that is used for NFS, but is also used for=
system
calls (fhopen(2), fhstat(2) and fhstatfs(2)) that are not related to NFS.
--> A file handle isn't really NFS specific, although NFS is the big user=
of it.
If the above is correct, then it seems that there should only be one kind o=
f file handle.
--> Since the fsid is a key part of a file handle, one kind of file handle =
implies one
kind of fsid.
I just think trying to create two kinds of fsid and two kinds of file handl=
e would
make the code confusing and unnecessarily complex.
On the big picture..the more I look at this, the less obvious the usage of =
setting
an fsid other than what the file system sets seems to become. I thought the=
usage
of this was to ensure that when a file system was moved (just moving the st=
orage
hardware or a block by block cloning) to a different system, the same fsid =
would
be used so that file handles wouldn't change. Note that a file handle also =
has
a fileid number (think I-node#) in it, so the file system "move" can't chan=
ge the
file system's structure.
- UFS keeps the fsid in the superblock, so moving the file system should re=
tain
the same fsid value. (There might be an obscure case of another file syst=
em
having the same fsid, so it has to change. However, since newfs(8) uses t=
he
creation time and a random# to create it, a conflict seems highly unlikel=
y.)
- This leaves ZFS. I know nothing about ZFS, but a glance at the code seems
to indicate it normally comes out of the "physical dataset" field ds_fsi=
d_guid.
--> Does this mean it changes when "moved" or stays the same, like UFS?
If the answer is "stays the same", I don't see that being able to manually =
set
the fsid is useful?
(There are file systems like cd9660 and msdosfs where the fsid will change,
but I don't see those used a storage for NFS servers where they might be
moved/cloned/=85)
Maybe someone can explain when it would be useful for FFS (or not)?
rick
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?YTOPR0101MB11621C0D5F4F4D9BED169110DDCF0>