[plug] How long to fsck 160 GB?

[Bernd Felsche]

"Patrick Coleman" <blinken at gmail.com> writes:
>On 6/26/06, Bernd Felsche <bernie at innovative.iinet.net.au> wrote:

>> As people are in the habit of storing copies of something
>> "important" in every place they think fit, filesystem sizes have
>> grown massively over the past decade. And they still can't find what
>> they want... Which I often assume is the work already done for them.
>>
>> So more drives have been added and files shuffled onto a stripey
>> logical volume.
>>
>> Previous partition removed from the partition table and the
>> remaining filesystem (Reiser) told to grow from 100 to 150 GB to
>> fill the space. Minor problem.  Strange error.

>> So start up fsck on the filesystem -- now 2 hours later; still not
>> finished.

>I've fscked about 30GB worth of reiser, not full, and it took a while
>(probably about 30 minutes; I wasn't timing). So 2 hours or more for a
>complete tree scan would be about right.

Actually a filesystem on a ITE8212 PATA RAID using 4*80GB;
mirrored+striped, so I expected it to be quite a bit faster.

Well it finished the fix-fixable a few minutes after posting.
Just two minor problems - wrong block count and of course bitmap.
I resized the filesystem online... just because I could.

>I ran into some wonderful problems with reiser - what was happening
>was that the filesystem was corrupted in such a way as to hard-lockup
>the machine randomly. The machine (a VPS in this case) wouldn't do

Did you report the bug and collect your reward?

I've not had unfixable errors except on bad discs. In one case, the
system would roll back hours of stuff after crashing... the hard
drive didn't report that it had a problem writing to some blocks so
when the crash happened, everything got rolled back.

>anything - keyboard wasn't even working. fscking succeeded happily
>without resolving anything. I ended up creating another partition
>(thankyou LVM) the same size, formatting with ext3 and copying the
>data across.

I suspect that Reiserfs was "over-stressing" some part of the
system; possibly causing an interrupt to be missed and resulting in
a lock-up. Partly a driver, partly a filesystem and partly a
hardware issue. The filesystem is a victim to the lies it's told.
-- 
/"\ Bernd Felsche - Innovative Reckoning, Perth, Western Australia
\ /  ASCII ribbon campaign | "Laws do not persuade just because
 X   against HTML mail     |  they threaten."
/ \  and postings          | Lucius Annaeus Seneca, c. 4BC - 65AD.