Date: Fri, 9 Aug 2013 10:24:08 +0900 From: Masao Uebayashi <uebayasi@gmail.com> To: Konstantin Belousov <kostikbel@gmail.com> Cc: freebsd-arch@freebsd.org Subject: Re: panic(9) vs. RB_NOSYNC Message-ID: <CADbF7eeibX9qmaCHJZPok-m2N1FyRR=vr-UJf6%2BLkrQhqv-h7Q@mail.gmail.com> In-Reply-To: <20130808215719.GP4972@kib.kiev.ua> References: <CADbF7edYLBrKQrU9E7HX4Hh_emthRCPcr9WbUPDuLDe5kwNfZQ@mail.gmail.com> <20130808215719.GP4972@kib.kiev.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
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!
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CADbF7eeibX9qmaCHJZPok-m2N1FyRR=vr-UJf6%2BLkrQhqv-h7Q>