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