* reiserfsck (3.6.19) --rebuild-tree failed
@ 2006-09-08 9:51 grossnik.mailinglists
2006-09-08 10:05 ` Vladimir V. Saveliev
0 siblings, 1 reply; 7+ messages in thread
From: grossnik.mailinglists @ 2006-09-08 9:51 UTC (permalink / raw)
To: reiserfs-list
Dear all
I did a big mistake:
- I got bad blocks on my home partition
- I created a badblock file using:
badblocks -b 4096 -s -v -o /root/hda3.bad /de/hda3
- I tried to use reiserfstune to apply bad blocks:
reisefstune -B /root/hda3.bad /dev/hda3
- The tool said I have to use reiserfsck =>
$ reiserfsck --rebuild-tree --badblocks /root/hda3.bad /dev/hda3
Then I provides "Yes"
after 25% the --rebuild-tree stopped saing that there were bad blocks and that I've to provide the -B option and a badblock file.
But this is what I did (using --badblocks /root/hda3.bad).
Now /dev/hda3 can't be mounted (rood inode is set to -1).
I would be VERY happy if I could mount the partition read only!
What can I do?
Many Thx in advance
Bruno
Kernel is 2.6.15 (Debian)
reiserfsck -V => 3.6.19
debugreiserfs /dev/hda3:
Filesystem state: consistent
/home: Reiserfs super block in block 16 on 0x303 of format 3.6 with standard journal
Count of blocks on the device: 4883760
Number of bitmaps: 150
Blocksize: 4096
Free blocks (count of blocks - used [journal, bitmaps, data, reserved] blocks): 4883760
Root block: 0
Filesystem is clean
Tree height: 65535
Hash function used to sort names: "r5"
Objectid map size 614, max 972
Journal parameters:
Device [0x0]
Magic [0x78b2a94e]
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: 0x0:
sb_version: 2
inode generation number: 500386
UUID: f4fcb46d-04da-43c9-918d-2ef00f8d8412
LABEL: /home
Set flags in SB:
ATTRIBUTES CLEAN
cat /root/hda3.bad
4602176
4602179
4602180
4602181
4602182
4602183
4602185
4602186
4602187
4602188
4602189
4602190
4602191
4602193
4602194
4602195
4602196
4602197
4602198
4602199
4602201
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: reiserfsck (3.6.19) --rebuild-tree failed
2006-09-08 9:51 grossnik.mailinglists
@ 2006-09-08 10:05 ` Vladimir V. Saveliev
0 siblings, 0 replies; 7+ messages in thread
From: Vladimir V. Saveliev @ 2006-09-08 10:05 UTC (permalink / raw)
To: grossnik.mailinglists; +Cc: reiserfs-list
Hello
On Friday 08 September 2006 13:51, grossnik.mailinglists@hispeed.ch wrote:
> Dear all
> I did a big mistake:
> - I got bad blocks on my home partition
> - I created a badblock file using:
> badblocks -b 4096 -s -v -o /root/hda3.bad /de/hda3
> - I tried to use reiserfstune to apply bad blocks:
> reisefstune -B /root/hda3.bad /dev/hda3
> - The tool said I have to use reiserfsck =>
>
> $ reiserfsck --rebuild-tree --badblocks /root/hda3.bad /dev/hda3
>
> Then I provides "Yes"
>
> after 25% the --rebuild-tree stopped saing that there were bad blocks and
> that I've to provide the -B option and a badblock file.
>
> But this is what I did (using --badblocks /root/hda3.bad).
>
> Now /dev/hda3 can't be mounted (rood inode is set to -1).
>
> I would be VERY happy if I could mount the partition read only!
>
> What can I do?
>
> Many Thx in advance
>
> Bruno
>
> Kernel is 2.6.15 (Debian)
> reiserfsck -V => 3.6.19
>
> debugreiserfs /dev/hda3:
> Filesystem state: consistent
>
> /home: Reiserfs super block in block 16 on 0x303 of format 3.6 with
> standard journal Count of blocks on the device: 4883760
> Number of bitmaps: 150
> Blocksize: 4096
> Free blocks (count of blocks - used [journal, bitmaps, data, reserved]
> blocks): 4883760 Root block: 0
> Filesystem is clean
> Tree height: 65535
> Hash function used to sort names: "r5"
> Objectid map size 614, max 972
> Journal parameters:
> Device [0x0]
> Magic [0x78b2a94e]
> 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: 0x0:
> sb_version: 2
> inode generation number: 500386
> UUID: f4fcb46d-04da-43c9-918d-2ef00f8d8412
> LABEL: /home
> Set flags in SB:
> ATTRIBUTES CLEAN
>
>
>
> cat /root/hda3.bad
> 4602176
> 4602179
> 4602180
> 4602181
> 4602182
> 4602183
> 4602185
> 4602186
> 4602187
> 4602188
> 4602189
> 4602190
> 4602191
> 4602193
> 4602194
> 4602195
> 4602196
> 4602197
> 4602198
> 4602199
> 4602201
please run
for i in `cat /root/hda3.bad`; do debugreiserfs -1 $i /dev/hda3 > /dev/null;
done
and let me see the output
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: reiserfsck (3.6.19) --rebuild-tree failed
2006-09-08 10:51 Re: reiserfsck (3.6.19) --rebuild-tree failed grossnik.mailinglists
@ 2006-09-08 10:48 ` Vladimir V. Saveliev
0 siblings, 0 replies; 7+ messages in thread
From: Vladimir V. Saveliev @ 2006-09-08 10:48 UTC (permalink / raw)
To: grossnik.mailinglists; +Cc: reiserfs-list
Hello
On Friday 08 September 2006 14:51, grossnik.mailinglists@hispeed.ch wrote:
> Hi Vladimir
>
> >please run
> >for i in `cat /root/hda3.bad`; do debugreiserfs -1 $i /dev/hda3 >
> > /dev/null; done
>
> So many Thx for very fast response.
> Here's the output:
>
>
> debugreiserfs 3.6.19 (2003 www.namesys.com)
>
> 4602176 is used in ondisk bitmap
> debugreiserfs 3.6.19 (2003 www.namesys.com)
>
> 4602179 is used in ondisk bitmap
> debugreiserfs 3.6.19 (2003 www.namesys.com)
>
> 4602180 is used in ondisk bitmap
> debugreiserfs 3.6.19 (2003 www.namesys.com)
>
> 4602181 is used in ondisk bitmap
> debugreiserfs 3.6.19 (2003 www.namesys.com)
>
> 4602182 is used in ondisk bitmap
> debugreiserfs 3.6.19 (2003 www.namesys.com)
>
> 4602183 is used in ondisk bitmap
> debugreiserfs 3.6.19 (2003 www.namesys.com)
>
> 4602185 is used in ondisk bitmap
> debugreiserfs 3.6.19 (2003 www.namesys.com)
>
> 4602186 is used in ondisk bitmap
> debugreiserfs 3.6.19 (2003 www.namesys.com)
>
> 4602187 is used in ondisk bitmap
> debugreiserfs 3.6.19 (2003 www.namesys.com)
>
> 4602188 is used in ondisk bitmap
> debugreiserfs 3.6.19 (2003 www.namesys.com)
>
> 4602189 is used in ondisk bitmap
> debugreiserfs 3.6.19 (2003 www.namesys.com)
>
> 4602190 is used in ondisk bitmap
> debugreiserfs 3.6.19 (2003 www.namesys.com)
>
> 4602191 is used in ondisk bitmap
> debugreiserfs 3.6.19 (2003 www.namesys.com)
>
> 4602193 is used in ondisk bitmap
> debugreiserfs 3.6.19 (2003 www.namesys.com)
>
> 4602194 is used in ondisk bitmap
> debugreiserfs 3.6.19 (2003 www.namesys.com)
>
> 4602195 is used in ondisk bitmap
> debugreiserfs 3.6.19 (2003 www.namesys.com)
>
> 4602196 is used in ondisk bitmap
> debugreiserfs 3.6.19 (2003 www.namesys.com)
>
> 4602197 is used in ondisk bitmap
> debugreiserfs 3.6.19 (2003 www.namesys.com)
>
> 4602198 is used in ondisk bitmap
> debugreiserfs 3.6.19 (2003 www.namesys.com)
>
> 4602199 is used in ondisk bitmap
> debugreiserfs 3.6.19 (2003 www.namesys.com)
>
> 4602201 is used in ondisk bitmap
>
ok, all bad blocks are used. Lets try to find what they are used for:
get ftp://ftp.namesys.com/pub/tmp/reiserfsprogs-3.6.19.3.tar.gz
and run its debugreiserfs:
cat /root/hda3.bad | debugreiserfs -x /dev/hda3
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Re: reiserfsck (3.6.19) --rebuild-tree failed
@ 2006-09-08 10:51 grossnik.mailinglists
2006-09-08 10:48 ` Vladimir V. Saveliev
0 siblings, 1 reply; 7+ messages in thread
From: grossnik.mailinglists @ 2006-09-08 10:51 UTC (permalink / raw)
To: vs; +Cc: reiserfs-list
Hi Vladimir
>please run
>for i in `cat /root/hda3.bad`; do debugreiserfs -1 $i /dev/hda3 > /dev/null;
>done
So many Thx for very fast response.
Here's the output:
debugreiserfs 3.6.19 (2003 www.namesys.com)
4602176 is used in ondisk bitmap
debugreiserfs 3.6.19 (2003 www.namesys.com)
4602179 is used in ondisk bitmap
debugreiserfs 3.6.19 (2003 www.namesys.com)
4602180 is used in ondisk bitmap
debugreiserfs 3.6.19 (2003 www.namesys.com)
4602181 is used in ondisk bitmap
debugreiserfs 3.6.19 (2003 www.namesys.com)
4602182 is used in ondisk bitmap
debugreiserfs 3.6.19 (2003 www.namesys.com)
4602183 is used in ondisk bitmap
debugreiserfs 3.6.19 (2003 www.namesys.com)
4602185 is used in ondisk bitmap
debugreiserfs 3.6.19 (2003 www.namesys.com)
4602186 is used in ondisk bitmap
debugreiserfs 3.6.19 (2003 www.namesys.com)
4602187 is used in ondisk bitmap
debugreiserfs 3.6.19 (2003 www.namesys.com)
4602188 is used in ondisk bitmap
debugreiserfs 3.6.19 (2003 www.namesys.com)
4602189 is used in ondisk bitmap
debugreiserfs 3.6.19 (2003 www.namesys.com)
4602190 is used in ondisk bitmap
debugreiserfs 3.6.19 (2003 www.namesys.com)
4602191 is used in ondisk bitmap
debugreiserfs 3.6.19 (2003 www.namesys.com)
4602193 is used in ondisk bitmap
debugreiserfs 3.6.19 (2003 www.namesys.com)
4602194 is used in ondisk bitmap
debugreiserfs 3.6.19 (2003 www.namesys.com)
4602195 is used in ondisk bitmap
debugreiserfs 3.6.19 (2003 www.namesys.com)
4602196 is used in ondisk bitmap
debugreiserfs 3.6.19 (2003 www.namesys.com)
4602197 is used in ondisk bitmap
debugreiserfs 3.6.19 (2003 www.namesys.com)
4602198 is used in ondisk bitmap
debugreiserfs 3.6.19 (2003 www.namesys.com)
4602199 is used in ondisk bitmap
debugreiserfs 3.6.19 (2003 www.namesys.com)
4602201 is used in ondisk bitmap
-----------------------------------------------
syslog:
...
Sep 8 12:46:12 kim kernel: hda: dma_intr: status=0x59 { DriveReady SeekComplete DataRequest Error }
Sep 8 12:46:12 kim kernel: hda: dma_intr: error=0x40 { UncorrectableError }, LBAsect=114941706, high=6, low=14278410, sector=114941703
Sep 8 12:46:12 kim kernel: ide: failed opcode was: unknown
Sep 8 12:46:12 kim kernel: end_request: I/O error, dev hda, sector 114941703
Sep 8 12:46:12 kim kernel: Buffer I/O error on device hda3, logical block 4602201
Sep 8 12:46:13 kim kernel: hda: dma_intr: status=0x59 { DriveReady SeekComplete DataRequest Error }
Sep 8 12:46:13 kim kernel: hda: dma_intr: error=0x40 { UncorrectableError }, LBAsect=114941706, high=6, low=14278410, sector=114941703
Sep 8 12:46:13 kim kernel: ide: failed opcode was: unknown
Sep 8 12:46:13 kim kernel: end_request: I/O error, dev hda, sector 114941703
Sep 8 12:46:13 kim kernel: Buffer I/O error on device hda3, logical block 4602201
Kind Regards
Bruno
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: reiserfsck (3.6.19) --rebuild-tree failed
2006-09-08 11:30 grossnik.mailinglists
@ 2006-09-08 11:22 ` Vladimir V. Saveliev
0 siblings, 0 replies; 7+ messages in thread
From: Vladimir V. Saveliev @ 2006-09-08 11:22 UTC (permalink / raw)
To: grossnik.mailinglists; +Cc: reiserfs-list
Hello
On Friday 08 September 2006 15:30, grossnik.mailinglists@hispeed.ch wrote:
> Hi Vladimir
>
> >ok, all bad blocks are used. Lets try to find what they are used for:
> >cat /root/hda3.bad | debugreiserfs -x /dev/hda3
>
> # cat /root/hda3.bad | ./debugreiserfs -x /dev/hda3 > /root/tmp.txt 2>&1
> =>
>
> debugreiserfs 3.6.19.3 (2003 www.namesys.com)
>
> list of 21 block numbers is read
> /0
ah, sorry, I forgot that you ran reiserfsck --rebuild-tree and that did not
complete. debureiserfs -x will not help.
I will try to reproduce your problem here and debug it.
Btw, did reiserfstune say you something like the below?
reiserfstune -B list2 /dev/hda2
reiserfstune: Bad block 32793 is used already in reiserfs tree. To mark it as
a bad block use reiserfsck
--fix-fixable with -B option.
> block #0 has wrong level 0, has to be 65534
> Number of unresolved block numbers: 21
>
>
>
> Kind Regards
> Bruno
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: reiserfsck (3.6.19) --rebuild-tree failed
2006-09-08 12:04 grossnik.mailinglists
@ 2006-09-08 12:48 ` Vladimir V. Saveliev
0 siblings, 0 replies; 7+ messages in thread
From: Vladimir V. Saveliev @ 2006-09-08 12:48 UTC (permalink / raw)
To: grossnik.mailinglists; +Cc: reiserfs-list
Hello
On Friday 08 September 2006 16:04, grossnik.mailinglists@hispeed.ch wrote:
> Vladimir
>
> >Btw, did reiserfstune say you something like the below?
> >
> >reiserfstune -B list2 /dev/hda2
> >reiserfstune: Bad block 32793 is used already in reiserfs tree. To mark it
> > as a bad block use reiserfsck
> >--fix-fixable with -B option.
>
> Yes. exactly.
> Then I did:
> reiserfsck --rebuild-tree --badblocks /root/hda3.bad /dev/hda3
>
> after 25% the --rebuild-tree stopped saing that there were bad blocks and
> that I've to provide the -B option and a badblock file. (I thought that -B
> and --badblocks were the same?)
yes
>
> I did not use the --fix-fixable option.
>
please run
reiserfsck (3.6.19.3) --rebuild-tree --badblocks /root/hda3.bad /dev/hda3
once again and let me see whole output of the command.
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: reiserfsck (3.6.19) --rebuild-tree failed
2006-09-08 14:42 grossnik.mailinglists
@ 2006-09-09 15:25 ` Michael Weissenbacher
0 siblings, 0 replies; 7+ messages in thread
From: Michael Weissenbacher @ 2006-09-09 15:25 UTC (permalink / raw)
To: grossnik.mailinglists; +Cc: vs, reiserfs-list
Hi,
> I'm 100% happy. Now it did not stop.
> Either it would haven been nessesary to run it twice or the new
version I've got from did the trick.
Good to hear that!
> I thank you so much!
> Now I go any buy a new disk!!!
Usually when a disk goes bad you should get a new disk FIRST, then make
an image from the old disk with dd_rescue and then use fsck. It is much
safer this way and you don't have to fiddle around with the badblock
options at all.
Useful links:
[1] http://www.garloff.de/kurt/linux/ddrescue/
[2] http://www.knopper.net/knoppix/
[3] http://www.extremetech.com/article2/0,1697,1928206,00.asp
kind regards,
Michael
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2006-09-09 15:25 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2006-09-08 10:51 Re: reiserfsck (3.6.19) --rebuild-tree failed grossnik.mailinglists
2006-09-08 10:48 ` Vladimir V. Saveliev
-- strict thread matches above, loose matches on Subject: below --
2006-09-08 14:42 grossnik.mailinglists
2006-09-09 15:25 ` Michael Weissenbacher
2006-09-08 12:04 grossnik.mailinglists
2006-09-08 12:48 ` Vladimir V. Saveliev
2006-09-08 11:30 grossnik.mailinglists
2006-09-08 11:22 ` Vladimir V. Saveliev
2006-09-08 9:51 grossnik.mailinglists
2006-09-08 10:05 ` Vladimir V. Saveliev
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.