All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stan Hoeppner <stan@hardwarefreak.com>
To: Florian Lampel <florian.lampel@gmail.com>,
	LinuxRaid <linux-raid@vger.kernel.org>
Subject: Re: Need Advice regarding chunk size of RAID6 regarding HFS+
Date: Tue, 18 Feb 2014 18:38:05 -0600	[thread overview]
Message-ID: <5303FCED.3060105@hardwarefreak.com> (raw)
In-Reply-To: <FDEECA55-97E1-448E-AA80-76155613D8FD@gmail.com>

On 2/18/2014 4:40 PM, Florian Lampel wrote:
> Hi everyone,
> 
> thanks again for getting me up and running again. I'm in the process
> of copying over my backups, but even when connecting my RAID6 via
> iSCSI directly via a dedicated ethernet cable using a dedicated
> IP-Range and Subnet, I only get write speeds of about 55MB/s and read
> speeds of about 68MB/s when copying a single, large file.

First eliminate the network as the bottleneck.  What's your iperf
throughput?  You have over 1 GB/s peak throughput at the disks.
Anything less than 100 MB/s through the interface points to network
limitations, either ASICs or the IP stacks on the hosts.  If any of your
network ASICs are Realtek or Marvell, i.e. the cheapos, that'll be a
limiting factor.  With the Intel and Broadcom ASICs you typically get
close to wire speed.

> Having read enough about chunk sizes to make my head spin, I would
> like to know what chunk size you'd recommend for the following
> scenario:
> 
> *) The filesystem used is HFS+, and this means it's hard-coded to a
> 4kb block size.
> 
> *) The RAID is a RAID6 consisting of 12 HDDs (Western Digital RED,
> 2TB) using a chunk size of 512k (I stuck with the default).

Chunk size isn't your limiting factor with the large file write/read.

> *) Typical Usage consists of downloading material using Bittorrent
> and JDownloader (aka: lots of small writes) 

Then write throughput isn't a factor here, thus the RMW resulting from
partial stripe writes isn't a factor.

> and feeding an AppleTV
> and Macs using iTunes (aka: Large files (Movies) being read from the
> RAID).

Your stripe width is 5MB, which should be fine for streaming reads of
large files.

> *) While the Filesystem is encrypted using LUKS, I got everything to
> align properly and my CPU supports AES-NI, so there is no performance
> penalty on this front.

There is always a performance penalty when doing full disk encryption.
You should still have well over 100 MB/s throughput though, so your
network is limiting you far more than your encryption.

> *) The filesystem gets exported to a Mac Mini via iSCSI and then
> shared over the network using AFP and iTunes.
> 
> 
> Any ideas?

Yes.  Your network is deficient.

-- 
Stan


      reply	other threads:[~2014-02-19  0:38 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-02-18 22:40 Need Advice regarding chunk size of RAID6 regarding HFS+ Florian Lampel
2014-02-19  0:38 ` Stan Hoeppner [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=5303FCED.3060105@hardwarefreak.com \
    --to=stan@hardwarefreak.com \
    --cc=florian.lampel@gmail.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 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.