Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
/ 2006-12-08 13:58:33 -0200
\ Daniel van Ham Colchete:
> Hi Yall,
>
> I'm building my very first DRBD RAID. I've been sucessfull and
> everything is working great.
>
> My current config is:
> SERVER1:
> sda 400GB + sdb 400GB = md Software RAID1
> sdc 250GB
>
> SERVER2:
> sda 250GB + sdb 250GB = md Software RAID1
> sdc 400GB
>
> My problem is, when the DRBD`s metadata is allocated to a md partition
> (internal or /dev/md5[0]) the load time is greater than 4 minutes.
> What I mean by load is "drbdadm up drbd0". I had to recompile drbdadm
> changing it's timeout value from 120 to 600 seconds because of that,
> otherwise my distro wouldn't init the both drbd devices.
>
> Them, on the server that the metadata is being stored at the plain sdc
> disk, the load time is less than 2 seconds. Important: I'm using
> exactly the same hardware to each size, all the 400GB sized
> harddrivers are exectly the same.
>
> So, I tried changing both metadata storage place to plain sata drives
> and everything loaded in less than 2 secs.
>
> I also tried storing the metadata in internal and exlusive MD
> partitions but the load time were the same: 4-5 minutes to the 340GB
> partition and 2' 5'' to the 194GB partition.
>
> Looking through DRBD's source I found that the delay is probably
> happening that the _drbd_md_sync_page_io of the drbd_actlog.c file.
> Probabily at the wait_for_completion(&event); line.
>
> I'm using the kernel 2.6.18 with DRBD 0.7.22. My kernel has the
> BIO_RW_SYNC defined.
I think the md raid code strips off the BIO_RW_SYNC flag...
that way you suffer from the additional induced latency
with every meta data update.
this is just a suggestion for raid1, similar patch for the other raid levels...
should apply with small offsets to other kernel versions, too.
it may well be that the _re_assignment of the bi_rw is actually
the real bug: bio_clone has already set it, and even set some other
flags there as well, which probably should not be stripped off either.
feel free to forward this to lkml.
diff -u drivers/md/raid1.c*
--- /mnt/kernel-src/linux-2.6.19/drivers/md/raid1.c.orig 2006-12-11 10:06:17.661776243 +0100
+++ /mnt/kernel-src/linux-2.6.19/drivers/md/raid1.c 2006-12-11 10:11:42.189647127 +0100
@@ -776,6 +776,7 @@
struct page **behind_pages = NULL;
const int rw = bio_data_dir(bio);
int do_barriers;
+ int do_sync;
/*
* Register the new request and wait if the reconstruction
@@ -891,6 +892,7 @@
atomic_set(&r1_bio->behind_remaining, 0);
do_barriers = bio_barrier(bio);
+ do_sync = bio_sync(bio);
if (do_barriers)
set_bit(R1BIO_Barrier, &r1_bio->state);
@@ -906,7 +908,7 @@
mbio->bi_sector = r1_bio->sector + conf->mirrors[i].rdev->data_offset;
mbio->bi_bdev = conf->mirrors[i].rdev->bdev;
mbio->bi_end_io = raid1_end_write_request;
- mbio->bi_rw = WRITE | do_barriers;
+ mbio->bi_rw = WRITE | do_barriers | do_sync;
mbio->bi_private = r1_bio;
if (behind_pages) {
--
: Lars Ellenberg Tel +43-1-8178292-0 :
: LINBIT Information Technologies GmbH Fax +43-1-8178292-82 :
: Vivenotgasse 48, A-1120 Vienna/Europe http://www.linbit.com :
__
please use the "List-Reply" function of your email client.