RE: Re: Uh, another gotcha with AFR, pre-existing data specific

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Something that may be worth mentioning here is that on my glusterfs syncs using the find method I seem to get as close to the wire-speed of my network as I've ever seen. The snmp bandwidth graphs confirm it at > 90Mb/s on a 100Mb network, as does the sync time.

The reason why I'm mentioning this is because this means that it is unlikely you will actually achieve higher speed with rsync.

Gordan

On Tue, 6 May 2008, Christopher Hawkins wrote:

I have a need for something quite similar to that. Seems reasonable to me...


My guess is that what you want to do is:

Set xattr version = 2 for all gluster files on server 1. Start gluster with
AFR. Do a find on all files on server 1, which should copy them to server 2,
whether they already exist there or not (but really server2 should pretty
much be empty).

Now all files should be in sync. I will be doing some testing on this soon
and intend to write a script to handle it... The Md5 check is a good idea
and I'll try to find a way to build that in. Let me know how this goes for
you... Your feedback will be very helpful!

PS - You say "it did no good" but I disagree. In your setup below, even
though it copied the data all over again to server 2, it did so while server
1 was online because you manually set the xattrs on the existing data on
server 1. You had much less downtime than if you had re-copied all the data
from server 1 TO server 1, from non-gluster storage into gluster storage.

Chris

-----Original Message-----
From:
gluster-devel-bounces+chawkins=veracitynetworks.com@xxxxxxxxxx

[mailto:gluster-devel-bounces+chawkins=veracitynetworks.com@no
ngnu.org] On Behalf Of Brandon Lamb
Sent: Monday, May 05, 2008 9:07 PM
To: Gluster Devel
Subject: Re: Uh, another gotcha with
AFR,pre-existing data specific

On Mon, May 5, 2008 at 5:58 PM, Brandon Lamb
<brandonlamb@xxxxxxxxx> 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@xxxxxxxxxx
http://lists.nongnu.org/mailman/listinfo/gluster-devel




_______________________________________________
Gluster-devel mailing list
Gluster-devel@xxxxxxxxxx
http://lists.nongnu.org/mailman/listinfo/gluster-devel





[Index of Archives]     [Gluster Users]     [Ceph Users]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux