Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
On Fri, Jun 20, 2008 at 09:12:33AM +0100, Lee Christie wrote: > > + you can move each resource's primary independently between the two > > servers. This gives you the possibility of "live-live" > > operation, i.e. some > > volumes served from one side, and some from the other, and to > > migrate them. > > This is true but since writes are only confirmed when written to the > remote node by drbd, there is no performance advantage surely Indeed. As I said, the benefits would be application specific. Some people prefer "live-live" rather than "live-standby" simply because it gives a higher level of confidence that the standby really *will* work when disaster strikes. > we're using this storage for maildir boxes so lots of small files. Since > pobox.com knows something about email ;) I'd appreciate a heads up. I'm afraid I'm only a customer of pobox for my personal E-mail address, so my paying them $20 per year doesn't qualify me to say much about how their service is implemented :-) My current employer was using reiserfs for a large-ish mixed data volume, a few TB, which included a number of things including backup images of other systems. It became seriously toasted. At the time we had a mixture of different OSes and filesystems. Since then we've standardised on RHEL and ext3 on VMware, with EMC SAN on the back. I've been playing with drbd recently for possible use in less critical environments (e.g. development) However at a previous employer, a large ISP, I built a Maildir solution using a pair of NetApp filers (F8xx at the time, since migrated to F9xx I believe). It worked very well for hundreds of thousands of active mailboxes, and still does. The vast majority of users are POP3 rather than IMAP though. I can strongly recommend it if your budget stretches that far. Both the filesystem (WAFL) and the NFS server implementation are superb, and the boxes are trivial to manage and grow. The snapshot and snap-mirroring features work really well, and I've also seen the cluster failover work too (i.e. one head-end successfully takes over the disks and IP address of the other head-end) Regards, Brian.