From: NeilBrown <neilb@suse.com>
To: Gandalf Corvotempesta <gandalf.corvotempesta@gmail.com>,
linux-raid@vger.kernel.org
Subject: Re: stripe_cache_size, some info
Date: Fri, 24 Mar 2017 16:47:47 +1100 [thread overview]
Message-ID: <87wpbf8buk.fsf@notabene.neil.brown.name> (raw)
In-Reply-To: <CAJH6TXhL4=MLanyvQh8UMkBmfkfjPd-frsCOC3PqLnDXCpMetw@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1955 bytes --]
On Sun, Mar 19 2017, Gandalf Corvotempesta wrote:
> Hi to all,
> I need some info about stripe_cache_size
>
> Is that a sort of "writeback" cache? Higher the number, higher the
> amount of data to be cached in ram before writing to disks, right?
No.
All of memory is potentially a write-back cache for all filesystems.
the stripe_cache is a write-through cache which holds strips (one page
per device) while reading missing blocks and computing parity.
When the array is degraded, it is also used to hold the blocks in a
strip will calculating the missing data.
>
> Some questions:
>
> 1) any upper limit for that value ? Can I set it near 1GB like most
> hardware controller?
It is currently limited to 32768, for no particularly good reason.
Several stripes (so several times 64 with the default chunk size) is
good. Many stripes might help very random workloads.
> 2) why on my RAID-6 I don't have /sys/block/md0/md/stripe_cache_size ?
No idea. I certainly should do.
>
> As I would like to replace most of our HW raid controller with mdadm,
> any suggestion on how to improve RAID-6 speed ?
>
> Modern CPU aren't an issue, I don't think that double-parity
> calculation could create any bottleneck on a modern CPU.
> The real advantages of a raid controller are mostly 2:
>
> 1) the writeback cache (1GB or 2GB)
> 2) the ability to automatically replace a disk by hotswapping it.
>
> Any solution to this ? For the "2", i've tried by configuring the
> POLICY in mdadm.conf but new disk is never reconized and I always have
> to manually add the new disk to the array.
What, precisely, have you tried? Please provide exact contents of
config files (i.e mdadm.conf) and exact steps you took and what you
expected to happen.
NeilBrown
> --
> 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
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]
next prev parent reply other threads:[~2017-03-24 5:47 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-03-19 18:35 stripe_cache_size, some info Gandalf Corvotempesta
2017-03-20 15:59 ` Wols Lists
2017-03-20 16:13 ` Gandalf Corvotempesta
2017-03-20 16:22 ` Wols Lists
2017-03-20 16:24 ` Gandalf Corvotempesta
2017-03-24 5:47 ` NeilBrown [this message]
2017-03-24 6:00 ` Roman Mamedov
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=87wpbf8buk.fsf@notabene.neil.brown.name \
--to=neilb@suse.com \
--cc=gandalf.corvotempesta@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 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).