Speeding up a Synology rebuild

After purchasing a Synology NAS I inserted a bunch of drives and left ‘expanding’ overnight.

When I came back in the morning it had gone from 2% to 5% complete – about 95% less than what I was hoping.

I discovered that you can SSH into the box and check the status of the rebuild with:

cat /proc/mdstat

This showed that I had another 14 days left. Hmm, I don’t think so.

After some poking about I discovered it defaults to a strangely small 256 byte cache size.

There were a lot of posts on the internet about changing this value in /sys/block/md3/md/stripe_cache_size, but this failed with a permission problem. Maybe this applied to older versions.

Instead you can edit:

/etc.defaults/synoinfo.conf

And add the line:

md_resync_cache_size="16384"

It took a few minutes for this to be picked up and then the rebuild time decreased to 14 hours. Much more acceptable.

I tried some larger cache size values but they didn’t make any difference.

Clearing Chrome’s DNS cache

If you ever need to point a domain name at an IP address, for sandboxing during development, or for whatever reasons, then Chrome can be a real nuisance. It seems to cache the domain name and refuses to use your new IP address.

Recent versions supposedly monitor /etc/hosts, and if you view the DNS cache this seems to be true.

chrome://net-internals/#dns

However it can still be stubborn about actually using the new IP. After some digging I found that clearing the socket pool usually does the trick.

chrome://net-internals/#sockets

Certainly beats waiting until Chrome finally gives up the old values.

MacOS terminal cursor navigation with a mouse

File this under ‘I can’t believe I didn’t know this sooner’.

Ever had to edit a long command in a terminal window? Certainly you can set things up so you can jump back and forward using the keyboard. But you can also option+click to move the cursor instantly – really handy for some commands.

Also, in iTerm at least, you can apple+click a URL to open it in your browser.

Using pv to view the progress of dd

If you use dd for any kind of copying you’ll know how it’s not exactly forthcoming with information and it’s hard to tell if it’s doing anything.

Some versions of dd have a status=progress parameter that will output progress information. Sadly this doesn’t exist on the native MacOS version.

An alternative way of showing progress information is to use pv (or pipe viewer).

First install it with brew:

brew install pv

Then wedge pv between reading from the dd source and writing to the dd output.

For example, you might write a Raspberry Pi image to an SD card with:

dd if=retropie.img of=/dev/rdisk4

Using pv you break this into the input and output parts and put pv in the middle:

dd if=retropie.img | pv | dd of=/dev/rdisk4

Sudo needs to be added to both calls to dd:

sudo dd if=retropie.img | pv | sudo dd of=/dev/rdisk4

Telling pv how much data you are transferring allows it to provide better information, and you can do this with the -s flag. In this instance the amount of data is the size of the input image, so:

sudo dd if=retropie.img | pv -s `stat -f%s retropie.img` | sudo dd of=/dev/rdisk4

And what is the result of this? You get to see the progress! Useful if you’re transferring a large amount of data.

pv.jpg

Yarn

There’s another new toy from Facebook, this time called Yarn. Here’s how it went for me:

  1. Installed yarn with brew install yarn
  2. Typed yarn in my project directory
  3. Waited a while
  4. Committed changes to git

All very easy. I’ve not yet experienced any of the benefits of yarn, but that’s probably just a question of time.

virtio_net virtio0 ens3: renamed from eth0

So while fumbling about on my VPS I somehow managed to disable all networking. Using the VPS console I noticed this in /var/log/syslog:

virtio_net virtio0 ens3: renamed from eth0

That doesn’t sound good. Sure enough, trying:

ifup eth0

Returned:

Failed to bring up eth0

Certainly explains the lack of network.

After some digging about on the net I edited /etc/network/interfaces and changed all eth0 references to ens3. A quick reboot and everything is back in action.

I don’t know if it will revert back to eth0, or if this is the right action to take, but so far so good.


A follow-up note. After upgrading the kernel on my VPS I had to revert the above change as the device had gone back to eth0.