Re: [concept & "good taste" review] persistent store

[Huang Ying <ying.huang@intel.com>]

On Mon, 2010-12-20 at 04:17 +0800, Tony Luck wrote:
> On Sun, Dec 19, 2010 at 1:17 AM, Borislav Petkov <bp@alien8.de> 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