On Mon, 2013-04-22 at 16:39 -0400, Chuck Lever wrote:
> 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.
Can you give an example or refernce of what is stored in this XML/JSON
blob ? Why do you need structured data there ?
> 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.
Having to install a whole LDAP server as a pre-requisite seem very heavy
handed.
> 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?
>
Why should we leave a symlink ? Don't we expect to remove junctions for
all protocols ?
>
> 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?)
Why should we leave a symlink ? Don't we expect to remove junctions for
all protocols ?
What I do not get is why are you trying to use the same mechanism (a
symlink) but then treat them as independent and separate entities ?
What is the aim ?
>From your premise I thought you wanted to allow parallel functionality,
ie a DFS created in samba would be seen as a junction for nfs and
vice-versa, but the latter points seem to not allow that ?
> The FedFS extended attribute is called "trusted.junction.nfs". Should
> we rename it?
Shouldn't it be namespaced and use something like trusted.nfs.junction ?
Also why a xattr in the trusted namespace ? What are the security
considerations that warrants a trusted attribute rather than a normal
one ? (Links to RFCs or other docs are just fine)
> Note that CAP_SYS_ADMIN capabilities are required to access the xattr.
> Will that be a problem for Samba administration tools?
>
It should not be a problem for Samba, as we can retain capabilities if
needed, and we already handle data in xattrs (not for DFS symlinks).
Simo.
--
Simo Sorce * Red Hat, Inc * New York
--
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
