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