linux-raid.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Bill Davidsen <davidsen@tmr.com>
To: David Lethe <david@santools.com>
Cc: Dan Williams <dan.j.williams@intel.com>, linux-raid@vger.kernel.org
Subject: Re: Mapping physical disk block to logical block to selectively repair w/o forcing rescan
Date: Wed, 16 Apr 2008 09:58:59 -0400	[thread overview]
Message-ID: <48060623.9030109@tmr.com> (raw)
In-Reply-To: <A49AB75A717185448F69082E969E536B03C264CC@34093-EVS1C2.exchange.rackspace.com>

David Lethe wrote:
> I have the physical disk sector/drive, so I will have to go backwards.
> That means using compute_blocknr, factoring the chunk size, stripe size,
> look at the raid5_private_data to get everything else, including whether
> or not it is in a rebuild, what position the disk has in the stripe,
> among
> other things .. and repeat for RAID6.  Still all scriptable .. as long
> as I keep the block calculations in 64-bits when on 32-bit kernel. 
>
>   
Or use "bc" to do really long calculations. It works well with scripts.

> I can parse mdadm -Q -D  to get health and configuration, or get it from
> sysfs, haven't decided.
>
> Now for recovery ... a change was made in 2.6.15 that affects how the
> /dev/md recalculates & corrects the error, but I don't think I have to
> worry about it. Just directly read the /dev/md block that corresponds to
> the faulty physical disk/sector.  This should just repair the bad block
> w/o enticing the md system to fail over the entire disk.  Exception
> would be if the disk with bad block can remap due to a catastrophic
> failure, or lack of spare sectors.  
>
> Even if the bad physical block lands on a parity block in the /dev/md
> space, it should get rebuilt because it has to read the entire stripe to
> figure out if there is a parity error, which there will be because one
> disk will return the sense data indicating an unrecoverable read error,
> so the md will repair the stripe to keep parity consistent for me.
>
>   
The problem I see with this is that using raid1 you can read and entire 
array end to end and never use one mirror of the data. So unless you 
perform the 'check' operation you won't really be sure that you have the 
errors mapped. I suspect that running check fixes more errors than 
'repair' on most systems.

-- 
Bill Davidsen <davidsen@tmr.com>
  "Woe unto the statesman who makes war without a reason that will still
  be valid when the war is over..." Otto von Bismark 



  parent reply	other threads:[~2008-04-16 13:58 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-04-15 20:47 Mapping physical disk block to logical block to selectively repair w/o forcing rescan David Lethe
2008-04-15 22:14 ` Janek Kozicki
2008-04-16  0:35 ` Dan Williams
2008-04-16  0:37   ` Dan Williams
2008-04-16  2:47     ` David Lethe
2008-04-16  6:04       ` Dan Williams
2008-04-16 13:58       ` Bill Davidsen [this message]
2008-04-16 14:32         ` David Lethe

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=48060623.9030109@tmr.com \
    --to=davidsen@tmr.com \
    --cc=dan.j.williams@intel.com \
    --cc=david@santools.com \
    --cc=linux-raid@vger.kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).