All of lore.kernel.org
 help / color / mirror / Atom feed
* 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.