From: Benjamin ESTRABAUD <be@mpstor.com>
To: Robert Kierski <rkierski@cray.com>,
Adam Goryachev <adam@websitemanagers.com.au>,
"linux-raid@vger.kernel.org" <linux-raid@vger.kernel.org>
Subject: Re: {Possible Spam} RE: stripe_cache_active always 0
Date: Thu, 07 Jan 2016 17:53:47 +0000 [thread overview]
Message-ID: <568EA62B.80103@mpstor.com> (raw)
In-Reply-To: <F7761B9B1D11B64BBB666019E9378117FE848B@CFWEX01.americas.cray.com>
On 07/01/16 16:34, Robert Kierski wrote:
> Adam,
>
> stripe_cache_active is the value to indicate how many pages are currently in use in the stripe cache. I could be wrong about this... but I don’t think you can disable the stripe cache. You can shrink it to an unreasonable size, but the minimum you can set stripe_cache_size to is 17 (pages).
>
> Having said that, it may be that your RAID isn't using the stripe cache or that you're not checking the value frequently enough to see stripe cache activity.
>
> A file system that is properly tuned, and doing buffered IO will likely reduce the stripe cache usage. The stripe cache is basically where data gets put when the RAID is doing partial stripe IO's, calculating parity, or waiting for slow devices to complete their IO's. It's not intended to be yet another level of cache, so it gets purged when the RAID is done with it. So, unlike other caches that will hold onto data until there is memory pressure, the stripe cache is more likely to be empty.
>
> As far as adjusting stripe_cache_size... The stripe cache is dynamically allocated. It won't save any RAM by decreasing stripe_cache_size. Decreasing it too much will negatively impact performance as it's more likely you'll do Read-Modify-Write's when doing partial stripe writes.
>
I find that tuning it a bit higher (but not too high) has a very
positive impact on rebuild times (where we are therefore building
stripes). I can't remember exactly the values but we were setting it to
256 or 512 or even 1024 while building RAID5 or 6 with positive results.
Regards,
Ben.
> Bob Kierski
> Senior Storage Performance Engineer
> Cray Inc.
> 380 Jackson Street
> Suite 210
> St. Paul, MN 55101
> Tele: 651-967-9590
> Fax: 651-605-9001
> Cell: 651-890-7461
>
> N�����r��y���b�X��ǧv�^�){.n�+����{�����{ay�\x1dʇڙ�,j\a��f���h���z�\x1e�w���\f���j:+v���w�j�m����\a����zZ+�����ݢj"��!tml=
>
--
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
prev parent reply other threads:[~2016-01-07 17:53 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-01-07 3:09 stripe_cache_active always 0 Adam Goryachev
2016-01-07 16:34 ` Robert Kierski
2016-01-07 17:52 ` Roman Mamedov
2016-01-07 17:53 ` Benjamin ESTRABAUD [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=568EA62B.80103@mpstor.com \
--to=be@mpstor.com \
--cc=adam@websitemanagers.com.au \
--cc=linux-raid@vger.kernel.org \
--cc=rkierski@cray.com \
/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.