I did

echo 8192 > /sys/block/md0/md/stripe_cache_size

to improve my RAID performance, and it did helped alot.

But I still can't figure out how to make it permanent.

I was trying to set it in /etc/rc.local - other commands are executed, but it was overwritten to 256 elsewhere... Any hints?

  • Reposting comment from my answer below; I'm not sure if you saw it or not since I'm not sure how StackExchange works: Hmmm... I don't have RAID, so it's kind of a long shot, but can you try 'grep -R 256 /etc/init.d' and 'grep -R stripe_cache_size /etc/init.d'? – zpletan Jan 15 '11 at 1:45
  • 1
    Would the sysfsutils package help fix your problem? – zpletan Jan 26 '11 at 12:00

Add a udev rule, e.g. to /etc/udev/rules.d/60-md-stripe-cache.rules:

SUBSYSTEM=="block", KERNEL=="md*", ACTION=="change", TEST=="md/stripe_cache_size", ATTR{md/stripe_cache_size}="8192"

I haven't actually tried this so it might not be 100% right (may be some typos), but it should be close. Check man udev to understand more.

You may also want to run the following commands afterwards to immediately apply the new rule:

udevadm trigger
udevadm control --reload-rules
  • 1
    Thank you so much, this is finally perfect solution :-) Syntax is ok, I just had to add 60- before the name, and regenerate ramfs. – BarsMonster Mar 10 '11 at 15:21
  • 1
    Thanks. I can't believe this is still a problem in Ubuntu 13.10. Just went from <10MB/s and complete hangs to >100MB/s while copying from one encrypted RAID to another, just by changing the stripe cache size to a much more generous value. – frostschutz Oct 4 '13 at 21:00
  • Just so it's clear for others: on at least modern Ubuntu systems (17.04 in my case), possibly others, you need to rebuild your initramfs ("sudo update-initramfs -u") after creating this new rule or it won't actually take effect automatically. – Bryan Henry Aug 23 '17 at 4:18

Just to expand on the last post; the script underneath works for me. Just swap your details between the "<...>". Enjoy!

#!/bin/sh -e
# rc.local
# This script is executed at the end of each multiuser runlevel.
# Make sure that the script will "exit 0" on success or any other
# value on error.
# In order to enable or disable this script just change the execution
# bits.
# By default this script does nothing.

##  You are limited by CPU and memory too #
##  <Your Name> <Date of Modification>    #
##  stripe cache size and read-ahead      #
echo 16384 > /sys/block/<Your RAID5 or 6 Volume>/md/stripe_cache_size
blockdev --setra 16384 /dev/<Your RAID5 or 6 Volume>

exit 0
  • 3
    Don't say "Just to expand on the last post" because answers usually get ranked by votes so its possible your answer could appear above the one you are referring to. Refer to the post by the authors name. It's much clearer. – Warren Hill Aug 11 '13 at 8:37

I am also trying to figure this out. I put mine in rc.local and no luck. I start it up manually after logging in. I suppose you could write a script to handle this and put it in your "Startup Applictions" but that doesn't help at all if you're not logged in to gnome.

  • It's ubuntu server, so no luck here. – BarsMonster Jan 13 '11 at 6:21

Would the sysfsutils package help fix your problem?


I can't figure out how to comment on your question; I guess I'll edit this answer as I learn more about your problem.

Can you post (or pastebin, if it's long) the output of

grep -R md0 /etc/init.d
  • Nothing found there. – BarsMonster Jan 13 '11 at 4:05
  • Hmmm... I don't have RAID, so it's kind of a long shot, but can you try 'grep -R 256 /etc/init.d' and 'grep -R stripe_cache_size /etc/init.d'? – zpletan Jan 13 '11 at 12:25
  • both returned no results. – BarsMonster Jan 15 '11 at 9:39

I don't have a real answer for you, but maybe you could try creating a simple upstart startup script. Create a file in /etc/init with the .conf extension. In the file put:

start on started tty1

exec echo 8192 > /sys/block/md0/md/stripe_cache_size

My thinking is that that should run the command around the time that the terminal has started, which is probably around the same time you are running the command.

  • I've already tried to put this in startup script (rc.local) and this didn't helped. Also, as this is Ubuntu Server, no terminals might be there after reboot, AFAIK. – BarsMonster Jan 16 '11 at 21:29
  • I was proposing this as an alternative to the rc.local method. Maybe it would start later. I don't really know though. – user1974 Jan 17 '11 at 0:41
  • As for the lack of terminals, I have no idea. Why wouldn't a server have ttys after a startup? Do we mean the same thing when we say terminal? Regardless, you can use a different service to trigger the command, just change tty1 – user1974 Jan 17 '11 at 0:53

Total shot in the dark as I don't have a RAID 5 setup to test with: Maybe add a line with

chmod -w /sys/block/md0/md/stripe_cache_size

in rc.local to remove the write permissions after it's set. Maybe that will stop it from getting changed elsewhere?

  • Good idea, but it seems like something is screwed up in Ubuntu boot process :-S I'll try and post today. – BarsMonster Jan 19 '11 at 10:32
  • Didn't helped :-| – BarsMonster Jan 21 '11 at 19:03


echo 8192 > /sys/block/mdX/md/stripe_cache_size

to /etc/rc.local.

  • See the question - this is the first thing I've tried, and it didn't worked, apparently md-driver was reinitialized or something after rc.local was executed. – BarsMonster Oct 25 '11 at 7:16

This page suggests that stripe size (or width) should have been set up when the fs was set up. Maybe tunefs could help here?

  • 2
    It's totally different thing. Stripe cache size is a setting for MD kernel driver on memory for stripes cache. – BarsMonster Jan 25 '11 at 8:36

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.