On Apr 25, 2012, at 3:36 PM, Nico Williams wrote:
> On Wed, Apr 25, 2012 at 5:22 PM, Richard Elling
> <richard.ell...@gmail.com> wrote:
>> Unified namespace doesn't relieve you of 240 cross-mounts (or equivalents).
>> FWIW,
>> automounters were invented 20+ years ago to handle this in a nearly seamless
>> manner.
>> Today, we have DFS from Microsoft and NFS referrals that almost eliminate
>> the need
>> for automounter-like solutions.
>
> I disagree vehemently. automount is a disaster because you need to
> synchronize changes with all those clients. That's not realistic.

Advertising

Really? I did it with NIS automount maps and 600+ clients back in 1991.
Other than the obvious problems with open files, has it gotten worse since then?
> I've built a large automount-based namespace, replete with a
> distributed configuration system for setting the environment variables
> available to the automounter. I can tell you this: the automounter
> does not scale, and it certainly does not avoid the need for outages
> when storage migrates.
Storage migration is much more difficult with NFSv2, NFSv3, NetWare, etc.
> With server-side, referral-based namespace construction that problem
> goes away, and the whole thing can be transparent w.r.t. migrations.
Agree, but we didn't have NFSv4 back in 1991 :-) Today, of course, this
is how one would design it if you had to design a new DFS today.
>
> For my money the key features a DFS must have are:
>
> - server-driven namespace construction
> - data migration without having to restart clients,
> reconfigure them, or do anything at all to them
> - aggressive caching
>
> - striping of file data for HPC and media environments
>
> - semantics that ultimately allow multiple processes
> on disparate clients to cooperate (i.e., byte range
> locking), but I don't think full POSIX semantics are
> needed
Almost any of the popular nosql databases offer this and more.
The movement away from POSIX-ish DFS and storing data in
traditional "files" is inevitable. Even ZFS is a object store at its core.
> (that said, I think O_EXCL is necessary, and it'd be
> very nice to have O_APPEND, though the latter is
> particularly difficult to implement and painful when
> there's contention if you stripe file data across
> multiple servers)
+1
-- richard
--
ZFS Performance and Training
richard.ell...@richardelling.com
+1-760-896-4422