kern.sync_on_panic

Warner Losh
2011-06-26T05:51:37Z

On Jun 25, 2011, at 8:49 AM, Andriy Gapon wrote:
> Does anybody actually use kern.sync_on_panic tunable/sysctl?
> If yes, then in what circumstances do you need it?
> That is, why any other alternative doesn't work for you?
> Like:
> 1. remounting filesystems R/O before panic if you knowingly provoke it for
testing
> 2. using netboot for your test system
> 3. using su+j, gjournal or a different filesystem altogether
> 4. using fsck after reboot
>
> It seems to me that syncing filesystems in panic context is an adventure.
And it
> may become even more of an adventure if we introduce code that completely
stops
> scheduler in and after panic.

I've used it in the past when I was developing a device driver that was in
the late stages of maturing.  Since all the panics in the system were when the
driver dereferenced NULL in that driver, sync was safe because all the data
structures were sane except the aforementioned driver.

(1) It was a production system, and everything that could be was already mounted
r/w.  However, some small, but every critical, amount of data was still r/w and
it was very important to not lose this data.  Production here likely should be
in quotes, because it was in the late stages of testing/validation.  The problem
was without this sometimes the saved state of the GPS receiver and other
hardware would wind up being zero, which meant that we'd have to do a cold
start which cost us a few hours of time.  At the time I was doing this, we saw
zero files a couple times a day without this turned on.
(2) netbooting wasn't an option since we were qualifying a non-netbooting
system.
(3) these weren't available at the time, but the goal was to prevent data
loss, not to necessarily have to avoid fsck on boot.
(4) Data loss without it.

Now, I'll be the first to admit this has been a few years, and I haven't
done a fresh evaluation to see if things are still safe.  I'll also be the
first to admit that this was a useful debugging setting late in development, and
not in production.  I'm also the first to admit this isn't what I'd
call a very wide-spread case.  But it did come in very handy when chasing a few
bugs to be able to do 10 panic/reboot cycles an hour rather than 2 a day.

Warner