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. Thanks, -Gennadiy -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.linbit.com/pipermail/drbd-user/attachments/20090421/473d4b0d/attachment.htm>