* doubt about raid1 and writemostly
@ 2015-06-23 15:01 Roberto Spadim
2015-06-24 22:59 ` NeilBrown
0 siblings, 1 reply; 4+ messages in thread
From: Roberto Spadim @ 2015-06-23 15:01 UTC (permalink / raw)
To: Linux-RAID
hi guys, i'm with a doubt
when i use witemostly, how the md handle the slower drive
(writemostly) for example i have 2 ssd that support 500mb/s write
running raid1, i included a hdd with +- 100mb/s write with writemostly
flag
when i execute a dd if=/dev/zero of=./test , i get near to 200mb/s
with dd, and using iostat -d 1 -k, i get +- 100mb/s
there's some kind of configuration to writemostly drive? something
like 'buffer size' or someting like it?
--
Roberto Spadim
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: doubt about raid1 and writemostly
2015-06-23 15:01 doubt about raid1 and writemostly Roberto Spadim
@ 2015-06-24 22:59 ` NeilBrown
[not found] ` <CAH3kUhHH+uNM92QGEocLJ3HmYYL-28ax1LuC2cvypAHkMYou0Q@mail.gmail.com>
0 siblings, 1 reply; 4+ messages in thread
From: NeilBrown @ 2015-06-24 22:59 UTC (permalink / raw)
To: Roberto Spadim; +Cc: Linux-RAID
On Tue, 23 Jun 2015 12:01:33 -0300 Roberto Spadim
<roberto@spadim.com.br> wrote:
> hi guys, i'm with a doubt
> when i use witemostly, how the md handle the slower drive
> (writemostly) for example i have 2 ssd that support 500mb/s write
> running raid1, i included a hdd with +- 100mb/s write with writemostly
> flag
> when i execute a dd if=/dev/zero of=./test , i get near to 200mb/s
> with dd, and using iostat -d 1 -k, i get +- 100mb/s
> there's some kind of configuration to writemostly drive? something
> like 'buffer size' or someting like it?
>
You need to also enable --write-behind if you want md/raid1 to not be
slowed down so much by a slower device.
However this only really helps hide latency. There is nothing that can
be done to help over-all throughput.
When you set --write-behind you can provide a number which is the
number of outstanding requests that can be in flight to the
write-mostly device.
If your writes are "bursty" in nature - so lots of writes together,
then longer pauses with no writes, then this write-behind buffer can
hide the delay caused by the slower device. If you write continuously,
then there is no way that the slower device can keep up and the
over-all throughput will be reduced to match the slowest device.
This functionality was originally written for cases where both devices
had the same throughput, but one was higher latency, due to being
several kilometres away on the other end of an optical fibre.
NeilBrown
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: doubt about raid1 and writemostly
[not found] ` <CAH3kUhHH+uNM92QGEocLJ3HmYYL-28ax1LuC2cvypAHkMYou0Q@mail.gmail.com>
@ 2015-07-01 14:53 ` Roberto Spadim
2015-07-03 1:32 ` NeilBrown
0 siblings, 1 reply; 4+ messages in thread
From: Roberto Spadim @ 2015-07-01 14:53 UTC (permalink / raw)
To: NeilBrown; +Cc: Linux-RAID
i could do write-behind in a already up md device?
i'm trying echo writebehind > /sys/block/md0/md/dev-sdc1 and it return error
/sys/block/md0/md/dev-sdc1# echo write_behind >state
-bash: echo: write error: Invalid argument
2015-06-25 0:28 GMT-03:00 Roberto Spadim <roberto@spadim.com.br>:
> nice :) i read about it some years ago and i was trying to remember, i will
> test, thanks neil!
>
> 2015-06-24 19:59 GMT-03:00 NeilBrown <neilb@suse.com>:
>>
>> On Tue, 23 Jun 2015 12:01:33 -0300 Roberto Spadim
>> <roberto@spadim.com.br> wrote:
>>
>> > hi guys, i'm with a doubt
>> > when i use witemostly, how the md handle the slower drive
>> > (writemostly) for example i have 2 ssd that support 500mb/s write
>> > running raid1, i included a hdd with +- 100mb/s write with writemostly
>> > flag
>> > when i execute a dd if=/dev/zero of=./test , i get near to 200mb/s
>> > with dd, and using iostat -d 1 -k, i get +- 100mb/s
>> > there's some kind of configuration to writemostly drive? something
>> > like 'buffer size' or someting like it?
>> >
>>
>> You need to also enable --write-behind if you want md/raid1 to not be
>> slowed down so much by a slower device.
>> However this only really helps hide latency. There is nothing that can
>> be done to help over-all throughput.
>>
>> When you set --write-behind you can provide a number which is the
>> number of outstanding requests that can be in flight to the
>> write-mostly device.
>>
>> If your writes are "bursty" in nature - so lots of writes together,
>> then longer pauses with no writes, then this write-behind buffer can
>> hide the delay caused by the slower device. If you write continuously,
>> then there is no way that the slower device can keep up and the
>> over-all throughput will be reduced to match the slowest device.
>>
>> This functionality was originally written for cases where both devices
>> had the same throughput, but one was higher latency, due to being
>> several kilometres away on the other end of an optical fibre.
>>
>> NeilBrown
>
>
>
>
> --
> Roberto Spadim
> SPAEmpresarial - Software ERP
> Eng. Automação e Controle
--
Roberto Spadim
SPAEmpresarial - Software ERP
Eng. Automação e Controle
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: doubt about raid1 and writemostly
2015-07-01 14:53 ` Roberto Spadim
@ 2015-07-03 1:32 ` NeilBrown
0 siblings, 0 replies; 4+ messages in thread
From: NeilBrown @ 2015-07-03 1:32 UTC (permalink / raw)
To: Roberto Spadim; +Cc: Linux-RAID
On Wed, 1 Jul 2015 11:53:07 -0300 Roberto Spadim
<roberto@spadim.com.br> wrote:
> i could do write-behind in a already up md device?
> i'm trying echo writebehind > /sys/block/md0/md/dev-sdc1 and it return error
>
> /sys/block/md0/md/dev-sdc1# echo write_behind >state
> -bash: echo: write error: Invalid argument
You really should be using mdadm, not trying to poke directly at sysfs.
The "Write behind" functionality involves two separate configurations.
1/ the write-intent bitmap must enable write behind - it records a
maximum number of outstanding "behind" requests". To arrange this
you remove any bitmap that you have and add a correctly configured
one.
2/ individual devices can be marked as "write mostly", in which case the
writes to those devices are "behind" writes. you can enable this
by writing "writemostly" to the 'state' file.
NeilBrown
>
> 2015-06-25 0:28 GMT-03:00 Roberto Spadim <roberto@spadim.com.br>:
> > nice :) i read about it some years ago and i was trying to remember, i will
> > test, thanks neil!
> >
> > 2015-06-24 19:59 GMT-03:00 NeilBrown <neilb@suse.com>:
> >>
> >> On Tue, 23 Jun 2015 12:01:33 -0300 Roberto Spadim
> >> <roberto@spadim.com.br> wrote:
> >>
> >> > hi guys, i'm with a doubt
> >> > when i use witemostly, how the md handle the slower drive
> >> > (writemostly) for example i have 2 ssd that support 500mb/s write
> >> > running raid1, i included a hdd with +- 100mb/s write with writemostly
> >> > flag
> >> > when i execute a dd if=/dev/zero of=./test , i get near to 200mb/s
> >> > with dd, and using iostat -d 1 -k, i get +- 100mb/s
> >> > there's some kind of configuration to writemostly drive? something
> >> > like 'buffer size' or someting like it?
> >> >
> >>
> >> You need to also enable --write-behind if you want md/raid1 to not be
> >> slowed down so much by a slower device.
> >> However this only really helps hide latency. There is nothing that can
> >> be done to help over-all throughput.
> >>
> >> When you set --write-behind you can provide a number which is the
> >> number of outstanding requests that can be in flight to the
> >> write-mostly device.
> >>
> >> If your writes are "bursty" in nature - so lots of writes together,
> >> then longer pauses with no writes, then this write-behind buffer can
> >> hide the delay caused by the slower device. If you write continuously,
> >> then there is no way that the slower device can keep up and the
> >> over-all throughput will be reduced to match the slowest device.
> >>
> >> This functionality was originally written for cases where both devices
> >> had the same throughput, but one was higher latency, due to being
> >> several kilometres away on the other end of an optical fibre.
> >>
> >> NeilBrown
> >
> >
> >
> >
> > --
> > Roberto Spadim
> > SPAEmpresarial - Software ERP
> > Eng. Automação e Controle
>
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2015-07-03 1:32 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2015-06-23 15:01 doubt about raid1 and writemostly Roberto Spadim
2015-06-24 22:59 ` NeilBrown
[not found] ` <CAH3kUhHH+uNM92QGEocLJ3HmYYL-28ax1LuC2cvypAHkMYou0Q@mail.gmail.com>
2015-07-01 14:53 ` Roberto Spadim
2015-07-03 1:32 ` NeilBrown
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).