> 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@xxxxxxxxxx > http://lists.nongnu.org/mailman/listinfo/gluster-devel >
