![](https://csdnimg.cn/release/download_crawler_static/11974445/bg11.jpg)
the hosts has made no modifications at all during split brain, DRBD will simply recover gracefully and declare the
split brain resolved. Note that this is a fairly unlikely scenario. Even if both hosts only mounted the file system
on the DRBD block device (even read-only), the device contents typically would be modified (eg. by filesystem
journal replay), ruling out the possibility of automatic recovery.
Whether or not automatic split brain recovery is acceptable depends largely on the individual application. Consider the
example of DRBD hosting a database. The discard modifications from host with fewer changes approach may be fine
for a web application click-through database. By contrast, it may be totally unacceptable to automatically discard any
modifications made to a financial database, requiring manual recovery in any split brain event. Consider your
application’s requirements carefully before enabling automatic split brain recovery.
Refer to Automatic split brain recovery policies for details on configuring DRBD’s automatic split brain recovery
policies.
2.12. Support for disk flushes
When local block devices such as hard drives or RAID logical disks have write caching enabled, writes to these devices
are considered completed as soon as they have reached the volatile cache. Controller manufacturers typically refer to
this as write-back mode, the opposite being write-through. If a power outage occurs on a controller in write-back
mode, the last writes are never committed to the disk, potentially causing data loss.
To counteract this, DRBD makes use of disk flushes. A disk flush is a write operation that completes only when the
associated data has been committed to stable (non-volatile) storage — that is to say, it has effectively been written to
disk, rather than to the cache. DRBD uses disk flushes for write operations both to its replicated data set and to its
meta data. In effect, DRBD circumvents the write cache in situations it deems necessary, as in activity log updates or
enforcement of implicit write-after-write dependencies. This means additional reliability even in the face of power
failure.
It is important to understand that DRBD can use disk flushes only when layered on top of backing devices that support
them. Most reasonably recent kernels support disk flushes for most SCSI and SATA devices. Linux software RAID (md)
supports disk flushes for RAID-1 provided that all component devices support them too. The same is true for device-
mapper devices (LVM2, dm-raid, multipath).
Controllers with battery-backed write cache (BBWC) use a battery to back up their volatile storage. On such devices,
when power is restored after an outage, the controller flushes all pending writes out to disk from the battery-backed
cache, ensuring that all writes committed to the volatile cache are actually transferred to stable storage. When running
DRBD on top of such devices, it may be acceptable to disable disk flushes, thereby improving DRBD’s write
performance. See Disabling backing device flushes for details.
2.13. Trim/Discard support
Trim/Discard are two names for the same feature: a request to a storage system, telling it that some data range is not
being used anymore [2: For example, a deleted file’s data.] and can get recycled.
This call originates in Flash-based storages (SSDs, FusionIO cards, etc.), which cannot easily rewrite a sector but
instead have to erase and write the (new) data again (incurring some latency cost). For more details, see eg. the
[[https://en.wikipedia.org/wiki/Trim_%28computing%29,wikipedia page]].
Since 8.4.3 DRBD includes support for Trim/Discard. You don’t need to configure or enable anything; if DRBD detects
that the local (underlying) storage system allows using these commands, it will transparently enable them and pass
such requests through.
The effect is that eg. a recent-enough mkfs.ext4 on a multi-TB volume can shorten the initial sync time to a few
seconds to minutes - just by telling DRBD (which will relay that information to all connected nodes) that most/all of
the storage is now to be seen as invalidated.
Nodes that connect to that resource later on will not have seen the Trim/Discard requests, and will therefore start a
full resync; depending on kernel version and file system a call to fstrim might give the wanted result, though.
The DRBD9 and LINSTOR User’s Guide: 2.12. Support for disk flushes
11