| |||||||||||||
Persistent storage for a kernel's "dying breath"Persistent storage for a kernel's "dying breath"Posted Mar 24, 2011 13:52 UTC (Thu) by ebirdie (subscriber, #512)Parent article: Persistent storage for a kernel's "dying breath"
The article reminded me about some very old article of writing oopses to a block device, like swap. At then the conclusion was that it isn't wise since a block device might be at stage of mayhem and there is data at stake. Still I find it appealing, that there could be a block driver for pstore and it is at sysadmin's choice to use it or not. The block driver could be configured to use a USB-storage or whatever storage auxiliary to data storage. I guess the main point is that the sysadmin is very very aware to place the pstore behind some other subsystem than the system's main storage.
(Log in to post comments)
crashdump to write logs Posted Mar 26, 2011 11:28 UTC (Sat) by Tobu (subscriber, #24111) [Link] A while ago LWN explained a proposal of using kexec to debug crashes. One prepares a crashdump kernel in some reserved memory area, and when the system crashes, it kexecs into the new kernel which can then write back a big core dump of the crashed kernel. Here are the kdump docs. It seems like both kernels could be extended to dump and read logs in some ram area, which doesn't require hardware support and could be a fallback when there is no persistent area for pstore. Those logs can then be read without requiring kernel debug symbols or a kernel hacker to make sense of the kdump image.
|
|||||||||||||