[prev in list] [next in list] [prev in thread] [next in thread] 

List:       freebsd-arch
Subject:    Re: panic(9) vs. RB_NOSYNC
From:       Masao Uebayashi <uebayasi () gmail ! com>
Date:       2013-08-09 1:24:08
Message-ID: CADbF7eeibX9qmaCHJZPok-m2N1FyRR=vr-UJf6+LkrQhqv-h7Q () mail ! gmail ! com
[Download RAW message or body]

On Fri, Aug 9, 2013 at 6:57 AM, Konstantin Belousov <kostikbel@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!
_______________________________________________
freebsd-arch@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org"
[prev in list] [next in list] [prev in thread] [next in thread]