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

  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.