linux-raid.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Keld Simonsen <keld@keldix.com>
To: Michael <michael@rw23.de>
Cc: Neil Brown <neilb@suse.de>, linux-raid@vger.kernel.org
Subject: Re: Map Block number from hdd to md
Date: Wed, 17 Feb 2010 05:34:38 +0200	[thread overview]
Message-ID: <20100217033438.GA8228@rap.rap.dk> (raw)
In-Reply-To: <6a4b5c4af12e9b35347e7d325e4eee13@rw23.de>

On Tue, Feb 16, 2010 at 11:57:00AM +0100, Michael wrote:
> Hi Keld,
> 
> if you do a smartctl -A on /dev/sdX you sould see something under
> Current_Pending_Sector and Offline_Uncorrectable.
> Your hard drive replaces the bad blocks with spare blocks as far as you
> are write something to them.
> 
> i have solved the resync issue by using
> dd if=/dev/zero of=/dev/sdX bs=512 seek=<bad-block-number> count=1
> 
> you can test the block number to be really bad by
> dd if=/dev/sdX of=/dev/null bs=512 skip=<bad-block-number> count=1
> if that command causes a input/output error, the block is bad.

Yes, that cleared some errors, but unfortunately not all.
That is one divice had 72bad blocks beforehand, and 44 afterwaeds, and
the other had 9 beforehand, and 5 after.

The second dd command actuallly did not report any bad blocks, but a
selective badblocks command did.

Anyway, is there something about Samsung disks not having spare blocks 
for this?


> in fact, with each block, you have "lost" 512 bytes of data. your problem
> is very simular to mine.
> after overwriting the bad blocks, all should be fine again.
> 
> you sould be able to "repair" all that bad blocks by a little xor'ing
> script/program mentioned by neil brown.
> if would be nice to have such a script where you can tell which
> block/chunk is wrong and to which device to write to (and to read from).
> with that program, the bad block will be overwritten with the (hopefully)
> valid data and become functional again.

yes, I still would like to find the inode in the raid file system from 
the bad block on a physical disk.

> i also think this is a very common issue, that after a 1disk failue a 2nd
> disk fails at resync because of bad blocks.
> this could be prevented by doing a long smart check once a week or
> something, but i did not had the idea to do that till today :)

I will do some description of this on the wiki, in a while. Others may
also contribute, you are most welcome to write something up for the
wiki.

> On Tue, 16 Feb 2010 06:38:41 +0200, Keld Simonsen <keld@keldix.com> wrote:
> > Further to my problems described below I dreamt up something that could
> > solve my problem, till I got new disks installed.
> > 
> > I am actually alive with a raid5 with 2 malfunctioning devices -
> > something that is impossible...  And I think I could be revived.
> > And I think it is not an uncommon situation.
> > 
> > I have badblocks. But only about 60 blocks on one drive and 10 on the
> > other, out of 4 drives. It is an error rate of about 1 out of 20,000
> > or 99,995 % good data rate. If I could resync both the erroneous drives,
> > and
> > avoid the badblocks in the process, I would be safe (for some time). 
> > 
> > So if resync could be told to avoid the badblocks, and the file system
> > in question also could be told to avoid the blocks then I could be in
> > the air. I was then thinking of a userland resync process - no need to
> > change the kernel, just install new mdadm and friends. Is that doable
> > and useful?
> > 
> > best regards
> > keld
> --
> 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:[~2010-02-17  3:34 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-02-12  0:24 Map Block number from hdd to md Michael
2010-02-16  1:20 ` Neil Brown
2010-02-16  4:02   ` Keld Simonsen
2010-02-16  4:38     ` Keld Simonsen
2010-02-16 10:57       ` Michael
2010-02-17  3:34         ` Keld Simonsen [this message]
2010-02-17  8:43           ` Michael
2010-02-16 11:14   ` Michael
2010-02-17 23:47     ` Neil Brown
2010-02-18  4:12       ` Keld Simonsen

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=20100217033438.GA8228@rap.rap.dk \
    --to=keld@keldix.com \
    --cc=linux-raid@vger.kernel.org \
    --cc=michael@rw23.de \
    --cc=neilb@suse.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 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).