e2fsck vs sata_sil & 400GB drive

[Gene Heskett]

Greetings all;

I got a rather unpleasant surprise this morning while rebooting to 2.6.26-rc8

The drive I use for amanda's virtual tapes is a 400GB Deathstar on a sata_sil 
based pci card.

I didn't think too much of it when the bootup said it had been mounted 26 times, 
check forced.  So I knew I was in for a 30+ minute wait, but e2fsck normally 
outputs about the first 24% of the check's progress on that particular drive 
fairly quickly before entering a silent phase that may last 15+ minutes, then 
resume, but do another long pause somewhere in the 80% finished area.  These 
pauses have been part of an e2fsck session since drives went above 40GB IIRC.

But this morning it just sat there without any drive activity or any sign that 
it may have been working, but the keyboard was apparently alive, return keys 
were getting a 1 line scroll.  I let it sit for about 40 minutes while I made 
preps to get to work on a garage attachment for our house.  Then I then tried 
several other kernels in the 2.6.26-rcx category, and all did the same, no 
progress bar from e2fsck at all.

I was forced to reboot to a rescue disk and edit /etc/fstab to remove that drive 
from the fstab list, then rebooted to 2.6.26-rc8 which was then normal, and I 
was able to execute "e2fsck -C0 -p /dev/sdc1", and it ran as expected.  
Re-enabling the entry in fstab, it wouldn't mount, IMO it should have, but did 
on yet another reboot.  All told, a simple reboot took well over 2.5 hours to 
get back to a fully mounted, functioning system.

Catching some total newbie on something like this, and his answer will be to 
reach for the windows install disks, never again to touch linux with a 20 foot 
pole.

I have no idea what the problem is, but this needs moved to the top 5 on the 
list of fixit's.

-- 
Cheers, Gene
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
George Orwell was an optimist.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/