I just wanted to toss out a thought I had to get it on the table. For me, the replication features (in any filesystem that supports it) serve several purposes 1, is to have 2 or more copies of the data which are live and useable (I think lustre doesn't offer this) -- this is handy for HA, and for performance (in my case, the servers are clients, and so they read data from their local disk and only have to go down to network speed when writing). another is for disaster recovery. What I'd like to see is a DR translator.. which is basically identical to AFR with a few notable exceptions: 1) it would be a one-way pipe--when data is updated, the updates are pushed over, and it's assumed that the DR location is never written to locally, so the auto-healing can make some assumptions and not have to do a 2 way comparison and data transfer 2) delayed writes -- I'd like to specify an allowable delay for updates (if this is 0, then my writes will block waiting on the data to be replicated), if this is higher, then gluster returns control back after it's written the file to the "local brick" but then replicates in the background. 3) delayed writes 2 -- if we're allowing delayed writes, then there may be an added benefit. if the same file changes multiple times over a short period, we only have to transfer the most recent version of that data across the network. So, one could have a disaster recovery site with slower Internet connections which are in sync within a specified amount of time. Or one could even use a service like Amazon S3 as a repository without worrying about super huge data transfer fees. I could see it used to manage a file-serving/web farm. For example: I might have 7 machines which just serve images and videos. I update them by pushing a new image/video to one master server, the other 6 get updated. If someones updated a file on the DR box (i.e. the auto-heal would be triggered) instead of the file on the DR box being replicated back, it should be over-written with the version of the file on the master. This would insure data integrity and you could put your master copy of files on a very hardened secure server behind a firewall or DMZ, and if someone breaks into a box and tries to overwrite an image or something it would automatically get 'healed' from the master copy. Then, if there is a disaster, and you're running from your DR site, you simply reverse the configuration, and after the disaster let things auto-heal the other direction and then switch back once things are in sync. those are my thoughts. Keith
