Fwd: panic(9) vs. RB_NOSYNC

[Matthew Dillon]

: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
    system.

    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.

					-Matt
					Matthew Dillon 
					<dillon at backplane.com>