panic(9) vs. RB_NOSYNC
Masao Uebayashi
uebayasi at gmail.com
Fri Aug 9 01:24:10 UTC 2013
On Fri, Aug 9, 2013 at 6:57 AM, Konstantin Belousov <kostikbel at gmail.com> wrote:
> On Thu, Aug 08, 2013 at 02:36:51PM +0900, Masao Uebayashi wrote:
>> panic(9) (actually vpanic()) sets RB_NOSYNC when panicstr is already
>> set. What is the reasoning of this?
>>
>> My understanding is that panic() attempts VFS "sync" operation at
>> first. If another panic() is triggered during that, give up VFS
>> "sync". Is this correct? If so, how reliable is this design? I
>> wonder if attempting such a complex task like VFS "sync" after a panic
>> is a good idea.
>
> Look at the end of the vpanic(), right before kern_reboot() call.
> There, kernel does
> if (!sync_on_panic)
> bootopt |= RB_NOSYNC;
> so it only syncs when sync_on_panic sysctl is set to non-zero, which
> is zero by default.
I didn't notice that.
> Basically, this option might be reasonable when you debug something
> not related to i/o+VM+storage drivers, and you know what you do.
So most of FreeBSD users have been happy without try-sync-after-panic
for years. Good to know that, thanks!
More information about the freebsd-arch
mailing list