Re: kern.sync_on_panic

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
>=20
> 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=
_______________________________________________
[e-mail] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[e-mail]"