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