From: Piergiorgio Sartor <piergiorgio.sartor@nexgo.de>
To: Doug Ledford <dledford@redhat.com>
Cc: Piergiorgio Sartor <piergiorgio.sartor@nexgo.de>,
linux-raid@vger.kernel.org
Subject: Re: mdadm 3.1.x and bitmap chunk
Date: Wed, 4 Aug 2010 21:53:02 +0200 [thread overview]
Message-ID: <20100804195302.GA3288@lazy.lzy> (raw)
In-Reply-To: <4C58BC53.1070304@redhat.com>
Hi,
> > Since the setup might be quite fragile, since the
> > write performances are anyway limited by the USB
> > and not by the seek time and writing is anyway slow,
>
> Seeks will *always* limit array speed, even when the link is slow.
> Especially on bitmaps where the seek is synchronous to the pending write.
not really, in this case.
HDDs have cache and prefetch, being the link slow
these work quite at an optimal point.
Actually, there is a huge difference in case of fast
SATA HDDs (having bitmap or not), but as soon as the
link speed goes down it gets even.
In the end it is a RAID-6, so writes are not easy anyhow...
As a side condition, this USB array is mainly a read
device, it's a storage system.
This means that writes will be almost exclusively
filesystem metadata update (access time), so not
really a big deal.
> > 64MB is quite a huge amount of data for USB, so it
> > will not help to keep the bitmap resync fast.
>
> It will help, without a doubt. Any bitmap is better than no bitmap for
> resync. However, any bitmap is a hurt on performance. How much of a
> help versus a hurt just depends on the chunk size.
I meant, 64MB will help less than 64KB.
Chunk size is 64KB, that's because it was the default
at the time the arrays were created.
Since the max transfer data chunk for the USB storage
protocol should be 128KB, I wonder if that chunk size
would have been better.
I might try to reshape it.
> I don't have an easy answer for the smallest chunk size based upon the
[...]
Thanks for the suggestion, I'll try to see if I can
manage to get the "smaller chunk size".
> In any case though, I would just try reducing the bitmap chunk to the
> old default of 8mb. At 8mb you are already suffering a 5% or so
> performance penalty on write, but 8mb is not too much to resync, even
> over USB, so it might be a good compromise in your case.
I'll try also this, even if I hope I'll have not
to benchmark... :-)
BTW, a single USB device can transfer up to 30MB/s, with
one HDD limited to 15MB/s (old HDD).
The arrays can achieve around 43MB/s (read, of course),
which seems to be the limit of the USB chipset of the
motherboard (probably todays MBs can do 50~55MB/s).
This 43MB/s seem to be the limit, since this speed is
achieved with 10 HDDs as well as with 4 (a bit less).
Is this data any good to calculate the "optimal" bitmap
chunk size?
Note that with SATA HDDs the read speed I got (4 HDDs in
RAID-5) was almost precisely (n-1)*slowest_disk, i.e.
3*110MB/s.
In case of the USB system it is not (due to the USB
bottleneck) (n-2)*slowest_disk, so the concept of having
a bitmap chunk about around the 1 second transfer is a
bit difficult, for me, to understand.
Thanks again,
bye,
--
piergiorgio
prev parent reply other threads:[~2010-08-04 19:53 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-06-09 21:05 mdadm 3.1.x and bitmap chunk Piergiorgio Sartor
2010-08-02 18:41 ` Doug Ledford
2010-08-03 18:36 ` Piergiorgio Sartor
2010-08-04 1:03 ` Doug Ledford
2010-08-04 19:53 ` Piergiorgio Sartor [this message]
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=20100804195302.GA3288@lazy.lzy \
--to=piergiorgio.sartor@nexgo.de \
--cc=dledford@redhat.com \
--cc=linux-raid@vger.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).