All of lore.kernel.org
 help / color / mirror / Atom feed
From: Wols Lists <antlists@youngman.org.uk>
To: 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: Mon, 10 Oct 2016 22:55:49 +0100	[thread overview]
Message-ID: <57FC0E65.1050407@youngman.org.uk> (raw)
In-Reply-To: <20161010213726.GA3757@metamorpher.de>

On 10/10/16 22:37, Andreas Klauer wrote:
> On Mon, Oct 10, 2016 at 09:47:04PM +0100, Anthony Youngman wrote:
>> with a list of all blocks that failed to copy. Then we need to patch the 
>> low-level disk access code so that it reads this list of "bad blocks" 
>> and returns a read error if any attempt is made to read one. If a block 
> 
> hdparm has that feature to mark sectors as bad (--make-bad-sector).
> not sure how that behaves on a re-write by md. I never tried it myself.

I'm guessing it's useless ...

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.
> 
> Maybe you could also do something with device mapper. It does have 
> an error target, and then there's the overlay. I wish dmsetup had 
> some profiles/shortcuts/reciped to make creation of such device mapper 
> tidbits easier or another common tool for those device mapper tricks...
> 
That certainly sounds plausible ...

Cheers,
Wol


  reply	other threads:[~2016-10-10 21:55 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 [this message]
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
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=57FC0E65.1050407@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=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 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.