[DRBD-user] disk-barrier

Lars Ellenberg lars.ellenberg at linbit.com
Mon Nov 3 22:40:47 CET 2014

Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.

On Mon, Oct 27, 2014 at 06:00:31PM +0100, Roberto Fastec wrote:
> Dear friends
> One kind clarification
> the manual of 8.4 says about disk-barriers
> "disk-barrier
> Use disk barriers to make sure that requests are written to disk in
> the right order. Barriers ensure that all requests submitted before a
> barrier make it to the disk before any requests submitted after the
> barrier. This is implemented using 'tagged command queuing' on SCSI
> devices and 'native command queuing' on SATA devices."

Forget about "barriers", they do no longer exist as such
in the current linux kernel.
All of that funky TCQ/NCQ stuff has been replaced with
what comes down to basically a "drain; flush;" method
used within the current linux kernel.

> and at the end of the disk -barrier it says
> "Only some devices and device stacks support this method. The device
> mapper (LVM) only supports barriers in some configurations."

Meanwhile, with a current software stack,
devicemapper / LVM properly propagates flushes in most configurations.

> this last sentence confuses me a bit, since in XenServer it is used
> LVM and I'm using it
> and at the very end of the section it says
> "Depending on the I/O stack, write requests can be reordered, and they
> can be submitted in a different order on different cluster nodes. This
> can result in data loss or corruption. Therefore, turning off all
> three methods of controlling write ordering is strongly discouraged. "
> Ok. So what?

So you leave at least one (namely: drain) enabled, unless you know
exactly what you are doing and are willing to live with the consequences.

> What it is best to do with a XenServer environment with LVM on SATA disks?

If volatile caches are involved, you will need to either disable those,
and/or configure all users of said caches to add an explicit "flush"
before considering data to be on "stable" storage.

Or do neither, and live with *potential* data loss/corruption
after hard power loss.

: Lars Ellenberg
: LINBIT | Your Way to High Availability
: DRBD/HA support and consulting http://www.linbit.com

DRBD® and LINBIT® are registered trademarks of LINBIT, Austria.
please don't Cc me, but send to list   --   I'm subscribed

More information about the drbd-user mailing list