I have a Synology DS418 which I use as a backup for my other Synology NAS boxes.

Originally it had 3×12 WD Gold drives in it.  I decided to back some other things up, so I added another 12TB drive to the mix.

Then I nearly fainted at the current price of 12TB drives.  Another WD Gold 12TB would be $600+….gaaaah.  I found a Seagate Iron Wolf Pro for $429.  I’ve used WD for years and they’ve always been excellent.  I seem to recall in the distant paste having an issue with Seagate, though it was probably 20 years ago and for all I know it was some cheap 2-year warranty drive that I pushed for far too long.

Well, let’s give the Wolf a try.

I shutdown the box, popped the drive in, fired the system back up, and then went to the Synology Storage Manager to grow the volume.

I’m using Synology’s SHR RAID technology, which is a sort of glorified RAID 5.  Everything I’m discussing in this article would apply to standard generic Linux software RAID.

I expected the RAID resync to take a while, but…estimate was 4.5 days.  Ouch.

Personalities : [raid1] [raid6] [raid5] [raid4] [raidF1] 
md2 : active raid5 sdd5[3] sda5[0] sdc5[2] sdb5[1]
      23416309760 blocks super 1.2 level 5, 64k chunk, algorithm 2 [4/4] [UUUU]
      [=>...................]  reshape =  7.9% (931304416/11708154880) finish=5084.5min speed=35325K/sec

There are a few tricks you can use to speed up these kinds of resyncs.

How to Make Software RAID Resyncs Faster

First, turn off all other activity on the box so RAID resync is the only thing going on.

Next, set /proc/sys/dev/raid/speed_limit_max and /proc/sys/dev/raid/speed_limit_min to higher values.  Out of the box, speed_limit_max was set to 600000 which wasn’t bad.  Setting it to 700000 didn’t speed things up in my case, but if you have a very low value (or no value), it might help.

Modify these commands to suit your needs:

echo 600000 > /proc/sys/dev/raid/speed_limit_max
echo 100000 > /proc/sys/dev/raid/speed_limit_min

Finally, modify /sys/block/md2/md/stripe_cache_size so the system can work in bigger chunks.  A lot of systems default to 512.  Synology defaults to 1024.  I bumped it up to 4096.  Note that this command is RAID-device specific (in this case, my md2 RAID device) – so don’t copy/paste this command blindly.

echo 4096 > /sys/block/md2/md/stripe_cache_size

I wouldn’t leave it set at that forever but for resyncs, it seemed to help a bit.

Cumulatively, these settings improved performance by about 15%.   I’d guess the stripe_cache_size was the main contributor to the improvement.  Since the system is idle except for the resync, there shouldn’t be any other work on the disk fighting for I/O where speed_limit_min would come into the picture.

Two days later, my RAID resync is still running but these tricks shaved about 8 hours off of it.

Thanks to @luckypenguin for the tips!

raindog308

raindog308 is a longtime community LETizen, technical writer, and self-described techno polymath. With deep roots in the *nix world, he has a passion for systems both modern and vintage, ranging from Unix, Perl, Python, and Golang to shell scripting and mainframe-era operating systems like MVS. He’s equally comfortable with relational database systems, having spent years working with Oracle, PostgreSQL, and MySQL.

As an avid user of LowEndBox providers, raindog308 runs an empire of LEBs, from tiny boxes for VPNs, to mid-sized instances for application hosting, and heavyweight servers for data storage and complex databases. He brings both technical rigor and real-world experience to every piece he writes.

Beyond the command line, raindog308 has a life-long love of German Shepherd Dogs, high-quality knives, target shooting, theology, tabletop RPGs, playing guitar, and hiking in deep, quiet forests.

His goal with every article is to help users, from beginners to seasoned sysadmins, get more value, performance, and enjoyment out of their infrastructure.

You can find him daily in the forums at LowEndTalk under the handle @raindog308.