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
