The Export Facility

The Pnfs Mount Operation

• The requesting host/subnet ( nfs client ) is validated (or rejected )
• The requested mountpoint ( virtual mountpoint ) is mapped to an absolute pnfs directory.

• In the pnfs context the requested mountpoint is a virtual mountpoint because it first has to be mapped to a pnfs directory. This mapping is done using the hosts/net and groups files.
• Although the export configuration is stored in pnfs filesystem files, the 'pmountd' doesn't need to access those files via a mounted filesystem. In other word, it is not neccessary for the pmountd that the pnfs filesystem is mounted.

Looking up the nfs client host or subnet

Whenever an nfs mountrequest arrives, the ip number of the client host is converted to a filename representing its dotted decimal form. This file is looked up in the pnfs exports directory :

<pnfsMountpoint>/admin/etc/exports

If the file doesn't exist, the request is denied. Otherwise the file has to contain all the exportable filesystems in a syntax described later in this chapter.

With pnfs 3.1.3 not only individual hosts but also all hosts belonging to a subnet can be targets of the export facility. The subnet mask can be of arbitrary length. The filesyntax looks as follows :

<netmask>..<netpart>

Where <netmask> is the netmask and <netpart> the ip number of the subnet. Both quantities have to be specified in their dotted decimal representation. These files are scanned from the smallest to the largest subnet which means from the largest to the smallest netmask. So 255.255.255.0 is checked before 255.255.0.0. If the requested mountpoint is not found in the file with the largest fitting netmask the search is NOT continued and the request is denied.

Example

Assuming the export directory contains three files :

• 131.169.42.66
• 255.255.255.240..131.169.42.64
• 255.255.255.0..131.169.42.0

The first file is only inspected for requests from 131.169.42.66, the second file is responsible for the range 131.169.42.(65-79) except for node 31.169.42.66 and the third file describes the behaviour of the full 131.169.42.0 subnet except all nodes in the range 131.169.42.(65-79). If, for example, the file 131.169.42.66 is empty, the corresponding node is not allowed to mount anything whatever is enabled in the other files.

Virtual mountpoints and mount groups

After the relevant file in .../exports is found, it is searched for the requested mountpoint.

The syntax of the hostfiles, netfiles and groupfiles may be an arbitrary combination of one of the following :

<virtualMountpoint> <pnfsDirectory> <permission> nooptions

This form directly maps a <virtualMountpoint> to a pnfs directory. The <permission> determins the I/O behaviour and the initial pnfs level. The keyword nooption must be specified.

<virtualMountpoint> <mountGroup>[:<newVirtualMountpoint>]

This form redirects the search for <virtualMountpoint> to the mount group <mountGroup>. If <newVirtualMountpoint> is specified, the search continues for the virtual mountpoint <newVirtualMountpoint> otherwise the inital virtual mountpoint is used. The depth of indirection is limited to 8 to avoid endless loops. The mountGroup files are expected in ../exports/mountpoints. They must be named after the mount group they represent.

<virtualMountpoint> <newVirtualMountpoint>

This form is identical to the form above except that the current file is searched for <newVirtualMountpoint>.

In the latter two forms the <virtualMountpoint> can be the wildcard character '*'. The wildcard matches all requested mountpoints.

Examples

<pnfsMountpoint>/admin/etc/exports/255.255.255.0..131.169.44.0  :

     |/data           Hermes:/hermes            |   Rule 1
     |/hermes.users   Generic:/users            |   Rule 2
     |*               Generic                   |   Rule 3
     
<pnfsMountpoint>/admin/etc/exports/255.255.255.0..131.169.55.0  :

     |/data           Zeus:/data                |   Rule 4
     |/zeus.users     Generic:/users            |   Rule 5
     |*               Generic                   |   Rule 6
     
          
<pnfsMountpoint>/admin/etc/exports/mountpoints/Hermes  :
  
     |/hermes     /data                                                 |   Rule 7
     |/data       /0/root/fs/usr/hermes       30    nooptions           |   Rule 8
       
<pnfsMountpoint>/admin/etc/exports/mountpoints/Zeus  :
  
     |/zeus       /data                                                 |   Rule 9
     |/data       /0/root/fs/usr/zeus         30    nooptions           |   Rule 10
     
<pnfsMountpoint>/admin/etc/exports/mountpoints/Generic  :
  
     |/users        /0/root/fs/usr/desy/users         30    nooptions   |   Rule 11
     |/tmpPool      /0/root/fs/usr/largePool          30    nooptions   |   Rule 12
     

Result

• All hosts at subnet 44 will get /0/root/fs/hermes when mounting pnfshost:/data, while hosts from subnet 55 will get /0/root/fs/zeus when using the same mountpoint : pnfshost:/data.
  Subnet 44 uses rules : 1-7-8
  Subnet 55 uses rules : 4-10
  
• Both subnets end up with the same directory for the users if they specify pnfshost:/hermes.user for subnet 44 and pnfshost:/zeus.users for subnet 55.
  Subnet 44 uses rules : 2-11
  Subnet 55 uses rules : 5-11
  
• All other mounts are directed to the Generic group from both subnets. So the pnfshost:/tmpPool ends up at /0/root/fs/usr/largePool for both subnets.
  Subnet 44 uses rules : 2-11
  Subnet 55 uses rules : 5-11
  

The examples show that rules can be used to focus and defocus mountpoint requests. In addition the indirection with 3.1.3 makes it easier to change configurations without modifying all host or net files.