Re: Usynced blocks if replication is interrupted during initial sync

=0A=
Hi Joel=0A=
=0A=
I was never able to get the invalidate steps you outlined to work for our s=
et up. =0A=
=0A=
We downgraded to 9.2.4 kernel driver (the release prior to your referenced =
commit) and no longer see the issue. =0A=
=0A=
Do you know if this issue will be addressed in the next released version of=
 the driver?=0A=
=0A=
Thanks so much for your help=0A=
=0A=
Cheers,=0A=
Tim=0A=
=0A=
=0A=
=0A=
From:=A0Joel Colledge <[email protected]>=0A=
Sent:=A0Wednesday, March 20, 2024 12:02 AM=0A=
To:=A0Tim Westbrook <[email protected]>=0A=
Cc:[email protected] <[email protected]>=0A=
Subject:=A0Re: Usynced blocks if replication is interrupted during initial =
sync=0A=
=A0=0A=
[Caution - External]=0A=
=0A=
> We are still seeing the issue as described but perhaps I am not putting t=
he invalidate=0A=
> at the right spot=0A=
>=0A=
> Note - I've added it at step 6 below, but I'm wondering if it should be a=
fter=0A=
> the additional node is configured and adjusted (in which case I would nee=
d to=0A=
> unmount as apparently you can't invalidate a disk in use)=0A=
>=0A=
> So do I need to invalidate after every node is added?=0A=
=0A=
With my reproducer, the workaround at step 6 works.=0A=
=0A=
> Also Note, the node-id in the logs from the kernel is 0 but peers are con=
figured with 1 and 2 ,=0A=
> is this an issue or they separate ids?=0A=
=0A=
I presume you are referring to the line:=0A=
"Copying bitmap of peer node_id=3D0"=0A=
The reason that node ID 0 appears here is that DRBD stores a bitmap of=0A=
the blocks that have changed since it was first brought up. This is=0A=
the "day0" bitmap. This is stored in all unused bitmap slots. All=0A=
unused node IDs point to one of these bitmaps. In this case, node ID 0=0A=
is unused. So this line means that it is using the day0 bitmap here.=0A=
This is unexpected, as mentioned in my previous reply.=0A=
=0A=
Joel=