FedFsNfsServer0.9

From Linux NFS

Revision as of 20:48, 17 October 2012 by Chucklever (Talk | contribs)
Jump to: navigation, search

Contents

Project: fedfs-utils

[ Project Home | News | Downloads | Docs | Mailing Lists | Source Control | Issues ]


Introduction

This article describes how to configure a Linux NFS server to resolve junctions. Once a file server can resolve junctions in its local file systems, it can participate in a FedFS domain.

A junction is a link between two shared file systems. The two shared file systems may not reside on the same server. There may be more than one replica of the linked-to shared file system, stored on several different file servers. Each replica of the linked-to file system is called a location.

Junctions store a list of locations. Each location in the list is represented as an export path paired with a server name or IP address. When a file-access client encounters a junction, the file server (via a referral) provides the stored list of locations to the client, who chooses a location and mounts it.

A file server must convert the information stored in a junction into a list of locations that's in a format which is correct for the protocol clients are using to access the server (say, NFSv4). The server-side process of recognizing a junction and converting its contents is known as junction resolution.

A single junction is useful for linking together two shared file systems. A web of junctions can be used to create a namespace that crosses between multiple file systems on multiple file servers. FedFS uses junctions for just such a purpose.

On Linux, a junction is denoted by a directory with special mode bits and an extended attribute that contains the junction location list. The NFS server must convert a junction's location information into an NFSv4 referral which can be sent to NFS clients.

When the Linux in-kernel NFS server encounters a junction, it resolves the junction by performing an upcall to mountd. It is mountd that actually reads a junction and converts it to information that the kernel NFS server can put on the wire as an NFSv4 referral.

Pre-packaged install

If you are running Fedora 19, you can install a pre-packaged version of fedfs-utils-0.9. The server-side components are installed with:

# yum install fedfs-utils-server

This installs a pre-built nfsref command and libnfsjunct.a. The rpc.mountd daemon provided in this distribution is already prepared for junction resolution, and does not need to be replaced after the fedfs-utils-server package is installed.

Build from scratch

If your distribution does not provide a pre-packaged version of fedfs-utils-0.9, follow these steps instead.

Build fedfs-utils

Unpack the fedfs-utils-0.9 tarball somewhere convenient. For example:

$ cd fedfs-utils-0.9
$ ./configure
$ make

Note: If you're building for a 64-bit target such as x86_64, you need to specify the directory in which to install libraries. Add "--libdir=/usr/lib64" to the ./configure command line.

There are three pieces that need to be installed first. The plug-in library:

# cd fedfs-utils-0.9/src/plug-ins ; make install

The header describing the library's API:

# cd fedfs-utils-0.9/src/include ; make install

And finally, the "nfsref" command:

# cd fedfs-utils-0.9/src/nfsref ; make install

If you're feeling brave, a single "make install" in the top level directory should take care of all of this, and install lovely man pages to boot.

Build nfs-utils

Now download and unpack the latest nfs-utils tarball on the same system where you built fedfs-utils. Build nfs-utils, and replace rpc.mountd on your NFS server. The configure options are complicated; I usually copy them from the latest Fedora nfs-utils RPM spec file.

$ ./configure yada yada
$ make
$ sudo install utils/mountd/mountd /usr/sbin/rpc.mountd

Then restart the NFS service.

# systemctl restart nfs-server.service
Personal tools