All of lore.kernel.org
 help / color / mirror / Atom feed
* Hard errors, trying to recover
@ 2004-06-29 19:39 Kristian Koehntopp
  2004-06-30 14:02 ` Vitaly Fertman
  0 siblings, 1 reply; 9+ messages in thread
From: Kristian Koehntopp @ 2004-06-29 19:39 UTC (permalink / raw)
  To: reiserfs-list


I have a 160 GB disk that has at least one hard read-error.

I tried reiserfsck'ing that disk, in order to salvage data on that disk by
copying it to a safe location one last time. Unfortunately, reiserfsck
--rebuild-tree runs into that read-error and stops, lecturing me on disk
quality (I knew that!). Now I cannot even mount that disk, because
reiserfsck zeroed root block 0 during the rebuild-tree.

I am at the moment dd'ing that disk with conv=noerrors, hoping that I will
get an image (which will be truncated by 4 GB, because my scratch disk is
somewhat smaller than the source disk). I tried to reiserfsck --rebuild-tree
the partial image, but I reiserfsck breaks down, because it is unable to
read the last block of the images (it is a partial image).

What can I do to salvage the data on my broken disk?

Kristian

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: Hard errors, trying to recover
  2004-06-29 19:39 Hard errors, trying to recover Kristian Koehntopp
@ 2004-06-30 14:02 ` Vitaly Fertman
  2004-06-30 14:45   ` Kristian Köhntopp
  0 siblings, 1 reply; 9+ messages in thread
From: Vitaly Fertman @ 2004-06-30 14:02 UTC (permalink / raw)
  To: Kristian Koehntopp, reiserfs-list

Hello,

On Tuesday 29 June 2004 23:39, Kristian Koehntopp wrote:
> I have a 160 GB disk that has at least one hard read-error.
>
> I tried reiserfsck'ing that disk, in order to salvage data on that disk by
> copying it to a safe location one last time. Unfortunately, reiserfsck
> --rebuild-tree runs into that read-error and stops, lecturing me on disk
> quality (I knew that!). Now I cannot even mount that disk, because
> reiserfsck zeroed root block 0 during the rebuild-tree.
>
> I am at the moment dd'ing that disk with conv=noerrors, hoping that I will
> get an image (which will be truncated by 4 GB, because my scratch disk is
> somewhat smaller than the source disk). I tried to reiserfsck
> --rebuild-tree the partial image, but I reiserfsck breaks down, because it
> is unable to read the last block of the images (it is a partial image).
>
> What can I do to salvage the data on my broken disk?

we deal with hardware problems only under www.namesys.com/support.html terms.

-- 
Thanks,
Vitaly Fertman


^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: Hard errors, trying to recover
  2004-06-30 14:02 ` Vitaly Fertman
@ 2004-06-30 14:45   ` Kristian Köhntopp
  2004-06-30 15:16     ` Carl-Daniel Hailfinger
  2004-06-30 15:59     ` Vitaly Fertman
  0 siblings, 2 replies; 9+ messages in thread
From: Kristian Köhntopp @ 2004-06-30 14:45 UTC (permalink / raw)
  To: Vitaly Fertman; +Cc: reiserfs-list

On Wednesday 30 June 2004 16:02, Vitaly Fertman wrote:
> we deal with hardware problems only under
> www.namesys.com/support.html terms.

I have the hardware problem well under control now, thank you.

My mail referred more to two observations I made in that process:

1. Unless reiserfsck --rebuild-tree succeeds and finishes, it 
does more harm than good, because the disk is unmountable if 
reiserfsck --rebuild-tree stops halfway.

reiserfsck --rebuild-tree seems to stop when it has discovered 
something it believes to be a hard read error.

That combination of behaviours is somewhat suboptimal and could 
be improved, I believe. I'd rather have reiserfsck to present me 
with a choice to assume the defect block as all zero and 
continue or stop here and try other things.

2. When I make an image of a disk, and that image is incomplete 
for whatever reason, I cannot reiserfsck that image because of 
seeks beyond the end of the medium. Again, I'd rather have the 
choice of reiserfsck trying to salvage the incomplete medium 
(assuming all zero data for all missing blocks) or stop with an 
error.

The combination of 1 and 2 has bitten me badly in trying to 
salvage a failing 160GB disk, because I tried reiserfsck 
--rebuild-tree before making an image.

It may also be a good idea in some cases to have a version of 
reiserfsck that fsck's the disk to a new medium, that is, 
reiserfsck reads as much as it can from the defect disk or a 
possibly incomplete image of such a disk, and tries to construct 
a useable image on a new replacement partition.


I was able to force a reiserfsck to finish using a combination of 
writes to the defect blocks in order to force reallocation and 
thermal stimulation of the dying disk (don't ask, you do not 
want to know :). The filesystem was mountable r/o after that. 
The final copy is still in progress, but 132 of 135 GB have 
already been saved.

Kristian

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: Hard errors, trying to recover
  2004-06-30 14:45   ` Kristian Köhntopp
@ 2004-06-30 15:16     ` Carl-Daniel Hailfinger
  2004-06-30 15:59     ` Vitaly Fertman
  1 sibling, 0 replies; 9+ messages in thread
From: Carl-Daniel Hailfinger @ 2004-06-30 15:16 UTC (permalink / raw)
  To: Kristian Köhntopp; +Cc: Vitaly Fertman, reiserfs-list

Kristian Köhntopp wrote:
> 
> 2. When I make an image of a disk, and that image is incomplete 
> for whatever reason, I cannot reiserfsck that image because of 
> seeks beyond the end of the medium. Again, I'd rather have the 
> choice of reiserfsck trying to salvage the incomplete medium 
> (assuming all zero data for all missing blocks) or stop with an 
> error.

That's why you should NOT use dd. dd is crap for data recovery. Use
dd_rescue instead. It will give you the options of writing zeroes instead
of aborting the copy, reading the disk backwards etc. And reiserfsck
should work perfectly with an image made by dd_rescue.

Carl-Daniel
-- 
http://www.hailfinger.org/

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: Hard errors, trying to recover
  2004-06-30 14:45   ` Kristian Köhntopp
  2004-06-30 15:16     ` Carl-Daniel Hailfinger
@ 2004-06-30 15:59     ` Vitaly Fertman
  2004-06-30 19:42       ` Kristian Köhntopp
  1 sibling, 1 reply; 9+ messages in thread
From: Vitaly Fertman @ 2004-06-30 15:59 UTC (permalink / raw)
  To: Kristian Köhntopp; +Cc: reiserfs-list

On Wednesday 30 June 2004 18:45, Kristian Köhntopp wrote:
> On Wednesday 30 June 2004 16:02, Vitaly Fertman wrote:
> > we deal with hardware problems only under
> > www.namesys.com/support.html terms.
>
> I have the hardware problem well under control now, thank you.
>
> My mail referred more to two observations I made in that process:
>
> 1. Unless reiserfsck --rebuild-tree succeeds and finishes, it
> does more harm than good, because the disk is unmountable if
> reiserfsck --rebuild-tree stops halfway.

no, this is protection exactly from mounting not repaired filesystems
as this may lead to futher severe fs corruptions.

> reiserfsck --rebuild-tree seems to stop when it has discovered
> something it believes to be a hard read error.
>
> That combination of behaviours is somewhat suboptimal and could
> be improved, I believe. I'd rather have reiserfsck to present me
> with a choice to assume the defect block as all zero and
> continue or stop here and try other things.

there could be different hardware problems and sometimes you should 
fix them before proceeding. bad blocks is one of these problems that
reiserfsck is able to deal with (www.namesys.com/bad-block-handling.html).

> 2. When I make an image of a disk, and that image is incomplete
> for whatever reason, I cannot reiserfsck that image because of
> seeks beyond the end of the medium. Again, I'd rather have the
> choice of reiserfsck trying to salvage the incomplete medium
> (assuming all zero data for all missing blocks) or stop with an
> error.

you probably used some old reiserfsprogs.

> The combination of 1 and 2 has bitten me badly in trying to
> salvage a failing 160GB disk, because I tried reiserfsck
> --rebuild-tree before making an image.
>
> It may also be a good idea in some cases to have a version of
> reiserfsck that fsck's the disk to a new medium, that is,
> reiserfsck reads as much as it can from the defect disk or a
> possibly incomplete image of such a disk, and tries to construct
> a useable image on a new replacement partition.
>
>
> I was able to force a reiserfsck to finish using a combination of
> writes to the defect blocks in order to force reallocation and
> thermal stimulation of the dying disk (don't ask, you do not
> want to know :). The filesystem was mountable r/o after that.
> The final copy is still in progress, but 132 of 135 GB have
> already been saved.
>
> Kristian

-- 
Thanks,
Vitaly Fertman


^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: Hard errors, trying to recover
  2004-06-30 15:59     ` Vitaly Fertman
@ 2004-06-30 19:42       ` Kristian Köhntopp
  2004-07-01  1:04         ` Redeeman
  0 siblings, 1 reply; 9+ messages in thread
From: Kristian Köhntopp @ 2004-06-30 19:42 UTC (permalink / raw)
  To: Vitaly Fertman; +Cc: reiserfs-list

On Wednesday 30 June 2004 17:59, Vitaly Fertman wrote:
> you probably used some old reiserfsprogs.

Suse Linux 9.0 with all patches, reiserfsck identifies itself as

white:~ # reiserfsck -V
reiserfsck 3.6.9 (2003 www.namesys.com)

Kristian

-- 
Jetzt auch: Kristian =?iso-8859-15?q?K=F6hntopp?= <kris@xn--khntopp-90a.de>

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: Hard errors, trying to recover
  2004-06-30 19:42       ` Kristian Köhntopp
@ 2004-07-01  1:04         ` Redeeman
  2004-07-01  6:23           ` Raymond A. Meijer
  0 siblings, 1 reply; 9+ messages in thread
From: Redeeman @ 2004-07-01  1:04 UTC (permalink / raw)
  To: Reiserfs Mailinglist

On Wed, 2004-06-30 at 21:42 +0200, Kristian Köhntopp wrote:
> On Wednesday 30 June 2004 17:59, Vitaly Fertman wrote:
> > you probably used some old reiserfsprogs.
> 
> Suse Linux 9.0 with all patches, reiserfsck identifies itself as
> 
> white:~ # reiserfsck -V
> reiserfsck 3.6.9 (2003 www.namesys.com)
which is also very old, as 2.6.17 exists
> 
> Kristian
> 
-- 
Redeeman <redeeman@metanurb.dk>


^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: Hard errors, trying to recover
  2004-07-01  1:04         ` Redeeman
@ 2004-07-01  6:23           ` Raymond A. Meijer
  2004-07-01 10:10             ` Dieter Nützel
  0 siblings, 1 reply; 9+ messages in thread
From: Raymond A. Meijer @ 2004-07-01  6:23 UTC (permalink / raw)
  To: reiserfs-list

On Thu 1 July 2004 04:04, Redeeman wrote:

> > white:~ # reiserfsck -V
> > reiserfsck 3.6.9 (2003 www.namesys.com)

> which is also very old, as 2.6.17 exists

That's even older ;)

The latest version is 3.6.17.


Ray

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: Hard errors, trying to recover
  2004-07-01  6:23           ` Raymond A. Meijer
@ 2004-07-01 10:10             ` Dieter Nützel
  0 siblings, 0 replies; 9+ messages in thread
From: Dieter Nützel @ 2004-07-01 10:10 UTC (permalink / raw)
  To: reiserfs-list; +Cc: Raymond A. Meijer, Kristian Köhntopp

Am Donnerstag, 1. Juli 2004 08:23 schrieb Raymond A. Meijer:
> On Thu 1 July 2004 04:04, Redeeman wrote:
> > > white:~ # reiserfsck -V
> > > reiserfsck 3.6.9 (2003 www.namesys.com)
> >
> > which is also very old, as 2.6.17 exists
>
> That's even older ;)
>
> The latest version is 3.6.17.

Yes, but "SuSE" do not increase the last level even if they have "all" fixes 
in...

Chris have a patched reiserfs-3.6.13-2 in his home for SuSE 9.0.

Greetings,
	Dieter

^ permalink raw reply	[flat|nested] 9+ messages in thread

end of thread, other threads:[~2004-07-01 10:10 UTC | newest]

Thread overview: 9+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2004-06-29 19:39 Hard errors, trying to recover Kristian Koehntopp
2004-06-30 14:02 ` Vitaly Fertman
2004-06-30 14:45   ` Kristian Köhntopp
2004-06-30 15:16     ` Carl-Daniel Hailfinger
2004-06-30 15:59     ` Vitaly Fertman
2004-06-30 19:42       ` Kristian Köhntopp
2004-07-01  1:04         ` Redeeman
2004-07-01  6:23           ` Raymond A. Meijer
2004-07-01 10:10             ` Dieter Nützel

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.