[DRBD-user] DRBD starts too long (in about of 1,5 minutes).

Lars Ellenberg Lars.Ellenberg at linbit.com
Fri Mar 3 23:32:45 CET 2006

Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.


/ 2006-03-04 00:45:11 +0300
\ Igor Yu. Zhbanov:
> Hello!
> 
> I am using DRBD v0.7.16 on top of set of software RAIDs:
> 
> md8 = raid1 (sdc1, (md6 = raid0 (sdb1, sda1))); // DRBD-meta
> md9 = raid1 (sdc2, (md7 = raid0 (sda2, sdb2))); // DRBD-data
> The size of DRBD-data is about 400 GB.

> The story is that (at least when DRBD on second node is shut down) DRBD starts
> in about  of 1,5 minutes.  This is suspiciously long.  DRBD's init-script just
> displays
> Starting DRBD resources:    [ d0
> and you  must to wait  about 1.5 minutes  before it continues. After that time
> everything is ok.

> Feb 26 05:56:49 fileserv1 kernel: drbd0: size = 363 GB (380868352 KB)
> ######### ^^^^^ A LOOOONG DELAY ##############################################
> Feb 26 05:58:22 fileserv1 kernel: drbd0: 363 GB marked out-of-sync by on disk bit-map.

> Than I have compiled DRBD  with maximum debug options enabled  as I could found
> in drbd_config.h. Here is output of how it starts from /var/log/messages:

> Feb 26 06:01:28 fileserv1 kernel: drbd0: size = 363 GB (380868352 KB)
> Feb 26 06:01:28 fileserv1 kernel: drbd0: drbdsetup [13769]:drbd_md_sync_page_io(,72,<NULL>)
> Feb 26 06:01:28 fileserv1 kernel: drbd0: read_sect: sector=0 offset=0 num_words=128
>    ... SKIPPED ... SKIPPED ... SKIPPED ... SKIPPED ... SKIPPED ... SKIPPED ...

> So,  I don't know  what drbd_md_sync_page_io  and  read_sect means  but  23246
> sectors is about of 11 MB (provided the sector size of 512 bytes). I think, it
> is too slow  to read or write 11 MB for 1,5 minutes.  I hope that here happens
> something else.

well, actually, no.
there is not happening something else.
not much, anyways: counting the bits, eventually swapping bytes.

problem is: we do sector wise synchronous io,
thus we don't have throuput, because latency kills us.

some io subsystems behave better than other.
sometimes it helps to play with the io scheduler.
assuming the disk has some internal cache, sometimes it helps doing a
  dd if=<drbd-meta-data-device> bs=1M count=128 of=/dev/null
  (or count=12, in your case)
before.
your "unusual" setup of ( md on top of (scsi and (md on top of scsi)) )
does probably not improve the latency problem either.

> And the question is what is it and how to fix? :-)

well, implement asynchronous io.
we have this in drbd8, which will hopefully see a -pre2 (or so) soonish.

> Is it because of RAID or because of unavailable second node  and much
> data out of sync?

no.

-- 
: Lars Ellenberg                                  Tel +43-1-8178292-0  :
: LINBIT Information Technologies GmbH            Fax +43-1-8178292-82 :
: Schoenbrunner Str. 244, A-1120 Vienna/Europe   http://www.linbit.com :
__
please use the "List-Reply" function of your email client.



More information about the drbd-user mailing list