How to fill in the fsid for file systems?

[Rick Macklem]

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 Linux
>> does it" (but I can't speak for Josh).
>>
>> The kernel code currently sets this via an nmount(2) option called "export.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 processes
>> this option in vfs_domount_update(), so it would need to be moved to where
>> options are processed during mounting, but that wouldn't be hard.)
>>
>> This would actually avoid patching mountd.c. It would also avoid the fact that
>> the "export fsid option" applies to all clients and is not per-host or per-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 system
>> 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=N" 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 logical.
>
>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 fsid
>whereas today ZFS filesystems are mounted auto-magically.
>We could add a FreeBSD specific fsid ZFS property, but that's also some extra 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 filesystem.
>Obviously, to support the fsid override we have to modify the one true fsid.
>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 natural
>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 be 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), fhstatfs(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 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 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