|Read Part Two of this topic: Synology SSD Cache on External Devices – Part 2 – Forced Failure|
My Synology DS1513+ has been working great for 6 years and was a direct replacement for an old EMC NAS. The EMC was good too but the software support for a home user just wasn’t there. This is where the Synology really stood out.
A few years after I bought the DS1513+, Synology released an update to the OS to support SSD caching. The reviews of this feature were great but it required either an available internal drive bay or to use their $500 external enclosure. This device is now the center of my home network which hosts multiple websites, docker, security cameras and also the data store for an ESXi server. It’s doing a lot more than it was originally intended for.
This load has lead to rather poor performance. The five Hard Drives just can’t keep up with the rate of input/output requests. While up one night, I dug around in the /etc folder and found the configurations to allow SSD caching on externally connected drives. It’s now been running for almost a week and this NAS is new again!
This is not going to be a write up on how to enable and configure the SSD cache on your device. For that, you can read the fine manuals published by synology. This will document how to have your externally connected devices recognized by the SSD cache service.
These instructions can also be used to extend your internal volume using external drives, but that was not the intention of this implementation.
This was written for the DS1513+ but I’m confident it will work with other devices. Please write in the comments if you have successfully ( or unsuccessfully ) reproduced this yourself or have run into problems.
USB or eSATA
The NAS has both USB and eSATA ports and for my implementation, I made the conscious decision to only apply these changes to the eSATA ports for a few reasons:
- eSATA has lower latency than USB
- SMART diagnostics are only available over eSATA
- I frequently have backup drives hanging off the USB ports
- I don’t trust USB enumeration as a reliable mechanism
- I don’t trust USB for production data storage
Point 2 is important – without SMART diagnostic information, it’s not possible to determine the available remaining life of the SSD. As this diagnostic information directly influences data reliability, I consider it a requirement.
The last two points on my list are purely subjective. You may disagree with that and decide to use SSD caching with USB connected drives. I have not tried this myself, but the steps here should work for that too. Please write in the comments if you made SSD caching work with USB.
Supplies – What you need to buy
Other than an a SSD drive, you’ll need an adapter to connect the drive to the Synology. I used an inexpensive eSATA adapter from amazon that takes power from the USB port to power the drive.
- eSATA to SATA adapter $8 – https://amzn.to/2IAXXQv
Other adapters may work too, but what I’m using is cheap and since it’s passive, it’s also reliable. My drive is just hanging out on top of the NAS. It’s zip tied onto the adapter to prevent it from coming loose.
There are two files you want to edit and luckily for us, the changes in both files are the same. Warning: Don’t copy the files over each other. While they are similar, they are not the same.
You want to change two the two files:
Settings and Explanation
In both configuration files of the DS1513+ are the lines:
If you have a different model, your initial configuration will be different.
The *portcfg properties are bitmasks which define which drive will be mapped to which DSM drive management mechanism. What this means is that your drive sda is the least significant bit, sdb is the second after that and so on.
Let’s look at internalportcfg
0x1f is the hex value which represents binary 0001 1111. This tells DSM that the first through the fifth enumerated drives (sda -> sde) will be treated like internal drives.
Now, let’s look at externalportcfg
0xc0 is the hex value for binary 1100 0000. What we want to is to set all the bits to zero. This will tell DSM that non of the enumerated drives are connected to the eSATA interface and then transfer those bits into the value of the internalportcfg property which will become 1101 1111 or 0xdf.
It is curious that the sixth bit (counting from the right) is a zero. That means sdf is being used somewhere, but it’s not an internal sata or external eSATA drive. That needs to be further investigated.
New settings – All eSATA are now Internal
After migrating the bits from esataportcfg to internal portcfg and updating the number of max disks, what we get is:
With those changes applied and the Synology NAS restarted, any disks attached to the eSATA ports will be displayed in the UI as an internal drive. You can use this to expand your volume or utilize as an SSD cache.
New Settings – All drives are internal
First off, must say that I have not tried this for any length of time, but it does seem to work. I decided not to stick with these settings, but you’re welcome to try it yourself.
What if you want all enumerated drives to be used as part of your storage volume potentially useable as part of an SSD cache?
That will tell DSM to use the first 24 disks discovered by the kernel as internal drives.
I’m confident that this will lead to data reliability issues, mostly on drives connected to USB. These risks may be acceptable to you.
Synology is awesome but some of their product decisions are purely driven by revenue. They have hobbled our ability to connect external drives in favor of their ridiculously overpriced expansion bays.
I’m 100% certain that these changes will void my warranty just as it will void your warranty if you copy them. Luckily, I’ve been out of the warranty for 4 years.
Lastly, I’ve also made the conscious decision to have a read only SSD cache. There is risk in these changes and I’m not willing to extend that risk to a read/write cache. If you have a different threshold for risk than I do, then try this out for a read/write cache and please comment on your experience below.