[DRBD-user] Concurrent writes

Gennadiy Nerubayev parakie at gmail.com
Tue Apr 21 16:02:33 CEST 2009

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

On Tue, Apr 21, 2009 at 4:37 AM, Lars Ellenberg
<lars.ellenberg at linbit.com>wrote:

> On Mon, Apr 20, 2009 at 07:05:31PM -0400, Gennadiy Nerubayev wrote:
> > On Mon, Apr 20, 2009 at 6:28 AM, Lars Ellenberg
> > <lars.ellenberg at linbit.com>wrote:
> >
> > > On Mon, Apr 20, 2009 at 12:13:58PM +0200, Lars Ellenberg wrote:
> > > >
> possibly the target "announces" the equivalent of "tagged command
> queueing" in iSCSI, and the initiator tries to take advantage of that,
> but either target or initiator implement that incorrectly.
> not sure how to verify this assumption, maybe using wireshark on the
> iSCSI layer (which would also be a way to get to the actual data
> of the overlapping requests).

I'll try to get some more info about this, but I'm currently completely out
of ideas :(

data divergence due to conflicting (overlapping)
> writes cannot happen when DRBD is not connected.
> so in this case DRBD does not care.

Gah. But wait, you mentioned in the first email that "submitting a new write
request overlapping with an in flight write request is bad practice on any
IO subsystem, as it may violate write ordering, and the result in general is
undefined". So why don't we care about it in the standalone mode? Why can't
it happen when DRBD is disconnected? And if it can, why doesn't it cause
data corruption? I'm still trying to understand why this is not causing
issues for so many people that are running IET in blockio mode on standalone
targets (including those built on IET such as openfiler), yet when DRBD is
introduced, we run into this situation.

Sorry if it seems like I'm trying to single out DRBD as the culprit, but I
can't quite grasp why this only appears to be a problem on DRBD (paranoia
checking for the condition aside), and that the problem is big enough to
discard writes.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linbit.com/pipermail/drbd-user/attachments/20090421/473d4b0d/attachment.htm>

More information about the drbd-user mailing list