From: Andreas Klauer <Andreas.Klauer@metamorpher.de>
To: Phil Turmel <philip@turmel.org>
Cc: Wols Lists <antlists@youngman.org.uk>,
Peter Gebhard <pgeb@seas.upenn.edu>,
Linux-RAID <linux-raid@vger.kernel.org>,
Another Sillyname <anothersname@googlemail.com>,
John Stoffel <john@stoffel.org>
Subject: Re: Recommendations needed for RAID5 recovery
Date: Mon, 27 Jun 2016 11:06:45 +0200 [thread overview]
Message-ID: <20160627090645.GA3255@metamorpher.de> (raw)
In-Reply-To: <5770549C.4060301@turmel.org>
On Sun, Jun 26, 2016 at 06:18:04PM -0400, Phil Turmel wrote:
> I don't know *any* scenario where dd is useful for raid recovery.
Basically you use dd to make a copy to play around with but
with overlays (as described in the RAID wiki) you don't need
those copies anymore. [as long as the device is intact]
There is conv=noerror,sync however I found recently that it
actually produces corrupt copies (changes offsets), still not
sure what the conv=noerror,sync is actually supposed to be for.
( http://superuser.com/a/1075837/195171 )
So you shouldn't use dd on bad disks...
I've had my fair share of issues with ddrescue as well, it likes
to get stuck forever and not continue. --min-read-rate=<bytes>
might help in such a case... (better to copy regions that still
work quickly rather than spending hours on error correction ...).
ddrescue produces a log (or a map) that records bad regions,
so if you somehow need a device that still produces read errors
for those, it can probably be magicked with the device mapper...
Regards
Andreas Klauer
next prev parent reply other threads:[~2016-06-27 9:06 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-06-24 19:55 Recommendations needed for RAID5 recovery Peter Gebhard
2016-06-24 20:44 ` Another Sillyname
2016-06-24 21:37 ` John Stoffel
2016-06-25 11:43 ` Wols Lists
2016-06-25 16:49 ` Phil Turmel
2016-06-26 21:12 ` Wols Lists
2016-06-26 22:18 ` Phil Turmel
2016-06-27 9:06 ` Andreas Klauer [this message]
2016-06-27 10:05 ` Mikael Abrahamsson
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=20160627090645.GA3255@metamorpher.de \
--to=andreas.klauer@metamorpher.de \
--cc=anothersname@googlemail.com \
--cc=antlists@youngman.org.uk \
--cc=john@stoffel.org \
--cc=linux-raid@vger.kernel.org \
--cc=pgeb@seas.upenn.edu \
--cc=philip@turmel.org \
/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.