On Mon, 2010-12-20 at 04:17 +0800, Tony Luck wrote: > On Sun, Dec 19, 2010 at 1:17 AM, Borislav Petkov <bp@xxxxxxxxx> wrote: > > Before we go and delve into priority-sorting the oopses in the pstore, > > let me ask this: how big an actual persistent storage device are we > > talking? > > I'm not sure how big the store is on my system ... the ACPI/ERST > interface on this machine limits each entry to just under 8KB. But > that isn't inherent to to ERST, both larger and smaller values would > be an option. 8K seems quite useful for kmsg_dump purposes as > it grabs a significant number of lines leading up to the oops/panic. 8KB is about 100-200 lines message, sometimes it may be not enough for all necessary information. But in fact, we can use multiple ERST records to save one kernel message dumping. So the real limitation is just total storage capacity. For journal (or transaction) semantics, I think the overall picture of system can be as follow, kernel ---> persistent storage ---> user space daemon ---> disk 1. kernel dump OOPS and PANIC message into persistent storage. 2. user space daemon poll persistent storage and erase the record after saving it into disk. So, - for OOPS messages will not cause system panic, it will go to disk and will not use up the persistent storage. - for PANIC message, it will be saved into persistent storage only and read out/saved to disk/erased after successfully rebooting. (Maybe need the heuristic to overwrite the latest OOPS if storage is really tight). The issues are: - We need a user space daemon, via extending /sbin/syslogd? - It is a little hard to implement "poll" support for a file system. Best Regards, Huang Ying -- To unsubscribe from this list: send the line "unsubscribe linux-arch" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
