Re: [RFC] pstore: Don't use persistent store for normal shutdown

From: AmÃrico Wang
Date: Tue Mar 22 2011 - 04:54:54 EST


On Tue, Mar 22, 2011 at 4:42 PM, Artem Bityutskiy
<Artem.Bityutskiy@xxxxxxxxx> wrote:
> On Mon, 2011-03-21 at 11:24 -0700, ext Luck, Tony wrote:
>> In commit 04c6862c055fb687c90d9652f32c11a063df15cf
>> kmsg_dump: add kmsg_dump() calls to the reboot, halt, poweroff and emergency_restart paths
>>
>> Seiji Aguchi added kmsg_dump options for all the "normal" ways
>> that a system can be shut down (KEXEC, RESTART, HALT and POWEROFF).
>> It doesn't seem useful to save the kernel log to persistent store
>> in these cases.
>>
>> Signed-off-by: Tony Luck <tony.luck@xxxxxxxxx>
>>
>> ---
>>
>> My /dev/pstore changes have been merged - and I immediately noticed that they
>> now save a record on every shutdown. ÂSome simple detective work with git found
>> that kmsg_dump now has some new "reasons" for calling its subscribers.
>>
>> This patch excludes the four "normal shutdown" cases from being logged
>> to persistent store, on the assumption that we don't want to clutter up
>> a limited amount of storage space with routine data. ÂMy presumption is
>> that there is some other subscriber to kmsg_dump that is doing something
>> with these reason codes ... is that right? ÂOr do you think that we should
>> save the tail of kernel log into persistent store for every shutdown?
>>
>> Perhaps we could save less data for these new reasons? Other ideas?
>
> If you ask me, this smells like policy in the kernel. I'd look into the
> direction of having only the mechanisms in the kernel and letting the
> user-space making policy decisions by choosing what he wants to filter
> out and what he wants to store via some pstore interfaces.
>

I agree, it would be nice if we can have another mount option for this.

Thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/