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

[Tony Luck <tony.luck@intel.com>]

On Tue, Dec 21, 2010 at 4:53 PM,  <david@lang.hm> wrote:
> almost nobody runs syslog with a fsync after each message anymore. the
> problem is that doing so reduced throughput so much that you ended up
> loosing more messages (and causing processes to block, resulting in
> user-visible problems) because the messages had to queue up for processing.
>
> so if you want to record critical messages and be guaranteed that they are
> on disk, you will be needing a specific application, and not just using
> standard syslog.

Here we are talking about OOPS situations ... when we have an
oops we will log it to persistent store and make sure we keep it
until something else says that the information has been saved
somewhere else.

Not sure how difficult it would be to have syslog parse what it
copies to look for oops signatures and
1) Issue an fsync()
2) Tell the persistent store to drop the record.

Perhaps some other logging mechanism would be better?
I outlined my thoughts for this yesterday:
> 1) Oops happens, gets written to persistent store.
> 2) fs/pstore code makes a file appear in /dev/pstore
> 3) Daemon that's watching /dev/pstore sees new file
> 4) File is read, copied some place safe and fsync'd
> 5) Daemon unlinks file from /dev/pstore
> 6) fs/pstore code tells platform level to erase record

Since this is only for "oops" class events, I don't think that
the fsync should be a performance problem (you really have
much bigger problems if there are that many oopses!)

-Tony