[Gluster-devel] Client side afr versus server side, doing a self-heal

[Gordan Bobic]

Christopher Hawkins wrote:
> I think a little documentation there would be fantastic. I am also starting
> with a full set of files that cannot be easily copied (a shared root... It
> kind of has to be there already, by definition!). 

Just out of interest, what are you using to bootstrap your shared root? 
I'm working on a patch for Open Shared Root for GlusterFS.

> Personally I was in the dark about all this until recent threads started
> shedding a little light on how versioning worked, and didn't even have my
> filesystem mounted with extended attributes enabled. Centos by default does
> not use them if you don't enable SE Linux and I had to go into fstab and
> change my root filesystem like so:
> 
> /dev/VolGroup00/LogVol00 /                       ext3    defaults
> 
> To:
> 
> /dev/VolGroup00/LogVol00 /                       ext3    defaults,user_xattr

That's not what I'm seeing. I have SELinux disabled, and I get xattrs on 
ext3 without explicitly enabling them on CentOS 5.x.

> And then remount it. I'm thinking about writing some scripts that will check
> for files that have gluster attributes and files that don't, and that will
> take some options for how to make everything right. Let's keep this thread
> going until we all understand the best way(s) to handle pre-existing data
> and then I'll post up whatever automation I can cobble together. 

IMHO, bootstrapping with a pre-existing directory is a hack. It may 
work, but it is still a hack, and I think encouraging people to do it 
with important data just because they can't be bothered to wait for a 
copy is ill advised. People who like hacks are also generally not the 
sort that keep extensive up to date backups.

> Any other gotchas with pre-existing data? Gordan, you said you thought it
> was too dangerous and opted against it. What kind of safeguards do you think
> would make this safer?

I think not using this approach at all is the way forward. Mount the 
GlusterFS volume and copy the data to it. That way there's no scope for 
really unfortunate events.

Gordan