a bad one

 

I copied

 

for i in /dev/md*

do

echo Setting $i

  blockdev --setra 2048 $i

  blockdev --getra $i

done

 

into my GO script and it brought my transfers down from 60mb-70mb a second to 6mb a second through both the disk and user share.  Local hdparm -tT tests showed no difference between the settings.  Am I doing something wrong? I'm running 4.4.2

I copied

 

for i in /dev/md*

do

echo Setting $i

  blockdev --setra 2048 $i

  blockdev --getra $i

done

 

into my GO script and it brought my transfers down from 60mb-70mb a second to 6mb a second through both the disk and user share.  Local hdparm -tT tests showed no difference between the settings.  Am I doing something wrong? I'm running 4.4.2

4.4.2 already sets the buffer size to 1024, setting it to 2048 may not change much.

 

To go from 60mb/s to 6 says something else is occurring.  Post a syslog for analysis.

 

(You did reboot, right, as the "go script" is only run when you reboot.)

 

Joe L.

does this tweak still make a difference for version 5.0-beta6a?

does this tweak still make a difference for version 5.0-beta6a?

not really.  but you can try it if you like.  The buffer size was increased long ago in unRAID to 1024

thanks for the info... I just ordered the Plus keys... i'm eagerly awaiting it and will just put a cache drive to my system

Does this tweak still apply for 5.x users?

Does this tweak still apply for 5.x users?

No... unRAID applied the same change LONG ago in the 4.4.X series.  You can still experiment, but you'll not see the same drastic  improvement.  If you are running unMENU there are three buttons on the user-scripts page you can press to experiment with alternate values easily. 

 

Joe L.

Even though not used any more (by most people) I thought I should point out a few possible issues with it, and a solution.

 

I don't agree with setting a hard-coded 'sleep 30' as that may not be enough time, or some people don't even have the array set to start on boot. Also, matching the devices by using /dev/md* could cause issues if there is ever any other similar named device, like /dev/mdblah or something.

 

Below is the code I have used to get around these issues:

 

#!/bin/sh

 

shopt -s extglob

READAHEAD="2048"

 

while [ ! -b /dev/md1 ]

do

        sleep 1

done

 

## The array has now been started

echo "Array has been STARTED";

echo  -n "Setting drive 'read-ahead' to $READAHEAD"

for i in /dev/md+([[:digit:]]);

  do

    `blockdev --setra $READAHEAD $i`;

    echo -n ".";

done

echo "Done."

exit $?

 

That code should be run from the go script and it will sit there sleeping until the block device /dev/md1 exists. At that point, it will run the blockdev command on all device nodes matching /dev/mdNN where NN is a digit from 0 to 99 inclusive.

Great additions, I will incorporate them into my go script.

Here is my prefix in waiting for /dev/md1 to come online.

 

declare -a CHAR=('+' 'x');

let i=0 notices=60
DEV=/dev/md1
while [[ ${notices} -gt 0 && ! -b ${DEV} ]]
do    printf "Waiting $notices seconds for ${DEV}. Press ANY key to continue: [${CHAR[${i}]}]: "
      read -n1 -t1 && break
      echo -e "\r\c"
      (( notices-=1 ))
      [[ $(( i+=1 )) -ge ${#CHAR[@]} ]] && let i=0;
done
[ ${notices} -ne 60 ] && echo

let i=0 notices=60
DIR=/mnt/disk1
while [[ ${notices} -gt 0 && ! -d "${DIR}" ]]
do    printf "Waiting $notices seconds for ${DIR}. Press ANY key to continue: [${CHAR[${i}]}]: "
      read -n1 -t1 && break
      echo -e "\r\c"
      (( notices-=1 ))
      [[ $(( i+=1 )) -ge ${#CHAR[@]} ]] && let i=0;
done
[ ${notices} -ne 60 ] && echo

 

There is more code, but it's a visually appealing notice with a max wait value that lets you break out of the loop early when doing maintenance.

Ideally this should be adjusted for the last drive in the array, however reading the sb.dat file in bash is/was more then I want to deal with.