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.

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)

 -- richard

ZFS Performance and Training

zfs-discuss mailing list

Reply via email to