Delete a directory, crash the system

[Da Rock]

On 03/29/15 08:02, Kirk McKusick wrote:
>> Date: Sat, 28 Mar 2015 22:22:26 +1000
>> From: Da Rock <freebsd-fs at herveybayaustralia.com.au>
>> To: Kirk McKusick <mckusick at mckusick.com>, Benjamin Kaduk <kaduk at MIT.EDU>
>> CC: freebsd-fs at freebsd.org
>> Subject: Re: Delete a directory, crash the system
>> X-ASK-Info: Message Queued (2015/03/28 05:22:36)
>> X-ASK-Info: Confirmed by User (2015/03/28 14:35:33)
>>
>> On 26/03/2015 03:12, Kirk McKusick wrote:
>>
>>> The suggestion to disable journalling is a good one. Journalling fixes
>>> only consistency errors that it knows about and cannot handle media errors.
>>> The sorts of panics you are getting are usually caused by media errors.
>>> So disabling journally and checking all metadata after crashes (which is
>>> what fsck does) should minimize your problems.
>> So my only option for journal is gjournal (slow) or zfs (memory hog) to
>> maintain consistency; is that it? Incidentally, why keep SU+J on as
>> default then? Wouldn't this be considered a bug still, then?
> SU without journaling will maintain consistency. It is just that you
> will need to run fsck after a crash. That is the way FFS has been since
> it was written in 1982 and will allow you to recover from media errors
> which it appears your system is suffering from. SU+J is just a faster
> way of restarting but only works when you do not have media errors.
I guess the point I'm driving at is that on a server this may be an ok 
solution, but if you have workstations/desktops with users who don't 
know how to do this properly, that is why the journalling is an 
important feature. So its not just about faster restarts, but a simple 
reboot/boot and everything is basically ok for them.

If there is any issue a system squawk at the sysadmin will then allow 
them to come in at some point to run a proper check. But in this case, 
we have a system which effectively crashes if there is a problem.

So thats why I mentioned the only other journal type fs' in freebsd, 
because in this scenario a journal is required and it appears these are 
the only alternative that don't create such a catastrophic effect.

Having made my point, what could be done about it - and what can I do to 
help? Would drive details provide data required to pick up the solution?