[Gluster-devel] Client side afr versus server side, doing a self-heal
Christopher Hawkins
chawkins at veracitynetworks.com
Thu May 1 18:01:23 UTC 2008
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!).
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
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.
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?
Chris
> So in my case where i have one directory with existing data
> and another that is empty, should i set the trusted version
> to 1 on the pre existing data and 3 on the empty directory?
> Or am I totally missing what this does?
>
> I agree starting with a clean slate is much easier/cleaner.
> But when you have 100 gigs of data consisting of tons of tiny
> files (web or mail data) it would be ideal to me anyway to be
> able to use the existing directory and somehow tell glusterfs
> that this is good data and that the empty directory is out of date.
>
> I guess this is more just a case of needing some
> documentation on the proper steps and order of executing this
> conversion?
>
More information about the Gluster-devel
mailing list