HDD problems causing Kernel panics in Linux/Debian?
in [Storage]
|
Prev: [fw] Oracle Drops Hitachi Data Storage Arrays
Next: Any way to revive a dropped 1.5TB Seagate drive? MUST GET IT TO SPIN UP
From: Rod Speed on 7 Mar 2010 15:48 Pascal Hambourg wrote > Arno wrote >> Pascal Hambourg <boite-a-spam(a)plouf.fr.eu.org> wrote >>> Rod Speed wrote >>>> Pascal Hambourg wrote >>>>> Aren't pending sectors sectors waiting to be remapped because of read errors ? >>>> Thats not the same thing as unreadable sectors. >>> Aren't pending sectors unreadable, because of read errors ? >> A pending sector is one that the disk tried to read but failed. > "Tried to read but failed", that looks very much like the definition of "unreadable" to me. Nope, the difference is that a successful read varys, it isnt necessarily always unreadable to be a pending sector.
From: Rod Speed on 7 Mar 2010 15:54 Yousuf Khan wrote > Pascal Hambourg wrote >> Rod Speed wrote >>> Pascal Hambourg wrote >>>> Aren't pending sectors sectors waiting to be remapped because of read errors ? >>> Thats not the same thing as unreadable sectors. >> Aren't pending sectors unreadable, because of read errors ? > Pending sectors are still readable, Some of them are unreadable, just not all of them are. > but they are weak when it comes time to write to them. So they are pending remapping during the next write to them. Even unreadable sectors are marked as pending until the write, so you can attempt to get what data is in them before the write/reallocate. And to Pascal, this is a good example of what a mess your agressive snipping can produce, leaving it all in is much more readable.
From: David Brown on 7 Mar 2010 16:14 Ant wrote: > On 3/7/2010 9:20 AM PT, Arno typed: > >> You don't need to, no disk access is possible after a kernel >> panic, hence no loging. The only thing you can do, is to >> look at the screen or to enable the serial console output and >> log that on another machine. >> >> The reason no disk access is possible is simple: A kernel >> panic only hapens when the kernel internal state is regarded >> as seriously corrupted. A disk access could then cause serious >> filesystem corruption (at least writing) and is therefore >> not done. > > So Windows' blue screens with memory dumps are different? Yes - when windows discovers that things have gone so completely wrong that it BSOD's, it then takes the opportunity to risk greater havoc by writing to the disk. Linux cuts your loses by stopping any disk writes.
From: Bill Marcum on 7 Mar 2010 18:26 ["Followup-To:" header set to comp.os.linux.hardware.] On 2010-03-07, Ant <ant(a)zimage.comANT> wrote: > On 3/7/2010 12:47 AM PT, Yousuf Khan typed: > >> HOWTO enable core-dumps - LinuxReviews >> http://en.linuxreviews.org/HOWTO_enable_core-dumps > > Thanks. Isn't this for program crashes, not kernel panics? I wonder why > it was removed because I used to see those core files from crashes. Core dumps are usually disabled by default because often they just take up space and are never seen by anyone who knows how to interpret them. Some software automatically mails a bug report to the developers if it crashes.
From: Yousuf Khan on 8 Mar 2010 07:53
Arno wrote: > You don't need to, no disk access is possible after a kernel > panic, hence no loging. The only thing you can do, is to > look at the screen or to enable the serial console output and > log that on another machine. > > The reason no disk access is possible is simple: A kernel > panic only hapens when the kernel internal state is regarded > as seriously corrupted. A disk access could then cause serious > filesystem corruption (at least writing) and is therefore > not done. > > Arno However, it doesn't look like his problems are actually disk related. The disk-related messages just seem to coincidental and minor. Yousuf Khan |