From: Jan Ceuleers <jan.ceuleers@computer.org>
To: Shaohua Li <shli@kernel.org>
Cc: linux-raid@vger.kernel.org, neilb@suse.de
Subject: Re: [RFC 1/2]raid1: only write mismatch sectors in sync
Date: Fri, 27 Jul 2012 18:01:49 +0200 [thread overview]
Message-ID: <5012BB6D.8070104@computer.org> (raw)
In-Reply-To: <20120726080150.GA21457@kernel.org>
On 07/26/2012 10:01 AM, Shaohua Li wrote:
...
> To reduce write, we always compare raid disk data and only write mismatch part.
> This means sync will have extra IO read and memory compare. So this scheme is
> very bad for hard disk raid and sometimes SSD raid too if mismatch part is
> majority. But sometimes this can be very helpful to reduce write, in that case,
> since sync is rare operation, the extra IO/CPU usage is worthy paying. People
> who want to use the feature should understand the risk first. So this ability
> is off by default, a sysfs entry can be used to enable it.
For clarity: the risk you are talking about is that the sync will result in more reads, as well as more CPU cycles spent comparing data. Is that right? I.e. there is no risk whatsoever to data integrity?
Can you comment on the magnitude of this risk? For example, if this functionality is inadvertently applied to hard disks, and assuming that the components reside on separate spindles (which is a safe bet), wouldn't those reads happen in parallel thereby not significantly contributing to the slowdown? In other words: the principal component of the slowdown is the in-memory data comparison?
But isn't there then an upside resulting from the avoidance of some writes where data is found to already match?
Thanks, Jan
next prev parent reply other threads:[~2012-07-27 16:01 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-07-26 8:01 [RFC 1/2]raid1: only write mismatch sectors in sync Shaohua Li
2012-07-27 16:01 ` Jan Ceuleers [this message]
2012-07-30 0:39 ` Shaohua Li
2012-07-30 1:07 ` Roberto Spadim
2012-07-31 5:53 ` NeilBrown
2012-07-31 8:12 ` Shaohua Li
2012-09-11 0:59 ` NeilBrown
2012-09-12 5:29 ` Shaohua Li
2012-09-18 4:57 ` NeilBrown
2012-09-19 5:51 ` Shaohua Li
2012-09-19 7:16 ` NeilBrown
2012-09-20 1:56 ` Shaohua Li
2012-10-17 5:11 ` Shaohua Li
2012-10-17 22:56 ` NeilBrown
2012-10-18 1:17 ` Shaohua Li
2012-10-18 1:29 ` NeilBrown
2012-10-18 2:01 ` Shaohua Li
2012-10-18 2:36 ` NeilBrown
2012-10-21 17:14 ` Michael Tokarev
2012-10-31 3:25 ` Shaohua Li
2012-10-31 5:43 ` NeilBrown
2012-10-31 6:05 ` Shaohua Li
2012-10-18 1:30 ` kedacomkernel
2012-11-20 17:00 ` Joseph Glanville
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=5012BB6D.8070104@computer.org \
--to=jan.ceuleers@computer.org \
--cc=linux-raid@vger.kernel.org \
--cc=neilb@suse.de \
--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 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).