From: Sebastian Parschauer <sebastian.riemer@profitbricks.com>
To: NeilBrown <neilb@suse.de>
Cc: "Linux RAID" <linux-raid@vger.kernel.org>,
"Florian-Ewald Müller" <florian-ewald.mueller@profitbricks.com>
Subject: Re: [RFC] Process requests instead of bios to use a scheduler
Date: Mon, 02 Jun 2014 13:12:18 +0200 [thread overview]
Message-ID: <538C5C12.8060407@profitbricks.com> (raw)
In-Reply-To: <20140602202050.14903534@notabene.brown>
On 02.06.2014 12:20, NeilBrown wrote:
> On Mon, 02 Jun 2014 11:51:52 +0200 Sebastian Parschauer
> <sebastian.riemer@profitbricks.com> wrote:
>>
>> Nope, we have our RAID-1+0. So it is more or less a RAID-10 and
>> putting the scheduler to this RAID-0 layer makes sense for us.
>
> I still cannot imagine how this would work. RAID-0 has no
> decisions to make, so no where for a scheduler to fit.
>
> Just to clarify: is this md/raid0 over md/raid1 or md/raid0 over
> hardware/raid1?
We have both variants but tested the scheduler with servers without HW
RAID and only 4 HDDs. On the production servers there are 24 HDDs,
every 2 HDDs are in md/raid1 or HW RAID-1 and these 12 RAID-1 devices
form an md/raid0 device.
This is the only PV for LVM and LVs are the customer volumes exported
via SCST/SRP. These are used by virtual machines on other servers. So
the scheduler has to bring some fairness to the customer volumes so
that a streaming customer can't block a database customer completely
with his big sequential IOs as these would have priority. But our goal
with a scheduler is to reduce latency for everyone.
I hope this is clear, now. Just tell me if not. ;-)
next prev parent reply other threads:[~2014-06-02 11:12 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-05-28 13:04 [RFC] Process requests instead of bios to use a scheduler Sebastian Parschauer
2014-06-01 23:32 ` NeilBrown
2014-06-02 9:51 ` Sebastian Parschauer
2014-06-02 10:20 ` NeilBrown
2014-06-02 11:12 ` Sebastian Parschauer [this message]
2014-06-04 17:09 ` [RFC PATCH 0/4] md/mdadm: introduce request function mode support Sebastian Parschauer
2014-06-04 17:09 ` [RFC PATCH 1/4] md: complete bio accounting and add io_latency extension Sebastian Parschauer
2014-06-04 17:10 ` [RFC PATCH 2/4] md: introduce request function mode support Sebastian Parschauer
2014-06-04 17:10 ` [RFC PATCH 3/4] md: handle IO latency accounting in rqfn mode Sebastian Parschauer
2014-06-04 17:10 ` [RFC PATCH 4/4] mdadm: introduce '--use-requestfn' create/assembly option Sebastian Parschauer
2014-06-17 13:20 ` [RFC PATCH 0/4] md/mdadm: introduce request function mode support Sebastian Parschauer
[not found] ` <CAH3kUhEK26+4KryoReosMt654-vcrkkgkxaW5tKkFRDBqgX82w@mail.gmail.com>
[not found] ` <53A14513.20902@profitbricks.com>
2014-06-18 13:57 ` Roberto Spadim
2014-06-18 14:43 ` Sebastian Parschauer
2014-06-24 7:09 ` NeilBrown
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=538C5C12.8060407@profitbricks.com \
--to=sebastian.riemer@profitbricks.com \
--cc=florian-ewald.mueller@profitbricks.com \
--cc=linux-raid@vger.kernel.org \
--cc=neilb@suse.de \
/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.