-
Notifications
You must be signed in to change notification settings - Fork 502
ReleaseNotes_2.1
These are the release notes for Version 2.1 of the NFS-Ganesha file server. NFS-Ganesha is a user mode NFS and Plan 9 Remote File Service server that provides many features not available in the kernel based NFS servers.
This version is the result of an 6 month effort by an active developer community. There is a lot of new code, a whole lot of improved code, and lots of new features and capabilities.
Current users of Version 2.0 and earlier servers should plan an upgrade to V2.1. See Support below for details.
A lot of new features and capabilities have been added in this very active development period. The following is a brief overview of these changes:
- Exports can now be dynamically added or removed. This is the major feature of this release. Prior versions of the server needed to restart to change exports.
- Exports now properly handles submounted filesystems. This applies to both submounts in export definitions and submounts in the backend filesystem.
- The Ganesha Pseudo FS is now more flexible, supported by a special FSAL (FSAL_PSEUDO).
- Ganesha infrastructure is able to properly support export of multiple FSALs.
- Several FSALs (FSAL_VFS, FSAL_XFS, FSAL_GPFS, FSAL_LUSTRE) now properly support export of multiple filesystems, including sub-mounted filesystems (/fs0 and /fs0/some/path/fs1).
- Nested exports (where /export1 and /export1/some/path/export2 are both exported) are properly supported for NFS v4. The two exports may be exported with different FSALs (with some caveats).
- Some NFSv4.2 support is in place. The protocol minor version is recognized and some of the new operations are supported. More will be coming in the future.
- Plan 9 (9P) support is improved. This is the 9P.2000L level protocol.
- System administration via the DBus server interface has been extended to manage the addition and removal of exports. The statistics interfaces have also been extended to count basic operations and record V4.2 I/O counts.
- RPM packaging has been improved. Note that this is different from the packaging for Fedora and Red Hat Enterprise Linux (RHEL).
- The configuration parsing/processing subsystem has been rewritten to improve stability, parameter validation, and error reporting diagnostics.
- We now use the Coverity service for open source projects. This has improved our code quality tremendously.
The software is available in source form from our Github site. Source tarballs are also available on the Github site.
The source includes ntirpc which is a new TIRPC library based on the original Sun implementation but extended significantly to support bi-directional RPC and thread safe operation. It is automatically pulled as a submodule when NFS Ganesha is cloned. If you use tarballs, make sure you also get the correct ntirpc tarball.
We use signed, annotated tags to mark our official releases. Our release tarballs are only made available using these signed tags.
- NOTE
- The fingerprint of the GPG key used to sign this release is bd0530f5.
There are Debian package control files in the source but these are out of date. We are looking for volunteers to pick up Debian and other Debian based distribution support.
The primary platform for NFS-Ganesha is Linux. Any kernel later than 2.6.39 is required to fully support the VFS FSAL. This requirement does not apply to configurations using other FSALs. We have not recently tested with kernels older than 3.8 but that should not be a problem for users with currently supported Linux distributions.
There are build time options and source code in the codebase that would indicate FreeBSD support. However, the server takes advantage of some advanced capabilities of the threads model in Linux kernels that are not available on FreeBSD. FreeBSD support will probably be dropped as of V2.2 because there is no current active development of equivalents for FreeBSD.
The primary development and use platform for NFS-Ganesha is the x86_64. This is mainly because these 64 bit platforms are the norm for enterprise deployments. It has also been built and tested on the ARMv8 (64 bit ARM) and 64 bit PPC. The server should work on 32 bit platforms although we have not tested it in a while. The server uses a lot of memory for its caches so a 32 bit address space would limit scalability.
NFS Ganesha supports NFSv3, NLM4, and MNTv1 and v3. Minimal MNTv1 support is present to handle some clients that still unmount NVSv3 exports using MNTv1. The server requires a running portmapper/STATD for NFSv3 at this time.
NFSv4.0, v4.1 and V4.2 are supported. pNFS is also supported where the FSAL is the backend for a distributed filesystem that can support pNFS. The server can act as both Metadata Server (MDS) and Data Server (DS) these distributed filesystems. Multiple (clustered) MDSs are not currently supported but they are on the roadmap for a future release. There can be as many DS instances as makes sense for the filesystem cluster. Generating and managing layouts is the responsibility of the FSAL and its underlying filesystem. The server core treats layouts as opaque data and so will mediate any layout type the FSAL chooses. Both files and object layouts have been tested.
The server supports the 9P.2000L protocol. This is a light(er) weight remote filesystem protocol that originated with AT&T Bell Labs Plan 9, their "next generation" UNIX. The primary client for this service is the 9P client in Linux.
The FSAL API, introduced in V2.0, has been extended and improved in V2.1. The API version has been incremented to show this. Any V2.0 FSALs that are not part of the release will require some changes and a re-build in order to run.
The Ganesha Ceph FSAL provides a Ganesha re-export mapping to one or more CephFS clusters (1 per export). Internally, the driver uses the libcephfs library interface to Ceph.
The Ceph FSAL has prototype pNFS support using the RFC5661 files layout. Due to limitations (striping patterns) in the files layout, pNFS is not a supported capability in Ganesha 2.1.
The Ceph FSAL builds with current releases of the filesystem.
The FSAL_GLUSTER layer enables integration of nfs-ganesha with the GlusterFS filesystem. If FSAL GLUSTER is enabled in the nfs-ganesha conf file, you can use and export GlusterFS volumes through nfs-ganesha. This means both NFSv3 and NFSv4 clients can now consume GlusterFS volumes.
nfs-ganesha can be deployed on one of the GlusterFS nodes or outside. There is no special license requirement other than using GlusterFS based on community license (www.gluster.org).
nfs-ganesha and GlusterFS integration uses the FSAL_GLUSTER to enable Gluster volume exports and use. The FSAL_GLUSTER layer communicates with GlusterFS filesystem via a library called libgfapi (available as part of the GlusterFS community distributions). Users are requested to install GlusterFS first to ensure libgfapi is available before starting nfs-ganesha. Developers need a couple of additional header files : glfs.h and glfs-handles.h (available and installed as part of deploying GlusterFS).
A sample nfs-ganesha config file for use with GlusterFS has been provided in the dir: $TOP/src/FSAL/FSAL_GLUSTER in the README file. It should mostly work as is with modifications to the hostname, IP, name of the volume to be exported, the GLUSTER export block and the Pseudo path for v4 export. Additional details for compilation and troubleshooting are also provided in the Wiki at: NFS Ganesha and GLUSTER Integration
This version of the GPFS FSAL supports all of the client side protocols including NFSv4.1 and v4.2 with pnfs. Ganesha/GPFS is not officially supported as a product by IBM and is for experimental use only. The FSAL is built by default and no additional libraries are required. However, GPFS V3.5 or later is required on the server at runtime.
The HPSS FSAL is used for accessing an IBM HPSS tape archive system. The files in the source are empty due to licensing issues. Users who may be interested in this FSAL should contact the authors at CEA in Paris, France.
This FSAL supports access to a LUSTRE filesystem. It does not currently support pNFS access but full support is in process for a future release. Users interested in using NFS Ganesha with LUSTRE should contact the authors at CEA in Paris, France.
The PROXY FSAL attaches to its backend as an NFSv4.0 client. This FSAL would act as a frontend to another NFSv4 only server. For example, 9P or NFSv3 clients could access NFSv4 servers via the proxy. Each PROXY export is configured with the destination server address and remote export to mount. The PROXY FSAL can also be used to access other NFSv4 servers through firewalls.
- NOTE:
- There are some issues with this FSAL that were discovered late in the development cycle. This FSAL has not had active users or a maintainer for a while. These issues will be addressed in a later, maintenance release.
The PT FSAL is designed for use with IBM's Protectier backup appliance. PT FSAL is not backed by a real filesystem and filesystem interface is offered by PT vtfd server through ccl library. This FSAL is not currently built by default.
The VFS FSAL can use any Posix filesystem available to the operating system. The only requirement is that the filesystem be able to generate and use "file handles". A generic set of file handle manipulation system calls were added to Linux in version 2.6.38 so any Linux system newer than that kernel can support any filesystem type.
The VFS FSAL also supports pNFS layouts with the EXOFS filesystem on Linux and the PanFS (Panasas proprietary) filesystem on Linux and FreeBSD. It is enabled by an option in the export definition.
This FSAL was an option controlled part of the VFS FSAL in V2.0. It was refactored into its own shared object module for this release. The XFS filesystem in Linux has supported a file handle interface for some time. This FSAL can be used as a workaround for older Linux kernels with XFS filesystems. Note that this FSAL is not required to support XFS on newer kernels and does not support non-XFS filesystems on older kernels.
The ZFS filesystem is supported via the libzfswrap library from the FUSE/Linux project. The library is included in the "contrib" directory of the source. Consult the FUSE/Linux website for details. ZFS "pools" can be managed either as storage partitions or as flat files within another filesystem. Note that this is not actively supported although it does build.
NFS Ganesha runs as any other server on a UNIX/Linux system. Start/stop scripting for typical Linux systems are provided in the RPM packages. These scripts are for both the traditional sysvinit model and the newer systemd environments.
The server accepts a small set of command line arguments but the detailed settings are derived from a configuration file that is supplied to the server at startup. The configuration file is read at server initialization time unless it is directed to re-read the file(s) via DBus commands. This re-reading of the configuration file is limited to adding or removing exports. This will be extended in the future.
The configuration file parsing and processing component has been rewritten. The primary motivation for this work was better maintainability and the creation of data structures to be more friendly to future work to expose those parameters to DBus control. Most of the changes are internal but there are a number of new capabilities that would be visible to the user or system administrator.
- All parameter processing uses common functions. This unifies the handling of parameter types, validation, and error reporting.
- Every parameter has defined range limits and defaults and validation based on those ranges. These are documented in the sample configurations and the project wiki.
- The use of defaults is now consistent. If the default is satisfactory, it does not need to be specified in the configuration file. This makes it possible to have a simple, small, and useable configuration file. A valid configuration with just a single EXPORT block in it is now possible.
- The file parser has been extended to record the file name and line number of each parameter. This greatly improves error reporting to the log.
- The loading of FSAL modules is greatly simplified and automatic. FSAL names are now hard coded and the module is automatically loaded from a known location in the system libraries.
- Configuration files in this release take advantage of sub-blocks to a greater extent than previous releases. This makes configuration files easier to understand and maintain.
The DBus is the primary server administration interface. Every DBus interface in the server has a companion script for accessing and controlling it in the scripts directory of the source. There are both command line and GUI (PythonQt) scripts provided. These can either be used as-is or as a reference implementation for those who wish to integrate or implement their own DBus administration tools. The DBus interface is by no means complete. The following new interfaces are provided in this release. Consult the wiki for more documentation.
- New log components have been added. The scripts handle these changes by consulting the DBus introspection interface.
- Exports are added or removed via the DBus interface. The command for adding a new export takes a parameter that describes the export(s) to be added and a path in the filesystem to be used. This path argument is typically the same configuration file used at startup although any parsable file with an EXPORT block in it can be used. The command for removing an export takes a single integer argument, the export ID, to identify the export to be removed. This will be expanded in the future. See the wiki for further details.
- The administrative command to shutdown the server is more reliable now that export removal is fully supported.
- Statistics have been extended to count and report a larger set of operations. The I/O statistics have also been refined to report NFSv4.2 operations separately.
- The DBus management scripts can be built and installed by the build process. They also packaged by the RPM packaging.
Version 2.1 of NFS Ganesha is a significant enhancement to the software. Our very active development community includes commercial companies who are using NFS Ganesha as an embedded component of their product. The only available commercial support is by these companies for their product with an embedded version of the server. As an Open Source project we have limited resources to provide significant support to older releases of the software. Therefore, users of older versions of NFS Ganesha are urged to upgrade to V2.1.
- NOTE
- There is no special, extended features or "enterprise" version of NFS Ganesha. The core server and FSAL code is common and available. The only code in a commercial product that might not fully shared would be extra administration tools, packaging, and possibly the underlying backend filesystem and, in some instances, its the backend filesystem support library. And, of course, support services.
Red Hat has provided Bugzilla instance for the project. This is available at Red Hat Bugzilla. You can find us by the Browse link followed by selecting the nfs-ganesha project/package under the Community category. This bug database is publicly readable but you will need to have a bugzilla account in order to file a bug. Please use the mailing list for questions and reserve the Bugzilla for bug reports.
The NFS Ganesha Developers on Sourceforge is our primary email list. This includes oaur archives. This is a moderated list but that is necessary to keep spam under control. Anyone interested in the project or who has a question is welcome.
We can be found on Freenode, channel #ganesha. There is usually someone online who can help with your issues although email is a better alternative.
These issues have been identified at the time of Version 2.1 release.
- This issue is only present if there is another file service, such as Samba, or a local user on the server. If the other service or local user creates a file or directory in a directory that is also active in NFS Ganesha, the NFS Ganesha server is unaware of that change because its metadata cache entries for those shared directories can be out of date. File I/O is not affected but NFS Ganesha clients may not see the new entries it until the old cache entries expire. This issue requires an extension to a Linux system call to notify NFS Ganesha of these filesystem changes. This work is in process.
- Exports can added and removed via DBus commands. Modification in place however is not present yet.
- The PROXY FSAL has some issues that are being addressed. It is not a critical component for the V2.1 release so it will ship with these issues deferred to a maintenance update.