[Gluster-devel] Re: Uh, another gotcha with AFR, pre-existing data specific

Krishna Srinivas krishna at zresearch.com
Tue May 6 15:27:45 UTC 2008


Brandon,

Having version 1 is same as not having version xattr.
So in your case it should not have sync'ed.

Can you do head -c on one file and send me the log.
Make sure you have "option debug on" in afr volume
definition and also run with "-L DEBUG".

Thanks
Krishna

On Tue, May 6, 2008 at 6:36 AM, Brandon Lamb <brandonlamb at gmail.com> wrote:
> On Mon, May 5, 2008 at 5:58 PM, Brandon Lamb <brandonlamb at gmail.com> wrote:
>  > I just did some testing, and came to the conclusion that trying to
>  > setup afr using one server with pre-existing data and a blank server,
>  > and copying your data and removing xattr's on the copied data then
>  > initiating afr DOES NO GOOD.
>  >
>  > server1 - 400 megs of data in 10 tarballs, removed all xattr
>  > server2 - copied the files from server1
>  > server1 - started glusterfsd, then ran setfattr
>  > trusted.glusterfs.version to 1, files on server2 have no xattr.
>  >
>  > At this point i should have identical copies of data *assuming* i had
>  > no writes in between.
>  >
>  > SO, now in a client i do head -c 1 file0.tar.bz2 and it seems that
>  > since files on server2 have NO xattr, it copies them all over again!!!
>  >
>  > So, is there no viable way to PRECOPY a copy of pre-existing data?
>  > Looks like what we will have to do is a directory by directory
>  > migration or stop all services that rely on the data store, copy the
>  > data to both machines while there are no writes (no changes) going on,
>  > then start everhting back up.
>  >
>  > For those of us that need this in a mail storage scenario, this is not
>  > good. I cant stop my entire mail system for 4 hours while I copy over
>  > 170 gigs of 4 million files.
>  >
>  > Now I will have to think of something a little more tricky like moving
>  > a single maildir subdirectory letter at a time.
>  >
>  > Thoughts, comments, suggestions?
>
>  I am stepping way over my head now, but here goes...
>
>  Is there any way either with a translator or I dont know what, but to
>  implement some kind of algorithm (md5 or whatnot) against the file in
>  this situation? Something that could/would only be used when initially
>  setting up a cluster? I dont knwo if that would require just a
>  seperate script written in whatever language or if it would be
>  something that could belong to glusterfs or what.
>
>  In the case i just described, it would be nice to have something to go
>  through all files such as the find trick, and have both servers do an
>  md5 check or whatever and if they arethe same update the version on
>  the COPY to the same version?
>
>  Is this TOTALLY broken/whackass to do? I know pretty much nothing
>  about file system schematics and such so please dont beat me up too
>  badly.
>
>  =P
>
>
>
>
>  _______________________________________________
>  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