I'm using the reexport=auto-fsidnum option with crossmnt (as Netapp is
involved) and using fsidd - as there could potentially be hundreds of
child volumes - which all works well, but I was just wondering if
instead of using an external service/database to map an export path to a
fsid, would it be 'better' if that mapping could be done internally by
creating a UUID hash of the export path?
Thanks
James Pearson
On 22/07/2025 12:36, Daire Byrne wrote:
We just hard code "fsid=12345" into the /etc/exports for each
mountpoint on the "re-export" server. We use config management on our
servers to maintain consistency.
We also mostly use NFSv3 re-exports but that shouldn't matter much.
Things get a bit trickier in the case of something like a Netapp that
might have multiple "volumes" appear as a single namespace (you have
to fsid each one in the tree).
Daire
On Tue, 22 Jul 2025 at 09:49, James Pearson <jcpearson@xxxxxxxxx> wrote:
I've been experimenting with re-exporting NFS shares and using the
external fsidd service via the 'reexport' option - which all seems to
work OK
As it is possible to use a UUID as a fsid for an export, would it
possible to allow an automatically generated fsid as a UUID - i.e.
instead of talking to an external service to provide a fsid, just
generate a UUID which would be a hash (of some kind) of the exported
path ? i.e. no need to use an external database to supply a consistent
fsid ?
Thanks
James Pearson
