> Seth M. Landsman writes:
> [snip]
> > A number 3 axe does wonders to introduce errors ... A hammer, a
> > two year old or the neighbor's dog will also go a long way to stress
> > testing a kernel ... :-)
> [snip]
>
> I was being serious (well the paint shaker idea was going a little too
> far, but the magnet, needle and SGT4MAT ideas were serious). The
> filesystem and drive controller drivers are mostly tested on perfect
> media. There is some utility to ensuring that a bad sector or two on
> media doesn't cause the kernel to crash or hang. I don't think any
> one expects the kernel to survive an axe passing through any piece of
> harware, or the neighbors dog urinating on the keyboard.
>
> What I want to ensure is that a bad sector (or even a whole track or
> head) on magnetic media or dirty heads can't crash the kernel. The
> consequences for the user programs which get errno=EIO back from
> read() or write() is not a kernel issue. However, ensuring that the
> kernel doesn't fall over before that happens is.
The frivality was uncalled for but appropriately noted (the :-)
was there).
Regardless, I could not help with sarcrificing hardware for the
cause (beyond my means right now), but I agree that it is a necessity.
An interesting question is poised, though. If linux was to become
the operating system of choice for mission critical applications, such as
embedded systems, people would want to see the kernel not crash after a
chunk of it gets disconnected or destroyed or mangled. While this may be
beyond the current scope, it is something interesting to think about as a
future project (keeping the axe and neighbor's dog in mind ... :)).
-Seth