From: Borislav Petkov <bp@alien8.de>
To: Tony Luck <tony.luck@gmail.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
"H. Peter Anvin" <hpa@zytor.com>,
linux-kernel@vger.kernel.org, linux-arch@vger.kernel.org,
tglx@linutronix.de, mingo@elte.hu, greg@kroah.com,
akpm@linux-foundation.org, ying.huang@intel.com,
David Miller <davem@davemloft.net>,
Alan Cox <alan@lxorguk.ukuu.org.uk>,
Jim Keniston <jkenisto@linux.vnet.ibm.com>,
Kyungmin Park <kmpark@infradead.org>,
Geert Uytterhoeven <geert@linux-m68k.org>
Subject: Re: [concept & "good taste" review] persistent store
Date: Sun, 19 Dec 2010 10:17:52 +0100 [thread overview]
Message-ID: <20101219091752.GA16150@liondog.tnic> (raw)
In-Reply-To: <AANLkTikhtWjFBQmA111Q+2JGRudrRNAmegGThMagr4vF@mail.gmail.com>
On Sat, Dec 18, 2010 at 03:06:57PM -0800, Tony Luck wrote:
> > Doesn't that sound like the best of both worlds?
>
> It sounds like an excellent heuristic for how the platform layer
> should manage the persistent store when space is tight. But
> I think that I can still keep my /dev/pstore filesystem as a
> presentation layer to make the bits available to the user in
> a device independent way.
>
> Or perhaps the pstore layer can help with the implementation
> of the heuristic. It knows what items are in the pstore, so it
> could build & maintain the "ring" and pass the id of the least
> wanted item down to the platform layer whenever it wants to
> write a record ... with the platform layer giving a status to
> say whether it had to delete that item to make space for the
> new one?
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?
Because if it is big enough - for some value of 'big' - we could try to
never let it fill up. If want to save space we might even do something
crazy like compressing the oops info. In the rare event it fills up or
hits some 'almost-full' watermarks, we can kick some userspace daemon
to start writing the oopses to fs and clear the pstore. This all should
happen in the case where all you get is non-critical warnings and the
system is still alive.
However, in the critical cases, you get a single "stream" of oopses with
the first one being the most important one and then you panic. And in
most cases that stream is only a couple of oopses long. For that, the
pstore should be big enough to easily contain it.
[ Btw, if we are able to write that stream to pstore before we panic,
we solve all the problems we have with catching oopses with cameras,
serial consoles, netconsoles, firewire and pen and paper! ]
In that case, when you restart the machine, the same daemon notices the
existence of the oopses and starts writing them to fs, notifies the
users and clears the pstore.
So, I think what we could do is keep our big enough pstore with enough
free space for a bunch of oopses in case we panic. In the remaining
cases, we write them out thus freeing some more space.
Hmmm..
--
Regards/Gruss,
Boris.
next prev parent reply other threads:[~2010-12-19 9:17 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-12-13 18:16 [concept & "good taste" review] persistent store Luck, Tony
2010-12-17 1:57 ` Linus Torvalds
2010-12-17 6:28 ` Tony Luck
2010-12-17 18:09 ` Tony Luck
2010-12-17 18:09 ` Tony Luck
2010-12-17 18:19 ` James Bottomley
2010-12-17 21:38 ` Linus Torvalds
2010-12-17 23:08 ` Tony Luck
2010-12-17 23:08 ` Tony Luck
2010-12-17 23:11 ` H. Peter Anvin
2010-12-17 23:53 ` Tony Luck
2010-12-18 18:23 ` Linus Torvalds
2010-12-18 23:06 ` Tony Luck
2010-12-19 9:17 ` Borislav Petkov [this message]
2010-12-19 17:01 ` Florian Mickler
2010-12-19 20:17 ` Tony Luck
2010-12-19 20:17 ` Tony Luck
2010-12-20 2:47 ` Huang Ying
2010-12-20 10:46 ` David Howells
2010-12-20 10:46 ` David Howells
2010-12-21 0:41 ` Huang Ying
2010-12-21 10:10 ` David Howells
2010-12-22 0:26 ` Huang Ying
2010-12-22 0:32 ` David Howells
2010-12-22 0:32 ` David Howells
2010-12-22 0:43 ` Huang Ying
2010-12-22 0:53 ` david
2010-12-22 0:53 ` david
2010-12-22 7:34 ` Tony Luck
2010-12-20 17:19 ` Tony Luck
2010-12-21 0:48 ` Huang Ying
2010-12-21 5:13 ` Tony Luck
2010-12-21 7:42 ` Borislav Petkov
2010-12-20 7:26 ` Borislav Petkov
2010-12-20 17:18 ` Linus Torvalds
2010-12-20 17:18 ` Linus Torvalds
2010-12-20 18:58 ` Borislav Petkov
2010-12-20 21:09 ` Tony Luck
2010-12-20 21:09 ` Tony Luck
2010-12-20 10:49 ` David Howells
2010-12-20 16:52 ` Tony Luck
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20101219091752.GA16150@liondog.tnic \
--to=bp@alien8.de \
--cc=akpm@linux-foundation.org \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=davem@davemloft.net \
--cc=geert@linux-m68k.org \
--cc=greg@kroah.com \
--cc=hpa@zytor.com \
--cc=jkenisto@linux.vnet.ibm.com \
--cc=kmpark@infradead.org \
--cc=linux-arch@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=tglx@linutronix.de \
--cc=tony.luck@gmail.com \
--cc=torvalds@linux-foundation.org \
--cc=ying.huang@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox