Date: Wed, 31 Oct 2018 15:50:32 +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: <YTOPR0101MB116207BA89FB66EE9B1AAF01DDCD0@YTOPR0101MB1162.CANPRD01.PROD.OUTLOOK.COM> In-Reply-To: <e7813a64-59c2-67a1-3471-b32a6ca42ef8@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>
next in thread | previous in thread | raw e-mail | index | archive | help
Andriy Gapon wrote:
>On 31/10/2018 04:23, Rick Macklem wrote:
>> Konstantin Belousov wrote:
>>> Why do you consider this an option for exports file and not for nmount(=
2)
>>> and fstab ? Do you intend to mangle fsid for mount protocol only ?
>> Well, Josh Paetzel proposed this. I believe it was because "that's how L=
inux
>> does it" (but I can't speak for Josh).
>>
>> The kernel code currently sets this via an nmount(2) option called "expo=
rt.fsid".
>> Although Josh's patch has this done in mountd.c, it could simply be used=
as
>> a mount option in /etc/fstab or manual mounting. (The code currently pro=
cesses
>> this option in vfs_domount_update(), so it would need to be moved to whe=
re
>> options are processed during mounting, but that wouldn't be hard.)
>>
>> This would actually avoid patching mountd.c. It would also avoid the fac=
t that
>> the "export fsid option" applies to all clients and is not per-host or p=
er-net.
>> (Doing it only for "exports" requires a moderate amount of code change, =
such
>> as a new function to be used instead of vfs_busyfs() to busy the file sy=
stem
>> after looking up the fsid in the export stuff. I haven't coded this, so =
I'm not
>> sure how much work that would be?)
>>
>> I actually think making it a generic nmount(2) option and not an export =
specific
>> one sounds like a good idea.
>>
>> What do others think of making "fsid=3DN" a generic mount option for
>> overriding the selection of fsid done by the file system?
>>
>> rick
>> ps: Although I don't try to be "Linux incompatible", I don't see why we =
should
>> be compatible when doing it a slightly different way seems more lo=
gical.
>
>I see two issues here.
>
>One is practical. How do we provide fsid to ZFS filesystems?
>I mean I would hate to resort to mounting ZFS via fstab just to provide fs=
id
>whereas today ZFS filesystems are mounted auto-magically.
>We could add a FreeBSD specific fsid ZFS property, but that's also some ex=
tra code.
Good point. I'm not a ZFS guy, so I wouldn't have thought of this.
>The other issue is a potential design issue.
>Right now there is the "one true" fsid that's embedded into struct mount
>(mnt_stat.f_fsid) and NFS uses it to match a handle to a specific filesyst=
em.
>Obviously, to support the fsid override we have to modify the one true fsi=
d.
>My thinking is why can't NFS have its own fsid (equal to the one true fsid=
by
>default) that it would use internally to match the handle to an exported
>filesystem...
>In that case we would not need to alter the one true fsid (in struct mount=
), we
>would just set the NFS export fsid. In that case, I think, it would be na=
tural
>that the fsid override is provided as an export option.
>This, of course, would require a new implementation for nfsvno_getfh() to =
use
>the NFS fsid instead of vp->v_mount->mnt_stat.f_fsid. Also, nfsd_fhtovp()=
would
>not be able to use vfs_busyfs(), instead it would do an internal look-up. =
Same
>for nfsvno_getvp().
>[I think that nfsrvd_compound() would keep using the one true fsid].
If NFS starts to use a different fsid, it would need to change everywhere.
>But maybe this is a too radical idea?
I alluded to this option in my last post. I think both fsids will need to b=
e in the
mount structure, since finding the correct mount point via the fsid is the =
first
step in translating a file handle to a vnode. (After that VFS_FHTOVP() does=
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), fhstat=
fs(2),
getfh(2), lgetfh(2)
I had assumed that the "file handles" used by these should be the same file
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 what
apps/utilities use fhopen/fhstat/fhstatfs, but getfh(2) is used by mountd.
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 NF=
S
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 th=
e 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 only =
use
of vfs_busyfs() in sys/kern. I haven't looked in the various file systems }=
.
With two fsids, you need two functions and need to be careful which one you=
use.
rick
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?YTOPR0101MB116207BA89FB66EE9B1AAF01DDCD0>