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 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..." :-/ once we paniced, we report all further io as error. unfortunately reiserfs will soon BUG, because of that, and in your case the reiserfs BUG seems to cancel our panic... so the box still is "alive", despite of our panic. which is bad. this box should be dead by now! > The backing device for drbd1 is a lvm partition > ontop of a software raid5. The raid5 should no be able by definition to cause > an I/O error as long as at least 2 of the 3 underlying devices are > OK. /proc/mdstat shows that all underlying devices are online. > 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.