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, Jan 3, 2011 at 1:22 AM, Felix Frank <ff at mpexnet.de> wrote: >>> <snip> >>> >>> But the result is undefined! What should DRBD write to the other member? The >>> result of the first or the second write? >>> >>> You are using a tool that permits the execution of stupid I/O streams. Good >>> for stress testing, but not good for data integrity. If you want undefined >>> data on a DRBD pair, then disconnect before the I/O, do the undefined thing, >>> and upon reconnect DRBD will faithfully replicate the garbage. It will still >>> be undefined stuff, but it will be identical undefined stuff. >>> >> Are you seriously thinking that Unix doesn't allow two writes to the >> same LBA simultaneously? >> >> This is part of Unix file system semantics. >> >> A dead system is not the proper outcome. > > Color me ignorant, but what have *file system* semantics got to do with > a block device? Exactly. It should have nothing to do with it, but it's causing lock-outs in the kernel (I'm not sure if that's the proper terminology, but the output is in previous incarnations of this thread) that cause spinning media not under DRBD control (i.e. the root fs) to disconnect (then reconnect as other SD devices... but that does the previous mounts, i.e. "/", no good). Chris > > But I concur, if at all possible, DRBD should probably have a way to > serialize writes in such circumstances. > > Cheers, > Felix >