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
next prev parent 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 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.