Date: Sun, 4 Nov 2018 00:58:26 -0700 From: Julian Elischer <julian@freebsd.org> To: Rick Macklem <rmacklem@uoguelph.ca>, Andriy Gapon <avg@FreeBSD.org>, Konstantin Belousov <kostikbel@gmail.com> Cc: FreeBSD Filesystems <freebsd-fs@freebsd.org> Subject: Re: How to fill in the fsid for file systems? Message-ID: <c98b999c-c4b8-55fe-adef-ac53e439487b@freebsd.org> In-Reply-To: <YTOPR0101MB11621C0D5F4F4D9BED169110DDCF0@YTOPR0101MB1162.CANPRD01.PROD.OUTLOOK.COM> 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> <YTOPR0101MB11621C0D5F4F4D9BED169110DDCF0@YTOPR0101MB1162.CANPRD01.PROD.OUTLOOK.COM>
next in thread | previous in thread | raw e-mail | index | archive | help
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@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-fs
> To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org"
>
>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?c98b999c-c4b8-55fe-adef-ac53e439487b>