All of lore.kernel.org
 help / color / mirror / Atom feed
* RE: reiserfsck --rebuild-tree is very slow
@ 2002-08-08 21:08 berthiaume_wayne
  2002-08-08 21:34 ` Hans Reiser
  0 siblings, 1 reply; 6+ messages in thread
From: berthiaume_wayne @ 2002-08-08 21:08 UTC (permalink / raw)
  To: green, pawal; +Cc: reiserfs-list

	You may want to check with hdparm -d /dev/hd<x> to see if the drive
has dropped out of DMA into PIO. When IDE detects an error it will step back
and retry in PIO, afterwards it remains in PIO. In 2.4.19 there is a kernel
config parameter to set IDE to always DMA so you don't get this type of
system degradation.
Wayne.
-----Original Message-----
From: Oleg Drokin [mailto:green@namesys.com]
Sent: Monday, August 05, 2002 3:43 AM
To: Patrik Wallstrom
Cc: reiserfs-list@namesys.com
Subject: Re: [reiserfs-list] reiserfsck --rebuild-tree is very slow


Hello!

On Mon, Aug 05, 2002 at 09:37:52AM +0200, Patrik Wallstrom wrote:
> > > The result of reiserfsck --check and the result with --fix-fixable:
> > > bread: Cannot read a block # 10052279.
> > Hm, what's in kernel logs, is it filled with I/O errors?
> Aug  5 06:34:13 motor kernel: hdd: lost interrupt
> Aug  5 06:34:53 motor last message repeated 4 times
> Aug  5 06:35:53 motor last message repeated 6 times

Hm, this is a problem of IDE layer then

> > > From what I can see, this session can last for many years...
> > > Any advise?
> > Look into the kernel logs, if it is filled by many I/O error messages, 
> > then it will indeed may atek a lot of time. Also it is possible that the
> > drive itself is reading data very slowly (ie it encounters multiple
errors
> > that it tries to correct and this takes huge amount of time, I saw such
> > behaviour with IBM DTLA drives).
> > If you can access data on the drive just fine without fsck
> > (I mean if dd if=/dev/device of=/dev/zero bs=4096k works as fast as
expected),
> > then this may need more investigations.
> The read operation from dd was very fast.

You mean right now if you interrupt reiserfsck and issue a dd command, it
will be fast (ie. you tried it right now), or it was fast some time ago?

How aboult changing blocksize from 4M down to 4k?

> Should I just try --rebuild-tree, and wait for some weeks? :)

No, you should fix a problem in your IDE subsystem instead.

> The error from --check was now
> Bad root block 4294967295. (--rebuild-tree did not complete)

Yes, this is correct message for unfinished rebuild tree.

> So I guess I have to...

As an alternative thing: you can copy your partition to file, run fsck
on that file and then dd the file back, but this way the problem you
are having won't be fixed. And we have nothing to do with the problem so
we cannot help here (err, we can help probably but since that's not reiserfs
bug, such a help won't be free).

Bye,
    Oleg

^ permalink raw reply	[flat|nested] 6+ messages in thread
* reiserfsck --rebuild-tree is very slow
@ 2002-08-04 21:21 Patrik Wallstrom
  2002-08-05  5:04 ` Oleg Drokin
  0 siblings, 1 reply; 6+ messages in thread
From: Patrik Wallstrom @ 2002-08-04 21:21 UTC (permalink / raw)
  To: reiserfs-list

Hi,
I've been running "reiserfsck --rebuild-tree /dev/hdd" for 24h now on
a 40Gb drive that is 99% full. I am using reiserfsprogs 3.6.2 from
Debian unstable.

The result of reiserfsck --check and the result with --fix-fixable:
bread: Cannot read a block # 10052279.

The --rebuild-sb seemed successful:

Did you use resiser(y/n)[n]:
rebuild-sb: wrong block count occured (10052280), fixed (6193026)
rebuild-sb: wrong bitmap number occured (307), fixed (189)
rebuild-sb: no uuid found, a new uuid generated
(c30996b1-8a54-45db-8407-102bc973b42b)
rebuild-sb: wrong journal max transaction length occured (0), fixed (1024)
rebuild-sb: wrong journal max batch size occured (0), fixed (900)
rebuild-sb: wrong journal  max commit age occured (0), fixed (30)
Reiserfs super block in block 16 on 0x1640 of format 3.6 with standard
journal
Count of blocks on the device: 6193026
Number of bitmaps: 189
Blocksize: 4096
Free blocks (count of blocks - used [journal, bitmaps, data, reserved]
blocks): 82842
Root block: 8384
Filesystem is cleanly umounted
Tree height: 4
Hash function used to sort names: "r5"
Objectid map size 20, max 972
Journal parameters:
	Device [0x0]
	Magic [0x0]
	Size 8193 blocks (including 1 for journal header) (first block 18)
	Max transaction length 1024 blocks
	Max batch size 900 blocks
	Max commit age 30
Blocks reserved by journal: 0
Fs state field: 0x1
sb_version: 2
inode generation number: 4240
UUID: c30996b1-8a54-45db-8407-102bc973b42b
LABEL:
Set flags in SB:

Is this ok ? (y/n)[n]: y

Do not forget to run reiserfsck --rebuild-tree


Here's my results so far from the --rebuild-tree session:

Replaying journal..
No transactions found
###########
reiserfsck --rebuild-tree started at Sat Aug  3 22:07:31 2002
###########

Pass 0:
####### Pass 0 #######
Loading on-disk bitmap .. ok, 6110187 blocks marked used
Skipping 8399 blocks (super block, journal, bitmaps) 6101788 blocks
will be read
0%                                                         left 5911812, 2 /sec

From what I can see, this session can last for many years...

Any advise?

-- 
patrik_wallstrom->foodfight->pawal@blipp.com->+46-709580442

^ permalink raw reply	[flat|nested] 6+ messages in thread
end of thread, other threads:[~2002-08-08 21:34 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2002-08-08 21:08 reiserfsck --rebuild-tree is very slow berthiaume_wayne
2002-08-08 21:34 ` Hans Reiser
  -- strict thread matches above, loose matches on Subject: below --
2002-08-04 21:21 Patrik Wallstrom
2002-08-05  5:04 ` Oleg Drokin
2002-08-05  7:37   ` Patrik Wallstrom
2002-08-05  7:42     ` Oleg Drokin

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.