Oh gurus of ext3... We have an application (it's essentially a watchdog) that monitors i/o on the root partition of our Linux system. What we would like to have happen is in the event that the root file system "goes away" (e.g. the SCSI cable is pulled from the storage device containing the root drive), we want to panic the kernel. We have tried using the "-e panic" option of tune2fs but that did not seem to do what we expected. What we have observed is that when the root device goes away ext3 will oops and the system hangs. No panic occurs. Any suggestions (tune2fs, ext3 module or kernel options)? FYI, ext3 is compiled as a module in this configuration. We have not yet tried with ext3 built into the kernel. Oops trace available on request. ...Roger...
"gaudet, roger" wrote:> > Oh gurus of ext3... > > We have an application (it's essentially a watchdog) that monitors > i/o on the root partition of our Linux system. What we would like > to have happen is in the event that the root file system "goes away" > (e.g. the SCSI cable is pulled from the storage device containing > the root drive), we want to panic the kernel. We have tried using > the "-e panic" option of tune2fs but that did not seem to do what > we expected. What we have observed is that when the root device > goes away ext3 will oops and the system hangs. No panic occurs. > > Any suggestions (tune2fs, ext3 module or kernel options)? > > FYI, ext3 is compiled as a module in this configuration. We have > not yet tried with ext3 built into the kernel. > > Oops trace available on request.Yup, please send the trace. It's possible that we forget to call the error handler for all I/O errors, but oopsing is not the intended behaviour ;) -
Hi, On Tue, Jul 02, 2002 at 06:18:19PM -0400, gaudet, roger wrote:> Attached is a console trace (oops.txt) of the oopses (there are two of them) > as well as the output of ksymoops (ksymoops.txt). We basically connected a > serial console, started an 'ls -R /' and pulled the SCSI cable. FYI, the > root file system is on /dev/sdc3, /boot is on /dev/sdc1. > > Thanks in advance for taking a look...Yes, it's the one I thought it was:> cp EXT3-fs error (device sd(8,33)): ext3_get_inode_loc: unable to read inode b > lock - inode=11, block=6ext3 copes fine with most of the errors until> Assertion failure in journal_bmap_Ra5771c33() at journal.c:602: "ret != 0"we get an error in the journal. That should be survived gracefully in 2.4.18 onwards. Cheers, Stephen