dynfsal

Table of Contents Using the "Dynamic FSAL" feature for using more than one FSAL in a single NFS-Ganesha instance? Compiling a FSAL to be used as a shaed object Compiling NFS-GANESHA with no FSAL Using FSAL per export entry in a dynamic way

Using the "Dynamic FSAL" feature for using more than one FSAL in a single NFS-Ganesha instance?

The "dynamic FSAL" feature allows you to compile NFS-Ganesha with no internal FSAL. The FSAL will be loaded at runtime, using the dlopen API. This makes it possible to load several FSALs in a single NFS-Ganesha daemon. The type of FSAL to be used for a given export entry will then become a characteristic of the export entry.

Compiling a FSAL to be used as a shaed object

Compiling NFS-Ganesha with no FSAL is very easy. You just have to specify "DYNFSAL" as the FSAL to be use. This is a fake name in the configure.ac that indicates that no FSAL is to be compiled and linked. To configure and compile, proceed this way

# ./configure --with-fsal=DYNFSAL
# make
# make install

You'll get a dynfsal.ganesha.nfsd that you'll be using later.

Compiling NFS-GANESHA with no FSAL

Compiling NFS-Ganesha with FSAL set to be shared object is done like this (in this example, XFS is used, but other FSALs may work as well)

# ./configure --with-fsal=XFS --enable-buildsharedfsal 
# make 
# make install

You'll find the shared objects under src/FSAL/FSAL_<name></name>/.libs . Note that a nfsd will ne generated in the src/MainNFSD directory, and it will be dynamically linked with the FSAL shared object. If you are generating rpm files, you will get an additionnal rpm package with the FSAL object in it. File will have a name matching nfs-ganesha-fsal-*.rpm .

Using FSAL per export entry in a dynamic way

Once you both have the dynfsal.ganesha.nfsd and the FSAL shared object, you just need to configure NFS-Ganesha properly. First thing to do is setting the paths to load the FSALs. Path are by the FSAL_Shared_Library parameter in block NFS_Core_param. The value is formatted this way : "FSAL name:FSAL Path". FSAL name is one of the following string: GPFS, HPSS, LUSTRE, POSIX, PROXY, SNMP, VFS, XFS, ZFS, CEPH.

For example, if you want to use FSAL_PROXY, FSAL_XFS, FSAL_VFS and FSAL_ZFS, you'll be using something like this:

  FSAL_Shared_Library = "PROXY:/usr/lib/libfsalproxy.so.1.1.0" &#59;
  FSAL_Shared_Library = "ZFS:/usr/lib/libfsalzfs.so.1.1.0" &#59;
  FSAL_Shared_Library = "XFS:/usr/lib/libfsalxfs.so.1.1.0" &#59;
  FSAL_Shared_Library = "VFS:/usr/lib/libfsalvfs.so.1.1.0" &#59;

 ( ... )
}

The next step is to indicate, for each export entry, the FSAL to be used. This is done in the 'Export' block by setting parameter 'FSALID' which expects its value to be a valid FSAL name. This parameter is mandatory when using dynamic FSALs.

Example with xfs:

  # Export Id (mandatory)
  Export_Id = 77 &#59;

  # Exported path (mandatory)
  Path = "/xfs" &#59;

  Root_Access = "localhost" &#59;

  Access = "*"&#59;

  # Pseudo path for NFSv4 export (mandatory)
  Pseudo = "/xfs"&#59;


  Access_Type = RW&#59;


  # This sets the filesystem id for the entries of this export.
  Filesystem_id = 192.168 &#59;


  # Export entry file system dependant options.
  # NOTHING for POSIX FS
  FS_Specific = "/xfs" &#59;

  # Export entry "tag" name
  # Can be used as an alternative way of addressing the
  # export entry at mount time ( alternate to the 'Path')
  Tag = "xfs" &#59;

  FSALID = "XFS" &#59;
}