[DRBD-user] kjournald getting stuck in sync_buffer on a drbd device

Florian Haas florian.haas at linbit.com
Mon Apr 28 14:55:03 CEST 2008

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


On Saturday 26 April 2008 01:18:09 Lars Kellogg-Stedman wrote:
> The secondary looks like this:
>
> version: 8.2.5 (api:88/proto:86-88)
> GIT-hash: 9faf052fdae5ef0c61b4d03890e2d2eab550610c build by
> buildsvn at c5-x8664-build, 2008-03-09 10:16:01
>   0: cs:Connected st:Secondary/Primary ds:UpToDate/UpToDate C r---
>      ns:42272 nr:32984 dw:38988 dr:45742 al:1 bm:52 lo:1 pe:0 ua:0 ap:0
> 	resync: used:0/31 hits:2478 misses:28 starving:0 dirty:0 changed:28
> 	act_log: used:0/127 hits:1500 misses:1 starving:0 dirty:0 changed:1
>   1: cs:Connected st:Primary/Secondary ds:UpToDate/UpToDate C r---
>      ns:145396 nr:12 dw:145728 dr:69130 al:1 bm:131 lo:0 pe:0 ua:0 ap:0
> 	resync: used:0/31 hits:635 misses:9 starving:0 dirty:0 changed:9
> 	act_log: used:0/127 hits:36428 misses:1 starving:0 dirty:0 changed:1

So as expected, you have local I/O headed for your Secondary's backing device 
which doesn't complete. Hence the local count ("lo") being >0 on the 
Secondary.

> (Here we're looking at drbd0, so when I say "primary" I mean "the
> system that is primary for drbd0", and similarly for "secondary").
>
> The two systems are passing network traffic back and forth while
> kjournald is hung.  I took a short packet trace, which is available
> here:
>
>    http://people.seas.harvard.edu/~lars/drbd/packets
>
> On the primary, kjournald is stuck in the D state in sync_buffer.  On
> the secondary, there don't appear to be any similarly stuck
> processes.

kjournald is the process that talks to the drbd block device. When that block 
device has pending I/O to process, kjournald goes to the D state. Not seeing 
any other processes in this state is expected.

Our working hypothesis here is still that "something" slows down I/O on your 
secondary.

And, since judging from your packet trace you are in fact using VMware virtual 
machines to run DRBD on, there's really no way for us to tell what.

Please try installing DRBD on a "real" machine and see how that goes.

Cheers,
Florian

-- 
: Florian G. Haas
: LINBIT Information Technologies GmbH
: Vivenotgasse 48, A-1120 Vienna, Austria

When replying, there is no need to CC my personal address.
I monitor the list on a daily basis. Thank you.



More information about the drbd-user mailing list