Hi-
I led a discussion on Friday at the Linux Storage and Filesystem Summit on how to store {DFS, FedFS} junctions in Linux filesystems. I'd like to summarize the discussion, then ask a few follow-up questions. I apologize in advance for the length.
FedFS is to NFS as Microsoft DFS is to SMB/CIFS. FedFS uses NFS referrals to glue together a file namespace out of separate shares, starting with a root share that may contain nothing but referrals. For more on FedFS, start with RFC 5716.
The physical object that stores referral location target information is called a junction. It can contain an actual list of locations, or it can contain the DN of an LDAP record where the location list is maintained.
+ Samba uses a symlink for this purpose. The contents of the link represent the location information passed out to CIFS clients.
+ FedFS uses an extended attribute on a directory for this purpose. The xattr contains XML which encodes location information passed out to NFS clients.
The reasons for this difference are simply historical.
Linux is often used as a multi-protocol file service platform, where the same physical data is presented to clients via both NFS and CIFS. For this reason, we think there would be value in using the same physical representation for both NFSD and Samba so that a single junction object on our exported filesystems can trigger a referral for both NFS and CIFS.
Samba has been around much longer, and DFS support is actually deployed. FedFS is newer and still experimental. Thus we decided to change FedFS to use a symlink instead of a directory. Samba will still use the regular contents of the symlink, and FedFS will store its metadata in an extended attribute attached to the symlink.
There was a rough consensus to prefer JSON over XML in the FedFS xattr, though there are still some who dislike both. I'm open to suggestion, since we're now essentially replacing the existing FedFS junction format and can change it to anything we like.
Today FedFS junctions can contain either a location list or an LDAP DN. One option for FedFS is to support only the LDAP DN junction type, and have a (possibly local) LDAP service available to store the location information. The FedFS junction xattr would then always contain an LDAP URL. Storing complex data types (a list containing pathnames, hostnames, integers, and other values) would then be up to LDAP.
We will have to discuss a conjunction of administrative interfaces at some later point. However, we should clarify how our junction management tools behave now that each junction can have metadata it did not have before.
FedFS:
nfsref add - if no symlink exists, create it (what contents should it have?)
- add an extended attribute
nfsref remove - remove the extended attribute, leave the symlink
- can we remove the symlink if its contents are meaningless?
Samba:
add - if a symlink already exists, replace its contents, preserving xattrs
remove - if a FedFS extended attribute exists, leave the symlink (what contents should it have?)
The FedFS extended attribute is called "trusted.junction.nfs". Should we rename it?
Note that CAP_SYS_ADMIN capabilities are required to access the xattr. Will that be a problem for Samba administration tools?
--
Chuck Lever
chuck[dot]lever[at]oracle[dot]com
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
