All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stefan *St0fF* Huebner <st0ff@gmx.net>
To: Keith Keller <kkeller@wombat.san-francisco.ca.us>
Cc: linux-raid@vger.kernel.org
Subject: Re: using dd (or dd_rescue) to salvage array
Date: Mon, 06 Feb 2012 22:37:38 +0100	[thread overview]
Message-ID: <4F304822.8000102@gmx.net> (raw)
In-Reply-To: <8q0309x4kf.ln2@goaway.wombat.san-francisco.ca.us>

On 05.02.2012 20:10, Keith Keller wrote:
> On 2012-02-04, Stefan /*St0fF*/ Hübner<stefan.huebner@stud.tu-ilmenau.de>  wrote:
>> actually, ddrescue is THE WAY TO GO in this case.  Don't use the old
>> ddrescue, but the GNU version.  Some distros call it gddrescue, on
>> gentoo the old one is called dd-rescue and the gnu-one ddrescue.  Just
>> check it out: http://www.gnu.org/software/ddrescue/ddrescue.html
> Thanks for the advice, Stefan.  Frustratingly enough, I will get a
> chance to try GNU ddrescue despite my impatience--I originally used
> dd_rescue to try to get an image of the failing drive, and while that
> succeeded just fine (only lost 8k), the target ended up reporting ECC
> errors during the rebuild!  So I've taken a new image with ddrescue
> to a tested drive (again, losing 8k), and am hoping that it goes better.
> (At the moment I'm just attempting a one-spare rebuild, which I'm hoping
> will go faster than a two-disk build, and therefore report any problems
> sooner.)
>
> I realized after reading my initial post that I wasn't 100% clear what I
> was asking.  I knew that some sort of dd would work, but I'd only done
> it before in a filesystem context, and didn't know how mdraid would
> react.  So I am curious, does anyone know what I might expect when the
> rebuild gets to the part on the new image where the data was lost?  Will
> it just create a problem on the filesystem, or might something worse
> happen?  Should I run a check if the rebuild completes successfully?
> And will mismatch_cnt get populated by the rebuild, or would I need a
> check to expose mismatches?
>
> --keith
>
 From the logical point of view those lost 8k would create bad data - 
i.e. a filesystem problem OR simply corrupted data.  That depends on 
which blocks exactly are bad.  If you were using lvm it could even be 
worse, like broken metadata.

It would be good if those 8k were "in a row" - that way at max 3 
fs-blocks (when using 4k fs-blocksize) would be corrupted.  If you're 
lucky, you won't even notice - like me: my system SSD broke down 
lately.  I ddrescued as much as I could, but around 250k are gone.  I'm 
dual-booting windows and gentoo and I have not yet encountered a problem 
from the missing data.  Lucky me...

Cheers,
Stefan
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

  reply	other threads:[~2012-02-06 21:37 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-02-07  1:34 Please Help! RAID5 -> 6 reshapre gone bad Richard Herd
2012-02-07  2:15 ` Phil Turmel
     [not found]   ` <CAOANJV955ZdLexRTjVkQzTMapAaMitq5eqxP0rUvDjjLh4Wgzw@mail.gmail.com>
2012-02-07  2:57     ` Phil Turmel
2012-02-07  3:10       ` Richard Herd
2012-02-07  3:24       ` Keith Keller
2012-01-31  6:31         ` rebuild raid6 after two failures Keith Keller
2012-02-01  4:42           ` Keith Keller
2012-02-01  5:31             ` NeilBrown
2012-02-01  5:48               ` Keith Keller
2012-02-03 16:08             ` using dd (or dd_rescue) to salvage array Keith Keller
2012-02-04 18:01               ` Stefan /*St0fF*/ Hübner
2012-02-05 19:10                 ` Keith Keller
2012-02-06 21:37                   ` Stefan *St0fF* Huebner [this message]
2012-02-07  3:44                     ` Keith Keller
2012-02-07  4:24                     ` Keith Keller
2012-02-07 20:01                       ` Stefan *St0fF* Huebner
2012-02-07  3:38         ` Please Help! RAID5 -> 6 reshapre gone bad Phil Turmel
2012-02-08  7:13         ` Stan Hoeppner
2012-02-07  3:04     ` Fwd: " Richard Herd
2012-02-07  2:39 ` NeilBrown
2012-02-07  3:10   ` NeilBrown
2012-02-07  3:19     ` Richard Herd
2012-02-07  3:39       ` NeilBrown
2012-02-07  3:50         ` Richard Herd
2012-02-07  4:25           ` NeilBrown
2012-02-07  5:02             ` Richard Herd
2012-02-07  5:16               ` NeilBrown

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=4F304822.8000102@gmx.net \
    --to=st0ff@gmx.net \
    --cc=kkeller@wombat.san-francisco.ca.us \
    --cc=linux-raid@vger.kernel.org \
    --cc=st0ff@npl.de \
    /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.