Another GlusterFS 3.1 question on my blog (http://cloudarchitect.posterous.com). Any help/ideas will be appreciated. Thanks Joshua ---- Here's my challenge: I have several 1 tb ebs volumes now that are un-replicated and reaching capacity. I'm trying to suss out the most efficient way to get each one of these into its own replicated 4 tb gluster fs. My hope was that I could snapshot each one, restore it twice from the snapshot, and launch this pair as a pre-replicated gluster FS where the 'heal' process (find . | xargs stat) allows the gluster daemon to rationalize the situation, and then add a second pair of empty bricks - to grow on. As you know, all this can be done in just a few minutes. Well, I have now tried this, and I'm afraid I've got a goopy mess... so much for -that- shortcut. Rather than try to debug the situation, I'm curious if there is a better high speed import strategy? A dd for gluster? Any thoughts? If all else fails, I'm happy to create the naked file system and just do an rsync, but last time I did this (when I was testing out LVM) the rsync took 3 days. In general, I'm thinking about this exercise not just as a migration, but also as a test of emergency restore, and a 3 day emergency restore is an awful long time. And one more time, thanks for this informative series. I'm curious where you go for your info (other than senior engineers at gluster!)... This topic - gluster on EBS - seems remarkably sparsely covered for all its massive applicability to cloud infrastructure... is there a gluster on ebs group somewhere? Its not as though either technology is brand new.... Regards, Gart
