Re: Usynced blocks if replication is interrupted during initial sync
Tim Westbrook <[email protected]> Tue, 16 Apr 2024 02:11:07 +0000
| Newsgroups | gmane.comp.linux.drbd |
|---|---|
| Message-ID | <SJ0PR22MB28114A026C0F8A6E559F4892EA082@SJ0PR22MB2811.namprd22.prod.outlook.com> |
--_000_SJ0PR22MB28114A026C0F8A6E559F4892EA082SJ0PR22MB2811namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Please ignore my Question, I just saw the response from Philipp ________________________________ From: Tim Westbrook <[email protected]> Sent: Monday, April 15, 2024 7:09 PM To: Joel Colledge <[email protected]> Cc: [email protected] <[email protected]> Subject: Re: Usynced blocks if replication is interrupted during initial sy= nc Hi Joel I was never able to get the invalidate steps you outlined to work for our s= et up. We downgraded to 9.2.4 kernel driver (the release prior to your referenced = commit) and no longer see the issue. Do you know if this issue will be addressed in the next released version of= the driver? Thanks so much for your help Cheers, Tim From: Joel Colledge <[email protected]> Sent: Wednesday, March 20, 2024 12:02 AM To: Tim Westbrook <[email protected]> Cc: [email protected] <[email protected]> Subject: Re: Usynced blocks if replication is interrupted during initial sy= nc [Caution - External] > We are still seeing the issue as described but perhaps I am not putting t= he invalidate > at the right spot > > Note - I've added it at step 6 below, but I'm wondering if it should be a= fter > the additional node is configured and adjusted (in which case I would nee= d to > unmount as apparently you can't invalidate a disk in use) > > So do I need to invalidate after every node is added? With my reproducer, the workaround at step 6 works. > Also Note, the node-id in the logs from the kernel is 0 but peers are con= figured with 1 and 2 , > is this an issue or they separate ids? I presume you are referring to the line: "Copying bitmap of peer node_id=3D0" The reason that node ID 0 appears here is that DRBD stores a bitmap of the blocks that have changed since it was first brought up. This is the "day0" bitmap. This is stored in all unused bitmap slots. All unused node IDs point to one of these bitmaps. In this case, node ID 0 is unused. So this line means that it is using the day0 bitmap here. This is unexpected, as mentioned in my previous reply. Joel --_000_SJ0PR22MB28114A026C0F8A6E559F4892EA082SJ0PR22MB2811namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <html> <head> <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"= > <style type=3D"text/css" style=3D"display:none;"> P {margin-top:0;margin-bo= ttom:0;} </style> </head> <body dir=3D"ltr"> <div class=3D"elementToProof" style=3D"font-family: Aptos, Aptos_EmbeddedFo= nt, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 11pt; c= olor: rgb(0, 0, 0);"> Please ignore my Question, I just saw the response from Philipp</div> <div id=3D"appendonsend"></div> <hr style=3D"display:inline-block;width:98%" tabindex=3D"-1"> <div id=3D"divRplyFwdMsg" dir=3D"ltr"><font face=3D"Calibri, sans-serif" st= yle=3D"font-size:11pt" color=3D"#000000"><b>From:</b> Tim Westbrook <Tim= [email protected]><br> <b>Sent:</b> Monday, April 15, 2024 7:09 PM<br> <b>To:</b> Joel Colledge <[email protected]><br> <b>Cc:</b> [email protected] <[email protected]><br= > <b>Subject:</b> Re: Usynced blocks if replication is interrupted during ini= tial sync</font> <div> </div> </div> <div class=3D"BodyFragment"><font size=3D"2"><span style=3D"font-size:11pt;= "> <div class=3D"PlainText"><br> Hi Joel<br> <br> I was never able to get the invalidate steps you outlined to work for our s= et 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 <[email protected]><br> Sent: Wednesday, March 20, 2024 12:02 AM<br> To: Tim Westbrook <[email protected]><br> Cc: [email protected] <[email protected]><br> Subject: Re: Usynced blocks if replication is interrupted during initi= al sync<br> <br> [Caution - External]<br> <br> > We are still seeing the issue as described but perhaps I am not puttin= g 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 b= e 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=3D0"<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> --_000_SJ0PR22MB28114A026C0F8A6E559F4892EA082SJ0PR22MB2811namp_--