Differences Between WinDRBD and Linux DRBD

WinDRBD® is based on the original DRBD® source code. However, there are some differences because the architecture of Windows NT differs significantly from the Linux architecture.

There are two types of differences between WinDRBD and the Linux DRBD® version:

• Differences that are imposed by system architecture. These differences will most likely remain in the WinDRBD kernel driver.
• Differences because of unimplemented features. These differences will be addressed in future versions of WinDRBD.

We assume in this article that you understand the basic principles of the Linux DRBD version. To learn about the Linux DRBD version, please consult the DRBD 9 User’s Guide.

Under Linux, DRBD volumes can be accessed as standard Linux block devices (/dev/drbdN, where N is the device minor number). Under Windows the block device interface has several limitations which cause some applications not to work properly on top of a WinDRBD volume. Most notably newer versions of the Microsoft SQL server would not run on top of a WinDRBD volume when it was a block device. The WinDRBD device layer therefore presents WinDRBD volumes as SCSI disks to the system. This causes the Windows Plug and Play manager to stack several Microsoft drivers (the disk.sys and partmgr.sys drivers, among others, depending on the Windows version) over the WinDRBD driver, thereby implementing all necessary application programming interfaces (APIs) that applications need (including undocumented interfaces). This implies that there is a partition table on the WinDRBD disk. For new WinDRBD disks these have to be created right after the device is set up. This can be done by using some PowerShell commands, for example, or by using the Disk Management utility (Windows Meta Key + R, diskmgmt.msc, ) in the Control Panel. To learn how to set up a WinDRBD disk with PowerShell, please read this knowledge base article.

Under Windows there is no such thing as the mount(2) system call. What Microsoft calls mounting is essentially assigning a drive letter to a Windows Volume, thereby making it accessible to applications (internally a symbolic link is created). Windows accesses disks without a defined procedure of opening and closing the device (including offline disks).  Since data on DRBD resources that are secondary can change when the primary peer writes to it, these accesses may read invalid or outdated data. We therefore decided to create a WinDRBD disk dynamically when a resource is promoted to primary (all DRBD volumes of the resource).  Therefore to access the data in read/write mode you have to first run:

drbdadm primary myres

When you have the Disk Management utility or the Device Manager (devmgmt.msc) open you will see the WinDRBD disks appear (and disappear on drbdadm secondary) in the GUI (you might have to refresh the view).

Since there is no device when a resource is secondary, there is consequently also no auto promote (and demote) feature as implemented in the DRBD 9 Linux driver. This is because on WinDRBD, there is no device to access the data as long a resource is secondary. Auto promote makes sense on systems where there is a defined interface for opening the device (such as on Linux systems). When promoting is possible, that is, when no other peers are currently primary, the DRBD driver on Linux promotes a resource to primary when, for example, the containing file system is mounted.

To prevent data corruption, WinDRBD hides file systems on backing devices from the Windows system. Again, this happens to prevent Windows from accessing (most notably writing to) the file system without WinDRBD knowing about it. If Windows were to write to the lower level device, there would instantly be a split-brain situation that would cause data corruption.

WinDRBD hides the file system by altering the file system signature in the boot sector. The file system signature is a 4-byte string starting at offset 3 of the boot sector. For example, if there is an NTFS file system, the string NTFS is in the boot sector. WinDRBD replaces this string by DRBD. This is done when the resource is brought up for the first time, or more precisely in the process of attaching the backing disk. Once this is done, the backing device, not to be confused with the WinDRBD disk device created on drbdadm primary, will show up as RAW in partition manager. The actual change of the file system signature is not done by the WinDRBD driver. Instead the windrbd.exe command line utility does this. On drbdadm up and drbdadm attach this utility is automatically called for all volumes of the resource. In rare cases, you can run the utility manually, either to check the file system state or to restore the file system’s signature in the boot sector to access the data again without routing it through WinDRBD. The commands to do this are (replace X with the drive letter of your backing device):

windrbd hide-filesystem X:

windrbd show-filesystem X:

windrbd filesystem-state X:

Since WinDRBD 1.1.4, it is possible to make existing Windows partitions highly available while maintaining compatibility with Windows applications. This is done by the WinDRBD driver by presenting a GPT partition table before and after the backing device. Windows will treat the WinDRBD device as a regular disk with one data partition on it and again stack the drivers for compatibility over the WinDRBD driver. WinDRBD’s implementation is smart enough to detect file systems on the backing device and to correctly generate the GPT partition table. Drive letters can be assigned to the data partition with standard Windows tools. The GUIDs in the partition table that identify the disk in Windows are generated from unique serial numbers in the file system’s boot sector. Now WinDRBD supports this for NTFS and ReFS, other file systems will follow upon request. If a file system is currently not supported, WinDRBD will generate a random GUID which will cause Windows to treat the disk as a new disk (Offline and Read Only) each time the resource is promoted to primary.

There is a subtle difference in the syntax of the disk and meta-disk clauses in a DRBD configuration file. Since there is no such thing as a /dev directory in the Windows file system, you can either specify backing devices by drive letter or by volume GUID, in a DRBD configuration file. Examples are:

disk E:;

meta-disk 3e56b893-10bf-11e8-aedd-0800274289ab;

You can find the volume GUID using the Windows mountvol utility. Besides this minor difference, there are no differences between Linux and Windows in the DRBD configuration file syntax. The configuration files can be found in the WinDRBD system root directory which defaults to C:\WinDRBD. So, assuming that you haven’t changed the system root directory at install time, the directory for the WinDRBD *.res configuration files is:

C:\WinDRBD\etc\drbd.d

Since there is no package management system similar to those from Linux distributions, such as DEB or RPM, we implemented an Inno Setup based installer that comes as a self-extracting EXE file. You can download these installers from the LINBIT® website’s downloads page. To install WinDRBD, just download and then run the EXE file.

To learn how to automate the WinDRBD installation process, refer to this knowledge base article. The DRBD installation program includes complete uninstall and upgrade support. It is usually not necessary to restart Windows when updating the WinDRBD driver.

The DRBD installation program first brings all WinDRBD resources down, shuts down WinDRBD related services (such as the logger service or LINSTOR® Satellite for Windows), and then unloads the driver. After that, it installs the new driver and restarts the services that were running before. It does not restart the WinDRBD resources. However, if you are using LINSTOR For Windows, the LINSTOR Satellite service will do that (for resources that were created by LINSTOR).

Although WinDRBD is in a 1.X stable release state and therefore ready to be used in production environments, there are some features that the Linux DRBD release supports that at the time of this writing (February 2023, WinDRBD 1.1.6) are not yet supported by WinDRBD. Here is an incomplete list of those missing features:

• Now, no real cryptographic algorithms are supported for verify-algand cram-hmac-alg. Only crc32c is supported. WinDRBD resources will fail to start if you specify anything besides crc32c as a cipher in the WinDRBD configuration file.
• No TRIM or DISCARD support: Especially SSDs and NVRAMs, but also thin-provisioned storage, benefit from this feature. It is a mechanism for an application to tell the storage driver that portions of data are not needed any more and can be discarded. Essentially it is an optimization for SSDs and NVRAMs. At the moment, WinDRBD does not support these special requests.
• Remote booting: While it is possible to boot from a WinDRBD disk remotely, setting this up is very complex and time consuming. Also there are other limitations (such as missing recovery from network outages) which currently make it not advisable to use WinDRBD for running Windows from a remote disk.
•  DRBD version: Currently, WinDRBD is based on the 9.0 branch of DRBD.  Due to various software engineering related topics this cannot be upgraded easily to 9.1 or even 9.2.

We are aware of these issues and will address them in future versions of WinDRBD.

If you have any questions about features in WinDRBD, reach out to LINBIT®, either by using the contact us web form on the LINBIT website, by sending an email to sales@linbit.com, or by joining the LINBIT Community Forum.

Written by JT, 02/17/2023.

Reviewed by MAT, 02/22/2023.