From owner-freebsd-fs@FreeBSD.ORG Sat Mar 28 22:24:33 2015 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 687E5AE5 for ; Sat, 28 Mar 2015 22:24:33 +0000 (UTC) Received: from mail.unitedinsong.com.au (mail.unitedinsong.com.au [150.101.178.33]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 1C08E1E1 for ; Sat, 28 Mar 2015 22:24:32 +0000 (UTC) Received: from laptop2.herveybayaustralia.com.au (laptop2.herveybayaustralia.com.au [192.168.0.185]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mail.unitedinsong.com.au (Postfix) with ESMTPSA id 33D6A620A0; Sun, 29 Mar 2015 08:24:27 +1000 (EST) Message-ID: <55172A18.70601@herveybayaustralia.com.au> Date: Sun, 29 Mar 2015 08:24:24 +1000 From: Da Rock User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Kirk McKusick Subject: Re: Delete a directory, crash the system References: <201503282202.t2SM2KAn056827@chez.mckusick.com> In-Reply-To: <201503282202.t2SM2KAn056827@chez.mckusick.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-fs@freebsd.org X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Mar 2015 22:24:33 -0000 On 03/29/15 08:02, Kirk McKusick wrote: >> Date: Sat, 28 Mar 2015 22:22:26 +1000 >> From: Da Rock >> To: Kirk McKusick , Benjamin Kaduk >> CC: freebsd-fs@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?