Date: Wed, 31 Oct 2018 10:02:05 +0200 From: Andriy Gapon <avg@FreeBSD.org> To: Rick Macklem <rmacklem@uoguelph.ca>, 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: <e7813a64-59c2-67a1-3471-b32a6ca42ef8@FreeBSD.org> In-Reply-To: <YTOPR0101MB11621427AF47133A93311E16DDCD0@YTOPR0101MB1162.CANPRD01.PROD.OUTLOOK.COM> References: <YTOPR0101MB11620BAF0E206EE36E927A5ADDF30@YTOPR0101MB1162.CANPRD01.PROD.OUTLOOK.COM> <20181030012240.GM5335@kib.kiev.ua> <YTOPR0101MB11621427AF47133A93311E16DDCD0@YTOPR0101MB1162.CANPRD01.PROD.OUTLOOK.COM>
next in thread | previous in thread | raw e-mail | index | archive | help
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. 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]. But maybe this is a too radical idea? -- Andriy Gapon
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?e7813a64-59c2-67a1-3471-b32a6ca42ef8>