Re: very slow sync

"Peter T. Breuer" <[email protected]>
Newsgroups gmane.linux.enbd.general
Message-ID <[email protected]>
"Also sprach Hegedus Gabor:"
> I shared a file from node1 to node2, and I make it a raid array. But the
> syncronisation is very slow.

How did you do it?

> The connection between the 2 node is gigabit ethernet. (I can copy files

You probably have a problem with fragmentation, duplex, or something
like that.  Data will tell me. Use FR1 in preference to raid1 anyway.

> between the nodes about 36-40MB/sec, and with drbd the syncronisation
> speed is about that same as the copy speed).

The sync speed is really up to raid1, not anyone else.  I expect you
have not asked raid1 to go any faster than that.  Look in
/proc/sys/dev/raid!


> ------------------------------------------------------------------
> md3 : active raid1 [dev 07:00][1] nda[0]
>       511936 blocks [2/2] [UU]
>       [====>................]  resync =  24.2% (126604/511936)
> finish=23.6min speed=272K/sec
> ------------------------------------------------------------------
> 
> node1:
>  - sata HDD
>  - created 500MB file
>  - running the server processes
>  - kernel 2.6.10 (debian sarge)
>  - debian:/home/hygy# cat /etc/enbd.conf 
>    server adohygy 1234 /home/hygy/nbdimage.fs -b 512

None of that means very much to me :-(. What does enbd say? Show the
output from nbdinfo.

> node2:
>  - 2 sata HDD connected with software raid1
>  - created an 500MB file mounted with node2:#
> losetup /dev/loop0 /home/hygy/slave.fs
>  - created a raid array (mdadm --create /dev/md3 --level=raid1
> --raid-devices=2 /dev/nda /dev/loop0
>  - kernel 2.4.29 (debian sarge)
>  - runnnig the client process
>  - rg-fw:/# cat /etc/enbd.conf
>    client adohygy /dev/nda 192.168.2.1 1234 -n 4 -b 512

I don't get a good picture at all ...  you say RAID1.  So you are
running a raid1 over a loopback device to a local file and a remote enbd
device?  That's quite a lot of layering.


> Why is it slow?

RAID1 works slowly in the background unless you tell it to hurry up!  It
normally tries to avoid occupying i/o bandwidth. I imagine that as soon
as it does something that some activity in loop or enbd makes it shut
itself down again.

If you don't like that, you will have to tell it forcibly to go faster!
Via /proc.

In particular there's a bit of code in its throttle loop that makes it
sleep for something liek a second every time it momentarily goes faster
than its limit speed, and I've always thught that crazy.  You could
excise that as a matter of convenience.

Or run fr1 instead of raid1.

Then we will be into issues of what blocksize you set, whether you set
request aggregation or not on enbd, etc. I can tell if you show me the
data.

Peter
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.