[DRBD-user] Opteron/Xeon - Kernel 2.4/2.6 setup

Lars Ellenberg Lars.Ellenberg at linbit.com
Tue Jun 15 11:08:06 CEST 2004

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


/ 2004-06-15 10:21:56 +0200
\ Lars Ellenberg:
> / 2004-06-15 11:57:46 +0400
> \ Eugene Crosser:
> > On Mon, 2004-06-14 at 09:51 +0200, Lars Ellenberg wrote:
> > 
> > > > I saw that the 0.7 branch should work on kernel 2.6.
> > > > But would it be crazy to use this in a production environment?
> > > 
> > > currently that would be asking for trouble.
> > > we have indication that under some circumstances drbd 0.7 may still
> > > cause data inconsistencies between its mirrors [read data corruption] :(
> > 
> > It was me who provided said indication.
> > I've got a (crasy?) thought: could that inconsistency be caused by
> > initially wrong meta-disk information, that does not get fully refreshed
> > after "invalidate"?  The point is that I had switched between 0.6 and
> > 0.7 several times, and every time I changed 0.6 to 0.7, meta-disk
> > naturally was out-of-sync with the actual data.  Of course I ran
> > "invalidate" every time, but maybe it is not sufficient?
> 
> nope. several thinkos in 0.7 bitmap handling, some probably where not
> really thinkos, but typos. leading to several off-by-one,
> off-by-factor-4, off-by-factor-8, and totally-off bugs...  
> anyways, debugging of that [] old bitmap code has proven to be undoable,
> and it has proven itself to be seriously broke.
> 
> so I implemented it from scratch now, should find its way into cvs today.
> since it is new (written yesterday in one go), it may of course have new
> bugs, but it is MUCH more readable and thus easier to debug...

can you do me a favor please: my local test setup is not able reproduce
the problem, so I cannot verify if this fixes it...

use current cvs (needs to have drbd_bitmap.c), and the patch below
(unless philipp already checked it in), and see whether your test setup
can verify that now we no longer have data corruption.

	lge
-------------- next part --------------
A non-text attachment was scrubbed...
Name: u.gz
Type: application/x-gunzip
Size: 20432 bytes
Desc: not available
URL: <http://lists.linbit.com/pipermail/drbd-user/attachments/20040615/e30146a0/attachment.bin>


More information about the drbd-user mailing list