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

[Christopher Hawkins]

> 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.
> 

I build out a directory with the files / libraries and cpio it into an
initramfs, and use this to PXE boot clients. A script then merges parts of
the gluster mounted remote filesystem into the ramdisk root.    

> > 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.
> 

I'm using 4.x... Prior to modifying fstab, I was unable to set / get attrs.
But I'll check on another box and verify... 

> > 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.

Hm, well it is a hack! But everything starts as a hack and then gets better
over time. Realistically, I think most people have pre-existing data anyway
and many will try this on their own now that there is some information out
there about what's involved. A good script will take an unstructured process
and make it more predictable, and should provide warnings about backups and
what is and is not safe. A bad script is worse than having nothing, as you
suggest, because you can just run it without knowing what you are doing. But
I am going to write it for me, anyway, and if the dev's want to put it out
there that's their decision. 

But in the end, I think assigning attributes can be made quite safe. The
variables are important but there aren't that many of them, and a decent
script should be able to run checks that prevent you from hosing yourself by
making common mistakes. Really it's more of a tool to first stop you from
doing it wrong, and second, allow you to do it right if you understand the
risk and have a backup.  

> > 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
> 
> 
> _______________________________________________
> Gluster-devel mailing list
> Gluster-devel at nongnu.org
> http://lists.nongnu.org/mailman/listinfo/gluster-devel
>