I have a file system that contains several hundred thousand very small files which are served to several clients (so, stat'd and read frequently). I need to replicate any changes to those files on to four systems which need read-only access, and three for read-write. The read-only systems don't need real-time access, but should be updated as quickly as possible. I've tried using the fuse mount on the read-only systems, which gives predictably atrocious performance over a high - latency link. The NFS client is a little better, but I'd prefer some fall over capability. I was originally thinking about using an inotify-based rsync job, but then I thought that Gluster might be able to do this for me easier. What if I set the ro systems to be geo-replicated peers, and just used their local brick directly as my "read-only" volume? Assuming my application is smart enough to not write to the brick & doesn't care about any metadata, and my volume is a straight replica with no striping, is there any real problem with this that I'm overlooking? That would get rid of the slow network stat(), and just have a minimal delay in replication while remaining fault-tolerant, right? --Danny _______________________________________________ Gluster-users mailing list Gluster-users@xxxxxxxxxxx http://supercolony.gluster.org/mailman/listinfo/gluster-users
