Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
Hello all, Thanks for letting me join the list. I'm afraid I have a question - have searched the archives, the docs and the website, but I can't find mention of this problem. Apologies if it's been asked before. Short version: If a DRBD-controlled underlying block device (/dev/hda3, for example) is mounted directly without DRBD running, the data is changed, then DRBD is reinstated using that block device, will DRBD recognise the changes? Long version: A bit of background: I have been running drbd on a two-machine cluster, with heartbeat managing failover. This has been working very well for months, and we have had no hiccups with it. Yesterday, after a kernel-upgrade-gone-wrong, the DRBD kernel module was not able to be inserted into the kernel. As it was extremely time-critical that the primary machine's data came back up, I thought "no problem, I'll just mount the underlying device on the mount point" : # mount /dev/hda3 /data1 Which worked fine. The users of the system then started to use and make changes to the data in /data1. And then proceeded to find out the cause of the problem by using our secondary node (turns out the kernel needed a 'make clean' as well as a 'make' and a 'make modules_install'). Now, DRBD works on the secondary (data out-of-date) node, and can be made to work on the primary. My question is: as the data on the underlying device (/dev/hda3) has changed without DRBD 'knowing about it', and this is the 'known good' copy of the data, will DRBD get confused or will it just notice the new/changed files and sync to the secondary as usual? If this isn't the expected case, is the only option to rsync the data away from the current partitions, modprobe drbd, invalidate all data, then make primary, and rsync back, or is there another way? Many thanks for any help anyone can offer - would be much appreciated! Yours Guy Davies