There is an interesting case of failing technology due to an unimplemented feature. See the following mail list thread for the original post.
Basically if you deploy DRBD and one of the endpoints is a vmware virtual machine:
– when trying to mount a newly created etx4 file-system over the LVM from the drbd device from the vmware disk a “disk detached” error occurs.
A nice explanation a solution is also provided by “Lars Ellenberg” from LinBit.
For some reason, (some? not only?) VMWare virtual disks tend to pretend to support “write same”, even if they fail such requests later.
DRBD treats such failed WRITE-SAME the same way as any other backend error, and by default detaches.
mkfs.ext4 by default uses “lazy_itable_init” and “lazy_journal_init”, which makes it complete faster, but delays initialization of some file system
meta data areas until first mount, where some kernel daemon will zero-out the relevant areas in the background.
Older kernels (RHEL 6) and also older drbd (8.3) are not affected, because they
don’t know about write-same.
Don’t use the “lazy” mkfs. During normal operation, write-same is usually not used.
Or tell the system that the backend does not support write-same:
grep ^ /sys/block/*/device/scsi_disk/*/max_write_same_blocks
echo 0 | tee /sys/block/*/device/scsi_disk/*/max_write_same_blocks
You then need to re-attach DRBD (drbdadm down all; drbdadm up all)
to make it aware of this change.