Stop scheduler on panic
avg at FreeBSD.org
Mon Nov 14 17:22:56 UTC 2011
on 14/11/2011 15:08 Kostik Belousov said the following:
> On Mon, Nov 14, 2011 at 12:06:48PM +0200, Andriy Gapon wrote:
>> On a more serious note:
>> - some code in my latest version of the patch was contributed by or was based
>> on the code or ideas contributed by jhb and mdf (so that attributions are not
Oops, forgot the most recent and quite big contribution from Attilio.
> Please provide me with proper attribution for contributors and testers.
My memory has faded a bit, so let's make it simple.
In cooperation with: attilio, avg, jhb, kib, mdf
Tested by: avg,
Eugene Grosbein <eugen at grosbein.net>,
Steven Hartland <killing at multiplay.co.uk>,
[strike out obvious/unnecessary]
>> - there was a concern about how sync-on-panic would work
>> About the latter, I have never really tested it. mdf has suggested to
>> move the sync-on-panic code to a place after we ensure that there is
>> only one CPU in panic(), but before we stop other CPUs.
> sync_on_panic is incompatible with the patch. I argue that it provides
> non-zero chance of damaging good filesystems even if panic was unrelated
> to the fs/bio/device layer. As an example, consider the case when other
> CPU was modifying in-memory representation of the metadata, and panic
> happen on this CPU. If you write half-changed block back, you make more
> damage to the filesystem then if you do not. The half-backed sync spoils
> any journaling or SU consistency guarantees.
Not sure how this is different from what we have right now (without the patch).
Perhaps I misunderstand what you say, but, just in case, the proposal was to do
sync-on-panic before stopping other CPUs.
> The issues of multithreading nature of our storage subsystem are secondary.
> The user who sets either tunable shall know what he does.
That has always been the case.
and apparently there are people who still want this option to exist.
>> I think that I've already sent you a list of the early testers for
>> various WIP versions of the patch.
> I do not have the list.
> BTW, if you want, feel free to handle the commit youself. You definitely
> spent much more efforts on the stuff and deserve the credit.
> I was promised in private that a review will be provided during this
Unfortunately too little time and spare mind capacity to do the commit now.
I do not care much about the credit (or commit-o-meter) as long as we get
functionality in. It was/is a collective effort in any case.
Besides I won't be able to handle any potential regression reports in a
sufficiently speedy manner.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 552 bytes
Desc: OpenPGP digital signature
Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20111114/4ebea693/signature.pgp
More information about the freebsd-current