Primary not accessible until both nodes are UpToDate
acidrop opened this issue · 6 comments
Hi Johannes,
Was testing rc6 and I noticed that the drbd device on the Primary node was not accessible while the synchronization with the Secondary was in progress. Once both nodes went in UpToDate status, only then the drbd device was accessible via its drive letter on Windows Explorer. Before that, it won't even show up in the Disk Management, so it's not a case where the drive letter was missing or something like that.
Steps to reproduce:
- On NodeA: set the resource as Primary
- On NodeB: disconnect (or bring down) the resource
- On NodeA: start writing some data on it
- On NodeA: stop writing data and set the resource as Secondary
- On NodeB: connect (or bring up) the resource, wait until the synchronization starts.
- On NodeA: set the resource as Primary (while the sync is in progress). It will happily set it as Primary, but the drbd device won't appear in Windows Explorer until the sync is completed.
Regards,
Yannis
Hi Yannis, thank you for your detailed bug report. I will try to reproduce and fix it. Are you sure that this is a new bug in 1.0.0-rc6? Can you also post the relevant parts of the drbd config?
Best regards,
- Johannes
Good question, I reverted to rc5 and the issue seems to be there are as well. Perhaps I had not tested this specific sequence of events in the past... The drbd config, is the standard we use in windrbd (almost)...
`include "global_common.conf";
resource "drbd-data" {
protocol C;
net {
use-rle no;
verify-alg crc32c;
timeout 60;
ping-timeout 30;
ping-int 20;
connect-int 10;
}
disk {
c-max-rate 4048000;
c-fill-target 1048000;
}
on win2016-1 {
address 10.2.2.10:7693;
node-id 1;
volume 1 {
disk "0a7d6bc1-6bee-4ae4-8821-cf075128b460";
meta-disk internal;
device minor 45;
}
}
on win2016-2 {
address 10.2.2.20:7693;
node-id 2;
volume 1 {
disk "97241921-0000-0000-0000-100000000000";
meta-disk internal;
device minor 45;
}
}
}
`
Thank you, I suspected that it was there earlier because I touched only the workqueue layer. It is also good to know that you are testing with SCSI interface (no drive letters in device clause), this is the recommended way to access WinDRBD resources. I am just preparing 1.0.0-rc7 which is based on an up-to-date (9.0.25) DRBD and will then look at this issue in more detail,
Thanks for reporting,
- Johannes
Hi Yannis,
I tried to reproduce the issue but only with partital success. In my case I have a 1 GB partition (with NTFS formatted) connected to a Linux machine. I executed the steps you posted and it took a while until the partition showed up in Windows Explorer (and also the partition manager) but once sync was at around 15-20 percent the drive appeared both in explorer and in partition manager. So there was an about 10-20 seconds delay until the drive showed up. But it showed up while sync was still in progress.
Hmm..maybe because the peer was Linux in my case? How big was the partition in your case and how long did it take for a full sync? The only reason for the delayed appearance in explorer I could imagine is that it took too long to read the boot sector and the partition table while the resource was syncing.
(I am using 1.0.0-rc6 with a Linux DRBD 9.0.24 peer).
Thanks for any info,
- Johannes
Hi Johannes,
My DRBD partition is 20GB. I ran some more tests, writing more data this time in order to slow down the re-sync process and I think you are right. The drive letter showed up in Windows Explorer after 15 sec or so, while the re-sync was still in progress (around 35% completed).
I'm going to mark this as closed, sorry for the noise.
Regards,
Yannis
No problem this is exactly the noise I need :) Thanks again for reporting,
- Johannes