From: Patrik Wallstrom <pawal@blipp.com>
To: reiserfs-list@namesys.com
Subject: reiserfsck --rebuild-tree is very slow
Date: Sun, 4 Aug 2002 23:21:48 +0200 [thread overview]
Message-ID: <20020804212148.GC6570@vic20.blipp.com> (raw)
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
next reply other threads:[~2002-08-04 21:21 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-08-04 21:21 Patrik Wallstrom [this message]
2002-08-05 5:04 ` reiserfsck --rebuild-tree is very slow Oleg Drokin
2002-08-05 7:37 ` Patrik Wallstrom
2002-08-05 7:42 ` Oleg Drokin
-- strict thread matches above, loose matches on Subject: below --
2002-08-08 21:08 berthiaume_wayne
2002-08-08 21:34 ` Hans Reiser
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20020804212148.GC6570@vic20.blipp.com \
--to=pawal@blipp.com \
--cc=reiserfs-list@namesys.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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.