The Export ID and FSID are used to uniquely identify handles to Ganesha. In NFS, the client gets an opaque handle to things (files, directories, block-devices, etc.) and use these opaque handles to reference those objects on the server. Ganesha breaks this up into 2 parts: The global part specifies a version, an export ID, and a length; and the per-FSAL part is opaque, and controlled by the FSAL that owns the export. VFS stores the FSID of the filesystem owning the object, and then the actual kernel handle (as passed to the *_at (open_by_handle_at(2) for example). The reason for the FSID is that Linux handles are only guaranteed to be unique within a single filesystem. If an export is removed, and another one is added, but it has the same system major/minor (which is the primary FSID on Linux), the handles that the client previously had open on the old export will try to be used on the new export, since, as far as Ganesha knows, they're valid for that export. In general, an export ID/FSID combo should never be re-used for the lifetime of a Ganesha server instance. This isn't a problem for filesystems based on block devices, since the FSID is based on the block device, and so will be unique, but can be a problem for FUSE, which generates it's FSID. One way around this would be to create the new FUSE FS before you take down the old one. That way it will get a new FSID. Or you can just script configuration in Ganesha with unique FSIDs. Ganesha has the ability to load config snippits (such as exports) from files with the %include directive. You can try using that with generated exports. Daniel On 10/09/2018 05:55 PM, Krishna Harathi wrote:
We are using Ganesha 2.5.4 VFS FSAL with FUSE based filesystem.
During our testing of deleting existing exports and creating new ones, found that if a device major and minor is reused, clients get ESTALE for accessing a newly created export (nfs2 below).
This seems to cause the following log entry, and explains the ESTALE response.
04/10/2018 T15:16:59.769027-0700 : nfs-ganesha-26627[sigmgr] 1595 :claim_posix_filesystems :FSAL :INFO :Root fs for export /exports/nfs1 is /exports/nfs2
We use our own Exportid and unique FSID configured for each export in the configuration file.
I would like to know more about the intent and purpose of the usage of device major and minor of an export in this context.
Any help in fixing this reuse issue is also appreciated.
Thanks.
Regards.
Krishna Harathi
_______________________________________________ Devel mailing list -- devel@lists.nfs-ganesha.org To unsubscribe send an email to devel-leave@lists.nfs-ganesha.org