[DRBD-user] Concurrent local writes

Lars Ellenberg lars.ellenberg at linbit.com
Fri Apr 23 11:47:23 CEST 2010

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


On Thu, Apr 22, 2010 at 08:38:19AM +0200, Alexander Thieme wrote:
> Hi List,
> 
> I am using DRBD 8.3.7 with XenServer 5.5 U2. The drbd device is used
> by 3 different operating systems: Win XP, Win 2000 and Linux
> paravirtualized 2.6.18.
> 
> I have an issue with concurrent local writes:
> block drbd1: tapdisk[22538] Concurrent local write detected!
> [DISCARD L] new: 120076912s +4096; pending: 120076912s +4096

> This event occurred in a period of 3 seconds and hasn't ever
> occurred before or after.
> 
> This already has been discussed here:
> http://lists.linbit.com/pipermail/drbd-user/2009-April/thread.html#11873
> 
> I understand the problem, however I have some questions:

All of which are answered in the thread you cite above.

> 1.) Lars Ellenberger said "DRBD currently _drops_ the later write.".
> Is this behaviour identical to what any other block device would do?

No quite. On any other block device you end up with either the first
or the second on stable storage.

> I would guess that its safer to drop the first write attempt (or, if
> the areas just overlap, create a single "combined" write attempt.)

We cannot possibly drop the first, because it is already in flight.
That is the whole thing: someone submits a write to a block
that has currently pending in flight writes.

> 2.) Why is this actually a problem when write barriers are used?

They are not used.
Possibly they could be used to workaround the broken IO stack above us.

> 3.) Can drbd configured in such a way that the last write attempt is
> not lost?

No.

> I understand the possibility that an incorrect replication
> is created but I prefer this over local data corruption and let a
> nightly online verify take care of the differences.
> 4.) Is there any known switch in the configuration of windows, which
> might prevent this issue (i.e. disabling the write cache?)?

This has been observed mainly from iSCSI targets,
and reportedly can be worked around by using "fileio" mode.

-- 
: 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