<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<style type="text/css" style="display:none;"> P {margin-top:0;margin-bottom:0;} </style>
</head>
<body dir="ltr">
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 11pt; color: rgb(0, 0, 0);">
Please ignore my Question, I just saw the response from Philipp</div>
<div id="appendonsend"></div>
<hr style="display:inline-block;width:98%" tabindex="-1">
<div id="divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" style="font-size:11pt" color="#000000"><b>From:</b> Tim Westbrook <Tim_Westbrook@selinc.com><br>
<b>Sent:</b> Monday, April 15, 2024 7:09 PM<br>
<b>To:</b> Joel Colledge <joel.colledge@linbit.com><br>
<b>Cc:</b> drbd-user@lists.linbit.com <drbd-user@lists.linbit.com><br>
<b>Subject:</b> Re: Usynced blocks if replication is interrupted during initial sync</font>
<div> </div>
</div>
<div class="BodyFragment"><font size="2"><span style="font-size:11pt;">
<div class="PlainText"><br>
Hi Joel<br>
<br>
I was never able to get the invalidate steps you outlined to work for our set up.
<br>
<br>
We downgraded to 9.2.4 kernel driver (the release prior to your referenced commit) and no longer see the issue.
<br>
<br>
Do you know if this issue will be addressed in the next released version of the driver?<br>
<br>
Thanks so much for your help<br>
<br>
Cheers,<br>
Tim<br>
<br>
<br>
<br>
From: Joel Colledge <joel.colledge@linbit.com><br>
Sent: Wednesday, March 20, 2024 12:02 AM<br>
To: Tim Westbrook <Tim_Westbrook@selinc.com><br>
Cc: drbd-user@lists.linbit.com <drbd-user@lists.linbit.com><br>
Subject: Re: Usynced blocks if replication is interrupted during initial sync<br>
<br>
[Caution - External]<br>
<br>
> We are still seeing the issue as described but perhaps I am not putting the invalidate<br>
> at the right spot<br>
><br>
> Note - I've added it at step 6 below, but I'm wondering if it should be after<br>
> the additional node is configured and adjusted (in which case I would need to<br>
> unmount as apparently you can't invalidate a disk in use)<br>
><br>
> So do I need to invalidate after every node is added?<br>
<br>
With my reproducer, the workaround at step 6 works.<br>
<br>
> Also Note, the node-id in the logs from the kernel is 0 but peers are configured with 1 and 2 ,<br>
> is this an issue or they separate ids?<br>
<br>
I presume you are referring to the line:<br>
"Copying bitmap of peer node_id=0"<br>
The reason that node ID 0 appears here is that DRBD stores a bitmap of<br>
the blocks that have changed since it was first brought up. This is<br>
the "day0" bitmap. This is stored in all unused bitmap slots. All<br>
unused node IDs point to one of these bitmaps. In this case, node ID 0<br>
is unused. So this line means that it is using the day0 bitmap here.<br>
This is unexpected, as mentioned in my previous reply.<br>
<br>
Joel</div>
</span></font></div>
</body>
</html>