Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
/ 2004-07-30 14:05:47 +0200 \ Lars Ellenberg: > / 2004-07-30 10:50:42 +0200 > \ Andreas Schultz: > > Hi, > > > > First, my apologies for what its going to be an incomplete and probably > > unhelpful problem report. > > > > Some minutes ago one of my test boxes paniced leaving the following > > information behind: > > > > Jul 30 10:30:12 sdev01 kernel: drbd1: IO error on backing device! > > Jul 30 10:30:12 sdev01 kernel: Kernel panic: drbd1: IO error on backing > > device! > > > The initial problem appears to be the: "drbd1: IO error on backing device!" > > which is simply not possible. > > um. maybe unlikely. but. > > the codepath in question is thus: > we get your request > we clone it, register our own bi_end_io handler, and pass it along to > block layer end_io handler gets called by block layer > if end_io handler is called with an error status, this is an IO error > on the backing device, and we panic (the on-io-error Panic setting). > > we don't care what is below us, if it passes back an error, we cannot go: > "oh. that by definition means it was ok, > since we are using three layers of software raid..." :-/ BUT... you may be right anyways. it just occurred to me that we may handle this too unspecific: e.g. read aheads are allowed to fail with EWOUDBLOCK. not every driver actually does, and we don't care. LVM and MD _do_ this under certain certain conditions. currently this is interpreted by drbd as a _real_ io error, even though it is just a "optimization" or "temporary" failure. I'll have a look at it. the reiserfs BUG canceling a panic is a real kernel bug, though. > > Kernel: 2.6.8-rc2-bk1 + vserver-1.9.2.7 + drbd-svn #1442 Lars Ellenberg -- please use the "List-Reply" function of your email client.