Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
/ 2006-07-04 21:37:14 +0800 \ Badge Parag-G19470: > Hi Lars, > > As a part of your reply to question: > > http://archives.free.net.ph/message/20060620.111834.71d3a4c0.en.html > > > you are saying that there are several options to solve this problem. But I am > seeing only one, which is to clean-up meta data. > Do you think there are other solutions to solve this issue if we don't > want complete sync-up every time we encounter this problem? depending in which part of the GCs differ, it may even help to # drbdadm connect all a couple of times (which might be seen as bug but I see as a feature) and of course, there are different ways to "clean up" the meta data. if one knows the details and context of the situation, one could try and manipulate them in a way that there will be a bitmap-based resync, not a full sync. Only if you are certain, that the (merged, bitwise or'ed together) bitmap is still valid and covers _all_possible_ data divergence. this would be on the "bad" node stop drbd, unconfigure drbd, reset the GC's to something smaller than on the "good" node, and just in case set the inconsistent flag. then start it up again and connect. But in case there are blocks with data divergence that are not covered by the bitmap, all would apear to work, until the next failover and maybe even beyond, and then suddenly out of nowhere BOOM you notice data corruption. and you'd blame it on drbd. which would be kind of unfair. cheers, -- : 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 :