From: Wols Lists <antlists@youngman.org.uk>
To: Brad Campbell <lists2009@fnarfbargle.com>,
Andreas Klauer <Andreas.Klauer@metamorpher.de>
Cc: Dark Penguin <darkpenguin@yandex.ru>,
Phil Turmel <philip@turmel.org>,
Rudy Zijlstra <rudy@grumpydevil.homelinux.org>,
keld@keldix.com, linux-raid@vger.kernel.org
Subject: Re: Why not just return an error?
Date: Tue, 11 Oct 2016 11:15:26 +0100 [thread overview]
Message-ID: <57FCBBBE.2040206@youngman.org.uk> (raw)
In-Reply-To: <e8f6f28d-5d64-f824-daaa-7c0c0072b751@fnarfbargle.com>
On 11/10/16 11:01, Brad Campbell wrote:
> On 11/10/16 17:18, Wols Lists wrote:
>> On 11/10/16 05:00, Brad Campbell wrote:
>
>>>> The point is that the disk sector is not bad. So you don't want to mark
>>>> it as bad on the disk. But you know that the *data* in that block is
>>>> bad, so you want the disk access layer to fake a read error when you
>>>> try
>>>> to read it. The intent is to deliberately trigger a rewrite by md.
>>>
>>> I suggested this a while ago. Take the badblocks log, use hdparm to mark
>>> each bad sector as bad and put the drive back in the array. I even
>>> suggested potentially adding a feature to ddrescue to auto-mark the
>>> blocks as bad on the target drive.
>>
>> But does that mean that the drive thinks those sectors are bad, and that
>> they're then lost permanently at the hardware level? That's what I
>> thought the badblocks list did with hdparm, and that's what I was trying
>> to avoid.
>
> I've not used bad blocks list, but a cursory read would indicate it only
> records a bad block if the writeback fails. That won't ever happen with
> a bad sector created with hdparm. All hdparm does is corrupt the EEC on
> the block so a read always returns dud. A write solves that issue nicely.
>
That's good to know. What happened with that suggestion for ddrescue?
Did they not like it, or was it the usual "show us the code and we'll
add it"? :-) So much to do, so little time :-)
I'm trying to build a little list of projects, partly as a result of
doing the wiki, that people wanting to get into raid programming (myself
included!) can do.
Cheers,
Wol
next prev parent reply other threads:[~2016-10-11 10:15 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-10-06 23:32 Why not just return an error? Dark Penguin
2016-10-07 5:26 ` keld
2016-10-07 8:21 ` Rudy Zijlstra
2016-10-07 9:30 ` keld
2016-10-07 11:21 ` Andreas Klauer
2016-10-07 14:43 ` Phil Turmel
2016-10-07 16:23 ` Dark Penguin
2016-10-07 16:52 ` Phil Turmel
2016-10-07 17:44 ` Dark Penguin
2016-10-07 18:41 ` Phil Turmel
2016-10-07 20:39 ` Dark Penguin
2016-10-07 23:11 ` Edward Kuns
2016-10-10 20:47 ` Anthony Youngman
2016-10-10 21:37 ` Andreas Klauer
2016-10-10 21:55 ` Wols Lists
2016-10-11 4:00 ` Brad Campbell
2016-10-11 9:18 ` Wols Lists
2016-10-11 10:01 ` Brad Campbell
2016-10-11 10:15 ` Wols Lists [this message]
2016-10-10 22:10 ` Wakko Warner
2016-10-07 14:19 ` Phil Turmel
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=57FCBBBE.2040206@youngman.org.uk \
--to=antlists@youngman.org.uk \
--cc=Andreas.Klauer@metamorpher.de \
--cc=darkpenguin@yandex.ru \
--cc=keld@keldix.com \
--cc=linux-raid@vger.kernel.org \
--cc=lists2009@fnarfbargle.com \
--cc=philip@turmel.org \
--cc=rudy@grumpydevil.homelinux.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).