From: Wols Lists <antlists@youngman.org.uk>
To: David Brown <david.brown@hesbynett.no>,
NeilBrown <neilb@suse.com>,
linux-raid@vger.kernel.org
Subject: Re: Multi-layer raid status
Date: Fri, 2 Feb 2018 14:24:49 +0000 [thread overview]
Message-ID: <5A7474B1.1020807@youngman.org.uk> (raw)
In-Reply-To: <5A744C4B.7030704@hesbynett.no>
On 02/02/18 11:32, David Brown wrote:
> You already do that during a scrub. You don't want to do it during
> normal operations - unless you have a usage pattern with mostly big
> reads, you will cripple performance. A small performance drop is
> acceptable if it can be shown to significantly improve reliability - but
> making every read a full stripe read will give you random read
> performance closer to that of a single disk than a raid array.
Unless integrity is more important than speed?
Unless (like in your own example) you know there's a problem and you
want to find it?
Yup I know it will knacker performance - I said so. But there are plenty
of use cases where it would actually be very useful, and probably the
lesser of two evils.
(Actually, re-reading your original email, it actually sounds like the
right thing to do would be to call hdparm to mark the sector bad on sda,
rather than use badblocks, so it will rewrite and clear itself. And this
is also a perfect example of where my technique would be useful - it's
probably not the raid-5 parity block that gets corrupted, therefore the
data itself has been corrupted, therefore my utility would find the
damaged file for you so you could recover from backup. A scrub at the
raid-5 level would just "fix" the parity and leave you with a corrupted
file waiting to blow up on you.)
Cheers,
Wol
next prev parent reply other threads:[~2018-02-02 14:24 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-01-30 15:30 Multi-layer raid status David Brown
2018-02-02 6:03 ` NeilBrown
2018-02-02 10:41 ` David Brown
2018-02-02 11:17 ` Wols Lists
2018-02-02 11:32 ` David Brown
2018-02-02 12:12 ` Reindl Harald
2018-02-02 14:24 ` Wols Lists [this message]
2018-02-02 14:50 ` David Brown
2018-02-02 15:03 ` Wols Lists
2018-02-02 15:40 ` David Brown
2018-02-02 16:49 ` Wols Lists
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=5A7474B1.1020807@youngman.org.uk \
--to=antlists@youngman.org.uk \
--cc=david.brown@hesbynett.no \
--cc=linux-raid@vger.kernel.org \
--cc=neilb@suse.com \
/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.