Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
On Thursday 30 September 2004 18:46, Lars Ellenberg wrote:
> / 2004-09-30 15:57:22 +0200
>
> \ Benoit.Ropartz at alcatel.fr:
> > Hello,
> >
> > DRBD 0.7
> > Kernel 2.4.x
> >
> > On Secondary (SyncSource) I see this message :
> >
> > drbd7: ASSERT( page_count(drbd_bio_get_page(&e->private_bio)) == 1 ) in
> > drbd_receiver.c:350
> >
> > The bloc is reading on Secondary because it is not yet syncing on Primary
> > !!!
> >
> > But the reading is OK (control by checksum....) !!!
> >
> > PS : each same reading give same editing on Secondary
>
> hm.
> you are not the first to report this.
> probably some thinko and the assert does not apply,
> rather than a bug ...
>
> I guess Phillip will have a look at this before 0.7.5 is released?
>
> likely that for remote application reads this assert is simply wrong:
> of course the application has still a reference on that page.
>
No, It is a real issue! It is the zeroy_copy_IO network send that still
has the reference to that page.
Under very rare conditions this could cause the read on the primary node
to return wrong data!
The race: drbd_put_ee() puts this buffer onto our free list (nowadays
at the end). If the receiver needs buffers it might get
this one with drbd_get_ee() (unlikely since get_ee takes them
from the beginning of the free list). And in case reding
new data from the disk is quicker then the still ongoing
zero-copy-IO network send ... we got it wrong.
Fixed now. 0.7.5 is really due...
-Philipp
--
: Dipl-Ing Philipp Reisner Tel +43-1-8178292-50 :
: LINBIT Information Technologies GmbH Fax +43-1-8178292-82 :
: Schönbrunnerstr 244, 1120 Vienna, Austria http://www.linbit.com :
-------------- next part --------------
An embedded message was scrubbed...
From: svn at svn.drbd.org
Subject: [DRBD-cvs] r1575 - branches/drbd-0.7/drbd
Date: Fri, 1 Oct 2004 10:15:20 +0200 (CEST)
Size: 3386
URL: <http://lists.linbit.com/pipermail/drbd-user/attachments/20041001/c6654192/attachment.eml>