Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
> > > confused why DRBD did behave like it did. How would DRBD behave when the > > backing device blocks hard? > > With recent enough DRBD, you can configure DRBD to force-detach from a "stuck" > backing device. This may be dangerous, though. You don't want too aggressive > settings there. > > Dangerous: say you submitted a READ, and then the backing device becomes > "unresponsive", and DRBD decides (based on your configuration) to force-detach, > re-try the read from the peer, and finally complete to upper layers. > Then some time later the backing device "suddenly" springs back to life, > processes the still queued request, and now DMAs data from disk to ... > ... where, exactly? > Right. > Into some pages which may meanwhile be reused for something completely > different, or may be unmapped. So in that scenario, best case it triggers > a pagefault and panic, worst case it silently corrupts unrelated data. > > So if you intend to use that feature, maybe you rather want Oops, that went out too early. ... you rather want to make sure the "stuck" device does not come back, ever. How you do that is left as an excercise ... -- : Lars Ellenberg : LINBIT | Your Way to High Availability : DRBD/HA support and consulting http://www.linbit.com