How to fill in the fsid for file systems?

Rick Macklem rmacklem at uoguelph.ca
Wed Oct 31 02:23:32 UTC 2018


Konstantin Belousov wrote:
>On Mon, Oct 29, 2018 at 03:56:02PM +0000, Rick Macklem wrote:
>> Hi,
>>
>> I have been working with Josh Paetzel on a patch to add support for
>> the "fsid=N" option (like what Linux has) to /etc/exports. (It is used
>> to ensure that the fsid for a file system doesn't change when migrated
>> to a different machine, so that file handles don't change.)
>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.




More information about the freebsd-fs mailing list