That makes it distinctly feature-incomplete, so not really a viable alternative. :( I am aware of a few alternatives, but they are all distinctly not suitable for my use case (WAN r/w cluster). 1) DRBD + [GFS | OCFS] - unusable for high latency (WAN) environment. 2) PeerFS - Requires a full resync if a volume is extended (imagine resyncing a few TB over a WAN connection!) 3) SeznamFS - no master-master replication, all nodes but one have to be read only. 4) Tahoe allmydata - last I checked it's fuse front ends (plural - not a good sign) are experimental and incomplete. GlusterFS seems to be as good as it gets for what I'm trying to do. Gordan On Mon, 4 May 2009 19:34:14 -0400 (EDT), Brent A Nelson <brent@xxxxxxxxxxxx> wrote: > It looks young; not even permissions are supported, yet... > > On Mon, 4 May 2009, Gordan Bobic wrote: > >> On 04/05/2009 23:01, ender wrote: >>> If you have an _immediate_ need for a fuse mountable >>> clustered filesystem you might want to look at : >>> http://wiki.apache.org/hadoop/MountableHDFS HDFS does replication(+ self >>> heal) well. >> >> Interesting, not heard of that one before. Have you used it? What is your >> >> experience of it? Is there readable mmap support? How does it compare to >> GlusterFS performance-wise? How gracefully does it handle disconnections >> and >> reconnections compared to AFR? Is it _really_ more stable than GlusterFS? >> >> I guess I really ought to try it, but for my intended use case it would >> mean >> writing support for it into Open Shared Root. Not that that's a problem, >> I've >> added GlusterFS support to it before, but it might be a month or so >> before I >> get around to it... >> >> Gordan >> >> >> _______________________________________________ >> Gluster-devel mailing list >> Gluster-devel@xxxxxxxxxx >> http://lists.nongnu.org/mailman/listinfo/gluster-devel >>
