From: Piergiorgio Sartor <piergiorgio.sartor@nexgo.de>
To: Peter Grandi <pg@lxraid.list.sabi.co.uk>
Cc: Linux RAID <linux-raid@vger.kernel.org>
Subject: Re: raid6check extremely slow ?
Date: Tue, 12 May 2020 18:09:43 +0200 [thread overview]
Message-ID: <20200512160943.GC7261@lazy.lzy> (raw)
In-Reply-To: <24249.54587.74070.71273@base.ty.sabi.co.uk>
On Mon, May 11, 2020 at 11:44:11PM +0100, Peter Grandi wrote:
> >>> With lock / unlock, I get around 1.2MB/sec per device
> >>> component, with ~13% CPU load. Wihtout lock / unlock, I get
> >>> around 15.5MB/sec per device component, with ~30% CPU load.
>
> >> [...] we still need to avoid race conditions. [...]
>
> Not all race conditions are equally bad in this situation.
>
> > 1. Per your previous reply, only call raid6check when array is
> > RO, then we don't need the lock.
> > 2. Investigate if it is possible that acquire stripe_lock in
> > suspend_lo/hi_store [...]
>
> Some other ways could be considered:
>
> * Read a stripe without locking and check it; if it checks good,
> no problem, else either it was modified during the read, or it
> was faulty, so acquire a W lock, reread and recheck it (it
> could have become good in the meantime).
>
> The assumption here is that there is a modest write load from
> applications on the RAID set, so the check will almost always
> succeed, and it is worth rereading the stripe in very rare
> cases of "collisions" or faults.
>
> * Variants, like acquiring a W lock (if possible) on the stripe
> solely while reading it ("atomic" read, which may be possible
> in other ways without locking) and then if check fails we know
> it was faulty, so optionally acquire a new W lock and reread
> and recheck it (it could have become good in the meantime).
>
> The assumption here is that the write load is less modest, but
> there are a lot more reads than writes, so a W lock only
> during read will eliminate the rereads and rechecks from
> relatively rare "collisions".
The locking method was suggested by Neil,
I'm not aware of other methods.
About the check -> maybe lock -> re-check,
it is a possible workaround, but I find it
a bit extreme.
In any case, we should keep it in mind.
bye,
pg
> The case where there is at the same time a large application
> write load on the RAID set and checking at the same time is hard
> to improve and probably eliminating rereads and rechecks by just
> acquiring the stripe W lock for the whole duration of read and
> check.
--
piergiorgio
next prev parent reply other threads:[~2020-05-12 16:09 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-05-10 12:07 raid6check extremely slow ? Wolfgang Denk
2020-05-10 13:26 ` Piergiorgio Sartor
2020-05-11 6:33 ` Wolfgang Denk
2020-05-10 22:16 ` Guoqing Jiang
2020-05-11 6:40 ` Wolfgang Denk
2020-05-11 8:58 ` Guoqing Jiang
2020-05-11 15:39 ` Piergiorgio Sartor
2020-05-12 7:37 ` Wolfgang Denk
2020-05-12 16:17 ` Piergiorgio Sartor
2020-05-13 6:13 ` Wolfgang Denk
2020-05-13 16:22 ` Piergiorgio Sartor
2020-05-11 16:14 ` Piergiorgio Sartor
2020-05-11 20:53 ` Giuseppe Bilotta
2020-05-11 21:12 ` Guoqing Jiang
2020-05-11 21:16 ` Guoqing Jiang
2020-05-12 1:52 ` Giuseppe Bilotta
2020-05-12 6:27 ` Adam Goryachev
2020-05-12 16:11 ` Piergiorgio Sartor
2020-05-12 16:05 ` Piergiorgio Sartor
2020-05-11 21:07 ` Guoqing Jiang
2020-05-11 22:44 ` Peter Grandi
2020-05-12 16:09 ` Piergiorgio Sartor [this message]
2020-05-12 20:54 ` antlists
2020-05-13 16:18 ` Piergiorgio Sartor
2020-05-13 17:37 ` Wols Lists
2020-05-13 18:23 ` Piergiorgio Sartor
2020-05-12 16:07 ` Piergiorgio Sartor
2020-05-12 18:16 ` Guoqing Jiang
2020-05-12 18:32 ` Piergiorgio Sartor
2020-05-13 6:18 ` Wolfgang Denk
2020-05-13 6:07 ` Wolfgang Denk
2020-05-15 10:34 ` Andrey Jr. Melnikov
2020-05-15 11:54 ` Wolfgang Denk
2020-05-15 12:58 ` Guoqing Jiang
2020-05-14 17:20 ` Roy Sigurd Karlsbakk
2020-05-14 18:20 ` Wolfgang Denk
2020-05-14 19:51 ` Roy Sigurd Karlsbakk
2020-05-15 8:08 ` Wolfgang Denk
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=20200512160943.GC7261@lazy.lzy \
--to=piergiorgio.sartor@nexgo.de \
--cc=linux-raid@vger.kernel.org \
--cc=pg@lxraid.list.sabi.co.uk \
/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).