On Jul 14, 2009, at 6:39 PM, Robert Thurlow wrote: > Joerg Schilling wrote: > >>>> Do you see a benefit from replacing technology that is known >>>> since more than 20 years by something that does not yet have even >>>> test users? > >> Which benefits? > > Caveat - this is about a follow-on case. > > I'm glad you asked. The current automounter hasn't had a decent > amount of work on it for years now, and it has a lot of issues, > strictly as a piece of code in a Solaris system. Maps are read > on system reboot or at the request of an admin on each client, > so new filesystems or changes to locations are not picked up well. > Further, unmounts are often necessary to react to changes; this > causes the most pain in /net paths. If there's a problem with > your network at boot time, you can run without maps or with > partial maps until someone notices and manually intervenes. > I'm the primary contact on automounter maintenance at Sun these > days, and as much as I rely on it, I'm aware of it's warts. > > As a concept, there are more issues. Autofs requires that an > admin edit a flat file of path-to-location relationships and > store them one of several network services, and the propagation > is widely variable. Automounter maps are not standardized, so > multi-platform support is still dodgy. And among implentations > compatible with Sun's map format, there are variations in what > features work that often mean you have to dumb down to the > lowest common denominator. And despite the admin's work, all > clients can doctor their maps so that they see different paths > to files than their cube-mate does. > > NFS referrals are baked into two standards (RFC3530 and the > not-yet-numbered NFSv4.1 spec), and are a way to redirect the > client to another place based in information at the server. > FedFS is a standard-in-development in the IETF's NFSv4 working > group, and ties well with NFSv4.0 and v4.1. It builds a > server-side infrastructure to let servers return a coherent > set of referrals to clients. It permits an admin to specify > a detailed set of locations, with enough metadata to permit > a V4.1 client to understand all the ways it can talk to a > multi-homed server, how old the different copies of data are, > and whether or not filehandles and state might be preserved > after a live migration has happened. Each referral can be > managed in LDAP as a distinct thing, rather than as part of > a map, but are set-and-forget unless you need to change them. > Changes to the namespace should be visible far more quickly. > There's also a way to have a zero-admin client find the top > of a namespace - it will ask for a DNS RR to get started. > FedFS is also trying to be expandable enough to provide SMB > referrals to those other clients. > > Bottom line: we think admins will be able to create uniform > namespaces for all of their clients across their whole company, > something that has always eluded us with the automounter.
FWIW, and as another point-of-usefullness regarding referrals, is to also look at AFS. While AFS doesn't embody anything resembling referrals, the end result is something similar - AFS volumes (read: NFS exports) living on multiple AFS volume servers (read: multiple NFS servers) mounted to form a tree. Where the volume lives is transparent to the user. A user whose cwd is /afs/@cell/stuff/foo is in AFS volume stuff.foo on server pluto. Volume stuff.foo.bar could live on server mars, and be "mounted" (in AFS-speak) at /afs/@cell/stuff/foo/morestuff, and when the user accesses files in there, they're getting that stuff from mars. Federated in a way.... but the end result is the same. That user's machine is accessing a AFS cell and beyond the credentials needed to access bits within that cell, there is no need for the user to maintain a map of which AFS volume on whatever server is to be mounted where. The AFS voldb takes care of that, along with the AFS client. When I need to add a new volume, stuff.foo.baz, I merely create it on a AFS volume server, grant it sundry things such as any quota and ACLs, and mount it where I need it in the AFS tree. Done. No having to fiddle with maps. So to Joerg's issue with this being something new... the concept is far from new. This is just a very new implementation of the concept (and one that is sorely overdue, imho) /dale
