17

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?

2
  • 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, 2011 at 1:45
  • 1
    Would the sysfsutils package help fix your problem?
    – zpletan
    Jan 26, 2011 at 12:00

8 Answers 8

18
+100

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
3
  • 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. Mar 10, 2011 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. Oct 4, 2013 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. Aug 23, 2017 at 4:18
1

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.

#################NOTE######################
##  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
1
  • 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. Aug 11, 2013 at 8:37
0

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.

1
  • It's ubuntu server, so no luck here. Jan 13, 2011 at 6:21
0

Would the sysfsutils package help fix your problem?

ORIGINAL ANSWER:

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
3
  • Nothing found there. Jan 13, 2011 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, 2011 at 12:25
  • both returned no results. Jan 15, 2011 at 9:39
0

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.

3
  • 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. Jan 16, 2011 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, 2011 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, 2011 at 0:53
0

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?

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

Append

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

to /etc/rc.local.

1
  • 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. Oct 25, 2011 at 7:16
-1

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

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

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .