From: Brad Campbell <lists2009@fnarfbargle.com>
To: Phil Turmel <philip@turmel.org>,
Wols Lists <antlists@youngman.org.uk>,
Martin Bosner <martin@bosner.de>
Cc: linux-raid@vger.kernel.org
Subject: Re: assistance recovering failed raid6 array
Date: Tue, 21 Feb 2017 10:03:26 +0800 [thread overview]
Message-ID: <d5d8d99c-b5ed-e395-da02-f9cc4681edcd@fnarfbargle.com> (raw)
In-Reply-To: <6286c879-2c58-ee43-86fb-22e83c1964c4@turmel.org>
On 21/02/17 05:21, Phil Turmel wrote:
> On 02/20/2017 03:45 PM, Wols Lists wrote:
>
>> But there's a request on the linux wiki program for someone to write a
>> utility program that takes a ddrescue log and flags the duff sectors as
>> "soft unreadable". That would mean that if you can recover 35 drives,
>> provided no stripe has lost two sectors across two drives, you wouldn't
>> lose any data.
>>
>> If you want to try and write that utility? Or if you want to email me a
>> ddrescue log with a bunch of failed sectors, I'll have a go at writing
>> it myself :-)
>
> Check out hdparm --make-bad-sector. You can get what you are describing
> by scripting that. It's marked very dangerous, but I guess if one has
> nothing to lose....
>
Wol and I have tic-tacced on that a couple of times. He suggested the
idea and I proved the viability of it by testing hdparm in a RAID to do
exactly that. Neither of us has had a chance to stitch it all together,
but the preliminary tests indicate that would do *exactly* what was
required.
Given the hdparm commands are completely reversible and non-permanent,
*and* they are being executed on a destination of a ddrescue, there is
pretty much no risk (as long as the underlying glue code to be written
gets the sector numbers and offsets right).
Regards,
Brad
next prev parent reply other threads:[~2017-02-21 2:03 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-02-20 1:49 assistance recovering failed raid6 array Martin Bosner
2017-02-20 15:39 ` Phil Turmel
[not found] ` <E18A7C79-09E0-4361-9F89-68AE1E6FCBF6@bosner.de>
2017-02-20 17:36 ` Phil Turmel
2017-02-20 17:48 ` Martin Bosner
2017-02-20 18:11 ` Phil Turmel
2017-02-20 18:27 ` Martin Bosner
2017-02-20 19:01 ` Wols Lists
2017-02-20 19:11 ` Martin Bosner
2017-02-20 19:16 ` Phil Turmel
2017-02-20 19:31 ` Martin Bosner
2017-02-20 21:30 ` Phil Turmel
2017-02-20 20:45 ` Wols Lists
2017-02-20 21:21 ` Phil Turmel
2017-02-21 2:03 ` Brad Campbell [this message]
2017-02-20 17:50 ` Roman Mamedov
2017-02-20 18:13 ` Martin Bosner
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=d5d8d99c-b5ed-e395-da02-f9cc4681edcd@fnarfbargle.com \
--to=lists2009@fnarfbargle.com \
--cc=antlists@youngman.org.uk \
--cc=linux-raid@vger.kernel.org \
--cc=martin@bosner.de \
--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.