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. Rob T