----- "Simon Matter" <simon.matter@xxxxxxxxx> wrote: > > Believe it or not, it works and has been confirmed by several peoples on > the list using different shared filesystems (VeritasFS and Tru64 comes to > mind). In one thing you are right, it doesn't work with BerkeleyDB. > Just switch all your BDB's to skiplist and it works. This has really been > discussed on the list again and again and isn't it nice to know that > clustering cyrus that way works? Yes, useful. But the original poster wanted to combine Cyrus application replication with a cluster filesystem (GFS specifically). It seems pretty unusual to combine both. GFS has a lot of locking overhead of writing, and e-mail storage is pretty write intensive. And Cyrus replication can have its own performance issues (slow replication that never catches up). Why do both at the same time? And GFS 6.1 (current version) has some issues with large directories: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=214239 I guess this might not be an issue if the GFS cluster only has two nodes (less nodes to lock against when creating files). Cyrus is usually IO bound anyways, so you'd probably wouldn't get any additional performance for having more than two nodes. Tom ---- Cyrus Home Page: http://cyrusimap.web.cmu.edu/ Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
