How to fill in the fsid for file systems?

[Rick Macklem]

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 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.
>
>I originally thought about having a separate filesystem list for NFS that would
>contain only exported filesystems.  But I suspect that managing it could be
>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 was
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 of 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 handle 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 storage
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 change the
file system's structure.
- UFS keeps the fsid in the superblock, so moving the file system should retain
  the same fsid value. (There might be an obscure case of another file system
  having the same fsid, so it has to change. However, since newfs(8) uses the
  creation time and a random# to create it, a conflict seems highly unlikely.)
- 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_fsid_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/…)

Maybe someone can explain when it would be useful for FFS (or not)?

rick