From mboxrd@z Thu Jan 1 00:00:00 1970 From: Huang Ying Subject: Re: [concept & "good taste" review] persistent store Date: Mon, 20 Dec 2010 10:47:14 +0800 Message-ID: <1292813234.8743.66.camel@yhuang-dev> References: <4d0662e511688484b3@agluck-desktop.sc.intel.com> <4D0BEE1F.7020008@zytor.com> <20101219091752.GA16150@liondog.tnic> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Return-path: Received: from mga03.intel.com ([143.182.124.21]:22272 "EHLO mga03.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752042Ab0LTCrY (ORCPT ); Sun, 19 Dec 2010 21:47:24 -0500 In-Reply-To: Sender: linux-arch-owner@vger.kernel.org List-ID: To: Tony Luck Cc: Borislav Petkov , Tony Luck , Linus Torvalds , "H. Peter Anvin" , "linux-kernel@vger.kernel.org" , "linux-arch@vger.kernel.org" , "tglx@linutronix.de" , "mingo@elte.hu" , "greg@kroah.com" , "akpm@linux-foundation.org" , David Miller , Alan Cox , Jim Keniston , Kyungmin Park , Geert Uytterhoeven On Mon, 2010-12-20 at 04:17 +0800, Tony Luck wrote: > On Sun, Dec 19, 2010 at 1:17 AM, Borislav Petkov 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