On 10/12/2010 06:22 AM, Marcus Bointon wrote: > On 28 Sep 2010, at 09:11, Marcus Bointon wrote: > > >> When I say they're out of sync I mean that there are files on one but not the other (both ways around, so both additions and deletions have not happened at some point) - I'm using cluster/replicate. I'm using gluster purely for redundancy (images on a web server farm), not space or performance, and only have a very small volume of data. I could quite reasonably delete everything from the trailing node and copy back from the one that's ok. >> >> The main thing I'm not clear on is what (if any) data gluster stores apart from what's in the backing store, i.e. is it safe to stop servers, copy content around then restart them and expect them to be ok? Is there some secret data stash that will get confused if I do that? >> > Just a little bump on this. Can I move stuff around while gluster isn't running and have it be OK when it starts back up? Or will I miss some other metadata store/cache? Can I force gluster to resync with the backing store? > > No, this is guaranteed to cause problems. Gluster stores information in the file's extended attributes (hence the requirement for filesystems that support extended attributes). If you don't have a lot of data, you might consider copying it off to non-Gluster storage, re-create your Gluster volume, and then copy the data back to the new Gluster volume. > On a related topic, I'm also thinking about moving one of the nodes between servers since I need to take load off one of them - can I copy the backing store on to the new server and redeploy the new client configs and expect it to work? > > Marcus >
