Forced FSCK on Bad Reboot

[Mike McCarty]

James Wilkinson wrote:

>Tony Nelson wrote:
>  
>
>>[Linux no longer does an extended check after power outage boot]
>>
>>You could always switch back to Ext2 if you want long checks.  This is
>>probably not a good idea.
>>    
>>
>
>Mike McCarty wrote:
>  
>
>>Why is this not a good idea? Not that I want to change anything.
>>    
>>
>
>OK: this doesn't look like it's been answered.
>
>The problem is that when a computer powers off (or reboots)
>unexpectedly, data in memory is lost, and the operating system "forgets"
>what it was doing.
>
>With ext2, Linux has to take an extended check of the whole filesystem
>to make sure that everything was left in the right place (or at least,
>in a consistent place). It can't always work out exactly which file and
>which filename(s) go together (this is one reason for the lost+found
>directory in each filesystem).
>
>Ext3 is a "journalling" filesystem (as are Reiser, xfs, jfs, and NTFS).
>Linux keeps a journal on disk of what it's doing, and makes sure that
>the journal reaches disk before it makes any changes to the filesystem
>structure on disk.
>  
>
Hmm. So if a power failure occurs during the update of the journal, the disc
is corrupted anyway. It's like a COBOL programmer back in the bad old
days, who claimed that, since he always used databases which had
journals and a separate commit call, his databases could never get
corrupted. I argued and argued with this guy. Sadly, one day he found out
I was correct, and had no recovery plan.

>So when Linux powers up after an unexpected shutdown, it can simply read
>the journal, find out what it was trying to do, and either "roll back"
>the changes or complete them. It *knows* which parts of the filesystem
>to look at, and how to fix them. So this is a much faster operation,
>taking hundredths of a second.
>  
>
So long as the journal is not corrupt.

It seems to me that you left out a lot of details. Reading between the 
lines,
I'll guess that what you are saying is ext3 uses a lot of disc cache with
write-back rather than write-through policy, and journals what it has done
to the memory copy. Thus unwritten system buffers at power down don't
corrupt the disc.

Frankly, I'd rather use write-through.

In any case, I don't see any argument for not using an extended fsck on
a reboot after improper shutdown, which was my original question.

>  
>
>>Hmm. Yet the boot has an option to do an extended check. If the extended
>>check doesn't do any aditional useful work, then why is it an option?
>>    
>>
>
>In theory, ext3 should never get corrupted. But this theory doesn't
>account for certain factors:
>  
>
Yeah. Like preventing corruption of a hard disc is impossible in 
principle, let
alone in practice.

>All Software Sucks. All Hardware Sucks. Most computers don't have ECC
>RAM, and are going to get the occasional memory error. Hard drives and
>processors (and cables) aren't perfect. There are always software bugs
>to worry about. And someone has to worry about overclocking, or
>heatsinks and fans falling off processors (we had *that* one at work
>just today).
>
>Given all that, it's a Good Idea to have some way of detecting and
>correcting corruption in a filesystem.
>  
>
So now we're back to my question: Why shouldn't the system do a full
fsck on reboot after improper/incomplete shutdown?

Mike

-- 
p="p=%c%s%c;main(){printf(p,34,p,34);}";main(){printf(p,34,p,34);}
This message made from 100% recycled bits.
I can explain it for you, but I can't understand it for you.
I speak only for myself, and I am unanimous in that!