How to fill in the fsid for file systems?

[Julian Elischer]

On 1/11/18 7:24 pm, Rick Macklem wrote:
> 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)?
SO lets' just make the usage model clear:
I believe that what Josh needs is to have a  two High availability 
servers viewing a single
(cloud based) filesystem, export the same FSID so that when one takes 
over for the other
the clients don't notice. The second usage is that over a reboot
an NFS client may not notice (if there were no transactions while the 
system was down).
Even if for some reason the file systems came up in a different order..

>
> rick
>
> _______________________________________________
> freebsd-fs at freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-fs
> To unsubscribe, send any mail to "freebsd-fs-unsubscribe at freebsd.org"
>
>