[NFS-Ganesha-Devel] Re: Ganesha 2.5.4 - usage of device major, minor

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: