[Gluster-devel] Client side afr versus server side, doing a self-heal
Christopher Hawkins
chawkins at veracitynetworks.com
Thu May 1 20:24:51 UTC 2008
> 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
>
More information about the Gluster-devel
mailing list