[fedfs-utils] On-disk junction format re-design

[Chuck Lever]

For fedfs-utils-0.8, I'd like to support what Solaris calls "NFS basic" junctions.  This simply means that the junction contains the actual fileset location information, rather than a pointer to an LDAP server with the information.  Eventually NFS basic junctions would supplant the use of "refer=" in /etc/exports.

This requires two new pieces of work:

  1.  A plug-in interface that allows support for each junction type to be delegated to a DLL that programs can load at run time

  2.  A command line tool that uses these plug-ins to perform simple administrative tasks with junctions

Mountd support is also needed, but that is a small piece of work once we complete 1. and 2.

Our plug-in for NFS basic junctions needs some way of storing fs_locations4, and eventually fs_locations_info4, on disk.  This means we have to store groups of booleans, integers, and UTF-8 string arrays in an NFS basic junction.

We already have some basic general requirements for junctions:

  • A text format rather than a binary blob, so junctions can be read or even edited by humans using a text editor

  • A format that is independent of endianness, so a junction can be moved between two storage systems of different endianness without a change in its meaning

  • A format that allows the content of several different junction types to be stored in an object, so different network file system services can insert their own specific referral content into the same object

  • A format that is extensible, so that new features and data items can be added to junction content without breaking existing behavior

  • A format that is fast to read from disk, so that it's quick for the kernel to distinguish junctions from non-junctions

So far, FedFS junctions need only store a limited amount of text.  We can simply store that text in a group of xattrs.

But NFS fs_locations4 and fs_locations_info4 contain string arrays and integers.  At first I thought we could store NFS fs_locations4 info in an XDR byte stream.  That's almost binary, though.  It is certainly not able to be edited by a text editor.

Then it occurred to me that we could store junction content using XML.  XML is expressly for the storage and transport of structured data, which is precisely what we need to do here.

XML can be read and edited by humans with text editors, and because it is a UTF-8 string, it is immune to endianness issues.  Each junction type would use a single specifically-named xattr that contains XML describing the junction, one xattr per junction type.  Then we would no longer need a trusted.junction.type xattr, and multiple junction types could be stored in a single file system object.

And we keep the special mode bits scheme that allows the kernel to discover the presence of junction content quickly.

What would the content of a junction xattr look like?  Here's a sample FedFS junction expressed in XML:

 --- Cut here ---

<?xml version="1.0" encoding="UTF-8"?>

<!-- Created by /usr/sbin/rpc.fedfsd -->

<junction>

  <fedfs>
    <fsnuuid>9ef44f24-ff2b-11e0-8aec-000c2979d1f3</fsnuuid>
    <nsdbname>nsdb.fedfs.org</nsdbname>
    <nsdbport>389</nsdbport>
  </fedfs>

</junction>

 --- Cut here ---

An NFS junction looks similar, but would contain fs_locations4 (or fs_locations_info4) data instead:

 --- Cut here ---

<?xml version="1.0" encoding="UTF-8"?>

<!-- Created by /usr/sbin/nfsref -->

<junction>

  <nfs4>
    <fs_location4>
      <server>fileserver1.fedfs.org</server>
      <server>fileserver2.fedfs.org</server>
      <server>fileserver3.fedfs.org</server>
      <rootpath>
        <component4>tank</component4>
        <component4>share</component4>
        <component4>people</component4>
        <component4>cel</component4>
      </rootpath>
    </fs_location4>

    <fs_location4>
      <server>netapp.example.net</server>
      <rootpath>
        <component4>vol</component4>
        <component4>users</component4>
        <component4>cel</component4>
      </rootpath>
    </fs_location4>
  </nfs4>

</junction>

 --- Cut here ---

Is this a crazy idea?

-- 
Chuck Lever
chuck[dot]lever[at]oracle[dot]com