Fwd: panic(9) vs. RB_NOSYNC
dillon at apollo.backplane.com
Thu Aug 8 10:11:42 PDT 2013
:DragonFly has made quite a few changes to panic() but the if
:(panicstr) RB_NOSYNC part still remains. Thought?
: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.
Well, the sync-on-panic can also be turned off with a sysctl. I think
we are going to stick with the default try-to-sync. Multiple entries
into panic do work fairly well as a means of detecting a truly hosed
Most modern filesystems don't corrupt any more if left unsynchronized,
but the real problem here is that filesystem do so much caching in
memory, particularly when files are mmap()'d RW, that not at least
trying to sync can result in disarray (rather than corruption) on boot
that can make the sysadmins job harder. The try-to-sync default could
be changed at a future date if work is undertaken to leave files
undergoing modification in less disarray.
<dillon at backplane.com>
More information about the Kernel