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:
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:
And add the line:
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.
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.
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.
Certainly beats waiting until Chrome finally gives up the old values.
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.
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
pv between reading from the
dd source and writing to the
For example, you might write a Raspberry Pi image to an SD card with:
dd if=retropie.img of=/dev/rdisk4
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
sudo dd if=retropie.img | pv | sudo dd of=/dev/rdisk4
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.
There’s another new toy from Facebook, this time called Yarn. Here’s how it went for me:
- Installed yarn with
brew install yarn
yarn in my project directory
- Waited a while
- 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.
So while fumbling about on my VPS I somehow managed to disable all networking. Using the VPS console I noticed this in
virtio_net virtio0 ens3: renamed from eth0
That doesn’t sound good. Sure enough, trying:
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