CODA filesystem
plug-discuss@lists.PLUG.phoenix.az.us
plug-discuss@lists.PLUG.phoenix.az.us
Wed, 18 Apr 2001 15:51:41 -0700
mutt directly supports maildirs. qmail directly
supports maildirs. sendmail using procmail as its
delivery agent supports maildirs. maildirs do not
require ANY locking whatsoever and are thus safe to
use with NFS.
djb is good, mmmmK? maildirs are good, mmmmK?
D
* On Wed, Apr 18, 2001 at 02:38:57PM -0700, Shawn T. Rutledge wrote:
> So I see the same old disclaimers are still on the web site about it
> not being stable enough for prime time, but it sure has been a long time...
> I remember JLF saying he was using it a while back. Anybody else?
>
> I have had too many problems which sometimes resulted in /home being
> offline. Right now it's on the primary Linux partition on my main
> workstation (the one where I went through all the install hassles last
> weekend) which is convenient for speed but very bad for reliability.
> I export it via NFS to my other systems. Usually I run mutt on top of
> screen on my gateway machine to read email from either work or home;
> and mutt cannot write to folders in my home directory because of NFS
> locking problems. The mutt developers seem to be really strict about
> doing what is correct rather than what works or is convenient... so this
> bug waits for a fix to NFS, which has been broken so long I don't expect
> much (seem to remember there being fundamental discord over how to do
> locking, and whether it even should work for NFS the same as it works for
> local disk). And, the web server depends on /home too; if it's not
> mounted, most of my web pages aren't available. So all of this makes
> me want to try Coda, for the following reasons -
>
> 1.) network filesystem without NFS's limitations, if I'm lucky
> 2.) I could use 2 or 3 servers, replicate and have enough redundancy
> to alleviate my fears about not doing backups often enough (and
> these days, a tarball of /home doesn't fit on one CDR anymore
> like it used to)
> 3.) the local cache should make it faster; and/or maybe it will be
> faster for other reasons too - NFS is not known for speed
> 4.) maybe I could use ReiserFS, and avoid the NFS bugs which occur when
> using ReiserFS and NFS together
>
> The ideal distributed filesystem would be a peer-to-peer aggregating one
> which also insures "n" levels of redundancy (configurable); it would
> aggregate free disk space on all the machines on the network. But such
> a thing doesn't exist in a way which can actually be mounted and used as
> a regular filesystem, AFAIK.... so in the mean time there's Coda.
>
> My best candidate for a file server at this point is probably Tachyon,
> which has a 17 gig drive that is only getting used for MP3's and backups
> so far. I could put the MP3's in my home directory and use the entire
> disk just for /home. But I think Coda requires servers to have the same
> size disks if you're doing replication and failover, right? Because all
> the files have to exist on both drives? AFAIK it doesn't do aggregation.
> So maybe I should get a pair of nice new 40 gig drives instead - they
> sure are cheap enough. I would put one in Tachyon, the dual Celeron
> box, and another in a slower box (I have an extra P75 laying around, and
> an extra rack case with nothing in it; this box could also have about
> 6 CDROMs mounted in it, which is something else I've been wanting to do.)
> So my question is then, which server should be the SCM, the faster less
> reliable one (which could conceivably be used to do more stuff besides
> being an NFS server, and is likely to get its kernel upgraded from time
> to time) or the slow one that I get working once, get it stable and then
> not expect it to do anything else? Will Coda automatically figure out
> that one box is faster and try to get files from that one most of the time?
> Or will it prefer to get files from the SCM if possible and only if it's
> not available, fail-over to the replicant? Will the speed even matter
> or will it be quite fast because of the client-side cache?
>
> If speed doesn't matter a lot, I could even put a tertiary even-more-
> reliable machine (a 486 maybe) in a different room as yet another
> failover machine. It would have its own little UPS, ext2 filesystem
> (just in case Reiser develops problems) and absolutely no other tasks
> besides acting as a backup.
>
> Why is there a limit of 300 megs for client-side cache? (This wasn't
> explained on the web site, they just said not to do it.)
>
> Given that Coda puts all the files in one giant directory, is ReiserFS
> vastly superior, because as I understand it's much more efficient than
> EXT2 for large directories? Are Coda and ReiserFS known to get along?
> Which version of Reiser should I run, the latest, or the latest even-
> numbered one?
>
> Do file conflicts arise often enough in practice to be a pest?
>
> --
> _______ Shawn T. Rutledge / KB7PWD ecloud@bigfoot.com
> (_ | |_) http://www.bigfoot.com/~ecloud kb7pwd@kb7pwd.ampr.org
> __) | | \________________________________________________________________
> ________________________________________________
> See http://PLUG.phoenix.az.us/navigator-mail.shtml if your mail doesn't post to the list quickly and you use Netscape to write mail.
>
> PLUG-discuss mailing list - PLUG-discuss@lists.PLUG.phoenix.az.us
> http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-discuss
>