Contribution

Contribution

[Chris Hiszpanski]

[-- Attachment #1: Type: text/plain, Size: 2389 bytes --]

Hi,

Recently, I ran a --rebuild-tree on a reiserfs partition in an attempt to
restore several files that I had accidentally deleted. Due to my own stupidity
I did not back up my files on the partition before doing this (!).

What can go wrong did, and --rebuild-tree stopped at the first bad block,
leaving an unmountable /home partition.

I ran badblocks on the partition and passed this to reiserfsck. Some of the
bad blocks were journal superblocks, and reiserfsck gave up at this point. Web
documentation suggested running a dd_rescue. Since I was working on a remote
machine and had no extra drives available this wasn't an open option.

I noticed that writing to the badblocks should cause the hard disk to remap the
blocks, making reiserfsck happy, though losing data (turned out that apparently
not much data was stored in these blocks, and this data was inaccessible
anyway, so not a big loss :).

The non-destructive write (i.e. badblocks -n ...) didn't remap the blocks. Only
the destructive writes (i.e. badblocks -w) did. Therefore, I modified the
lib/io.c code with a pretty trivial update that others in this situation may
find useful.

The contribution adds two options as #define in lib/io.c, NOSUPERDIE and NODIE.
When NOSUPERDIE is 1, the bread function calls badblocks -w to destructively
write the bad block, hopefully remapping it (since the remapped block is
meaningless data, I didn't worry about having bh point to meaningful data).
When NOSUPERDIE is 0, but NODIE is 1, the bread function returns a 0, acting
as if the block was in the bad blocks list, avoiding the need for running
bad blocks separately. When both NOSUPERDIE and NODIE are 0, the code compiles
unaltered.

The point of this contribution is to prevent reiserfsck from dieing on bad
blocks, to get it to finish, so that the file system, what's left of it, can
be mounted.

The results that I received were pretty good. I was able to recover most of
my files, and the file system appears to be in tact. Can anyone tell me how
in tact is actually is? I'm not exactly sure what was destroyed when I remapped
the journal superblocks.

I'd appreciate some feedback on this hack, any problems with it especially.

Hopefully the community finds this useful.

Cheers,
Chris

(attached reiserfsprogs-3.6.19-hiszpans.tar.gz)
(http://www.its.caltech.edu/~hiszpans/pub/reiserfsprogs-3.6.19-hiszpans.tar.gz)


[-- Attachment #2: reiserfsprogs-3.6.19-hiszpans.tar.gz --]
[-- Type: application/x-tar-gz, Size: 7818 bytes --]

flush file system

[John Sconiers]

Is there a reiserfs command to flush the pending wriets to the file system?
JOHN

Re: flush file system

[Simon Raffeiner]

[-- Attachment #1: Type: text/plain, Size: 215 bytes --]

Should be "sync" on Linux, regardless of the underlying file system.

Am Samstag, 26. März 2005 15:17 schrieb John Sconiers:
> Is there a reiserfs command to flush the pending wriets to the file system?
> JOHN

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: Contribution

[Hans Reiser]

Suggestion: If you want casual people to actually read code, you need to
send it as uncompressed patches.  Vitaly, please look at this.

I think we would only want to use the algorithm you describe below after
extensively warning the user that they should instead first copy it to a
working hard drive, and warning them that if fsck does not have a good
hard drive under it can make things far worse rather than better, and
having them rerun with the option
--continue-to-trust-my-data-to-failing-hardware

Thanks for the contribution, it sounds useful.

Hans

Chris Hiszpanski wrote:

>Hi,
>
>Recently, I ran a --rebuild-tree on a reiserfs partition in an attempt to
>restore several files that I had accidentally deleted. Due to my own stupidity
>I did not back up my files on the partition before doing this (!).
>
>What can go wrong did, and --rebuild-tree stopped at the first bad block,
>leaving an unmountable /home partition.
>
>I ran badblocks on the partition and passed this to reiserfsck. Some of the
>bad blocks were journal superblocks, and reiserfsck gave up at this point. Web
>documentation suggested running a dd_rescue. Since I was working on a remote
>machine and had no extra drives available this wasn't an open option.
>
>I noticed that writing to the badblocks should cause the hard disk to remap the
>blocks, making reiserfsck happy, though losing data (turned out that apparently
>not much data was stored in these blocks, and this data was inaccessible
>anyway, so not a big loss :).
>
>The non-destructive write (i.e. badblocks -n ...) didn't remap the blocks. Only
>the destructive writes (i.e. badblocks -w) did. Therefore, I modified the
>lib/io.c code with a pretty trivial update that others in this situation may
>find useful.
>
>The contribution adds two options as #define in lib/io.c, NOSUPERDIE and NODIE.
>When NOSUPERDIE is 1, the bread function calls badblocks -w to destructively
>write the bad block, hopefully remapping it (since the remapped block is
>meaningless data, I didn't worry about having bh point to meaningful data).
>When NOSUPERDIE is 0, but NODIE is 1, the bread function returns a 0, acting
>as if the block was in the bad blocks list, avoiding the need for running
>bad blocks separately. When both NOSUPERDIE and NODIE are 0, the code compiles
>unaltered.
>
>The point of this contribution is to prevent reiserfsck from dieing on bad
>blocks, to get it to finish, so that the file system, what's left of it, can
>be mounted.
>
>The results that I received were pretty good. I was able to recover most of
>my files, and the file system appears to be in tact. Can anyone tell me how
>in tact is actually is? I'm not exactly sure what was destroyed when I remapped
>the journal superblocks.
>
>I'd appreciate some feedback on this hack, any problems with it especially.
>
>Hopefully the community finds this useful.
>
>Cheers,
>Chris
>
>(attached reiserfsprogs-3.6.19-hiszpans.tar.gz)
>(http://www.its.caltech.edu/~hiszpans/pub/reiserfsprogs-3.6.19-hiszpans.tar.gz)
>
>  
>