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) +1 -- richard -- ZFS Performance and Training richard.ell...@richardelling.com +1-760-896-4422
_______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
