All of lore.kernel.org
 help / color / mirror / Atom feed
From: NeilBrown <neilb@suse.com>
Cc: Shaohua Li <shli@kernel.org>, Christoph Hellwig <hch@lst.de>,
	linux-raid@vger.kernel.org
Subject: Re: [md PATCH 0/5] Stop using bi_phys_segments as a counter
Date: Thu, 24 Nov 2016 11:31:59 +1100	[thread overview]
Message-ID: <87d1hlbtvk.fsf@notabene.neil.brown.name> (raw)
In-Reply-To: <20161123084540.GE16966@lst.de>

[-- Attachment #1: Type: text/plain, Size: 1565 bytes --]

On Wed, Nov 23 2016, Christoph Hellwig wrote:

> On Wed, Nov 23, 2016 at 01:08:38PM +1100, NeilBrown wrote:
>> For raid1/raid10 we could do a very similar thing.  There is an
>> awkwardness in raid1 w.r.t waiting for bi_phys_segments to reach 1, but
>> that might disappear if Coly's resync changes go through.
>> Alternately it might make sense to use bio_split so there is one r1_bio
>> per bio.
>> I might try the raid10 version and see what it looks like.
>
> For RAID1 reads there already is one r1_bio per bio

unless the bad-block-log records some bad/missing blocks in the middle
of the range being read.

> - in fact I have
> a hack that doesn't allocate a r1_bio at all, but that one currently
> does not handle reads from degraded arrays at all.  Due you remember
> why we only mark a leg fail for a given bio instead of on a per-device
> or at least per sector-range?

When we detect a read error, we try to "correct" it by reading the data
From elsewhere and over-writing the "bad" block.  If that works, there
was no need to mark the whole device as faulty.  If it does fail, that
is when the device is failed.

We could have a "soft-write-mostly" flag to discourage reads from a
questionable device, until it has been properly tested.

>
> For writes it would make sense to allocate the new bio for each mirror
> using a bio_set with front_pad for raid1-specific data, but I haven't
> really looked into the details yet.

Yes, you could.  I don't know if it would be an improvement, or just a
change.

NeilBrown

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 800 bytes --]

  reply	other threads:[~2016-11-24  0:31 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-11-21  1:19 [md PATCH 0/5] Stop using bi_phys_segments as a counter NeilBrown
2016-11-21  1:19 ` [md PATCH 5/5] md/raid5: use bio_inc_remaining() instead of repurposing " NeilBrown
2016-11-21  1:19 ` [md PATCH 3/5] md/raid5: simplfy delaying of writes while metadata is updated NeilBrown
2016-11-21  1:19 ` [md PATCH 4/5] md/raid5: call bio_endio() directly rather than queuing for later NeilBrown
2016-11-21  1:19 ` [md PATCH 2/5] md/raid5: use md_write_start to count stripes, not bios NeilBrown
2016-11-21  1:19 ` [md PATCH 1/5] md: optimize md_write_start() slightly NeilBrown
2016-11-21  2:32 ` [md PATCH 6/5] md/raid5: remove over-loading of ->bi_phys_segments NeilBrown
2016-11-21 14:01 ` [md PATCH 0/5] Stop using bi_phys_segments as a counter Christoph Hellwig
2016-11-21 23:43 ` Shaohua Li
2016-11-22  0:25   ` NeilBrown
2016-11-22  1:02     ` Shaohua Li
2016-11-22  2:19       ` NeilBrown
2016-11-22  8:01         ` Shaohua Li
2016-11-23  2:08           ` NeilBrown
2016-11-23  8:45             ` Christoph Hellwig
2016-11-24  0:31               ` NeilBrown [this message]
2017-02-06  8:56 ` Christoph Hellwig
2017-02-06 21:41   ` Shaohua Li

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=87d1hlbtvk.fsf@notabene.neil.brown.name \
    --to=neilb@suse.com \
    --cc=hch@lst.de \
    --cc=linux-raid@vger.kernel.org \
    --cc=shli@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 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.