background fsck considered harmful? (Re: panic: handle_written_inodeblock: bad size)

[jhell]

On Wed, 21 Jul 2010 16:15, Kirk McKusick wrote:
In Message-Id: <201007212015.o6LKFp9Y066176 at chez.mckusick.com>

>> Date: Tue, 20 Jul 2010 12:48:58 -0400
>> From: "Mikhail T." <mi+thun at aldan.algebra.com>
>> To: Kirk McKusick <mckusick at mckusick.com>
>> CC: Jeremy Chadwick <freebsd at jdc.parodius.com>, fs at 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