Date: Thu, 22 Jul 2010 09:02:14 -0400 From: jhell <jhell@DataIX.net> To: Kirk McKusick <mckusick@mckusick.com> Cc: "Mikhail T." <mi+thun@aldan.algebra.com>, fs@freebsd.org Subject: Re: background fsck considered harmful? (Re: panic: handle_written_inodeblock: bad size) Message-ID: <alpine.BSF.2.00.1007220838500.46844@pragry.qngnvk.ybpny> In-Reply-To: <201007212015.o6LKFp9Y066176@chez.mckusick.com> References: <201007212015.o6LKFp9Y066176@chez.mckusick.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 21 Jul 2010 16:15, Kirk McKusick wrote: In Message-Id: <201007212015.o6LKFp9Y066176@chez.mckusick.com> >> Date: Tue, 20 Jul 2010 12:48:58 -0400 >> From: "Mikhail T." <mi+thun@aldan.algebra.com> >> To: Kirk McKusick <mckusick@mckusick.com> >> CC: Jeremy Chadwick <freebsd@jdc.parodius.com>, fs@freebsd.org >> Subject: background fsck considered harmful? (Re: panic: handle_written_inodeblock: >> bad size) >> X-ASK-Info: Message Queued (2010/07/20 09:49:10) >> X-ASK-Info: Confirmed by User (2010/07/20 10:28:39) >> >> 20.07.2010 11:44, Kirk McKusick ???????(??): >>> Adding it to all the panic's will be a lot of work, >>> but I agree would be useful. I will look into doing so when I >>> get a chance. >>> >>> Kirk McKusick >>> >> How about disabling background fsck in a default install? It seems to >> be the consensus here, that my troubles were due to fsck not fixing the >> file-system properly reboot after reboot... >> >> Yours, >> >> -mi > > Certainly disabling background fsck will eliminate that from your > possible set of issues and may prevent a recurrance. It does mean that > after a crash you will have to wait while your filesystems are checked > before your system will come up. If your filesystems are below 0.5Tb > that should be tolerable. > This had me thinking of a possibility to have fsck write & read some meta-data to/from the disk its checking, say an enumerated value somewhere between 1 & 10, whatever would be acceptable. When it would hit this highest predetermined (hard coded) value fsck could return an error code that could be parsed by an rc script to change its behavior to a full check. But along those lines of thinking maybe fsck already returns something like this ? and if so does it do this early enough for a script to catch it ? This ultimately would remove the need to have a background_fsck_enable variable. And would allow for some file-systems to be checked in the background without user intervention while others would be checked in the foreground. And then thinking again maybe this could be handled by the initiating script that sets a variable that's held until the system is writable to be stored somewhere on-disk after the system is up so it could be read the next time around. Personally I prefer the previous as it seems to be a stronger solution. > The longer term solution is to use journaled soft updates when they > become available in 9.0. > > Kirk McKusick > Regards, -- jhell
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?alpine.BSF.2.00.1007220838500.46844>