DB-유

Synology SSD Cache: When It Helps

· synology, ssd, storage, performance

Those empty M.2 slots on the DS918+ invite the question: should I put SSDs in as a cache? Synology's marketing says yes. My experience says it depends entirely on the workload. On a media share streaming big files to a TV, a cache does nothing. On a Docker host with a few databases, a VMM guest, or a share full of small files hit by many users, a read-write cache changes how the machine feels.

Requirements first. You need a model that supports SSD cache (most Plus models with four or more bays, plus units with M.2 slots like the DS918+, DS1019+, DS1618+, DS1819+ and the RS line; check the spec page) and DSM 6.2, which has the advisor and lets you mount the cache on a volume. One SSD gives a read-only cache; a read-write cache is a RAID 1 pair, so two identical SSDs. Endurance matters, because a read-write cache absorbs every write and consumer TLC drives with low TBW ratings wear out. Check the TBW or DWPD figure before buying.

What gets cached

The cache works on random 4K-ish blocks. Sequential reads and writes of large files bypass it ("skip sequential I/O" is on by default and should stay on). So:

  • Large video files, ISO images, backup targets: no benefit.
  • Btrfs metadata, database files, Docker image layers, VM disks, Photo Station thumbnails, shared folders with thousands of small documents: real benefit.
  • Read-only cache accelerates repeated reads only. Read-write cache also absorbs random writes and flushes them to the HDDs later.

The cache is per volume. If your databases live on volume 2 and media on volume 1, cache volume 2.

Ask the advisor first

Storage Manager → SSD Cache → SSD Cache Advisor. I never buy SSDs before this has run. Select the volume and let it run for at least a few days that cover a normal work week; it records the read/write pattern and reports how much of the accessed data would fit in a given cache size and the expected hit rate.

If the advisor says a 200 GB cache would capture 90% of hot data, a pair of 250 GB SSDs is the right size. If it recommends multiple terabytes, your working set is not cacheable and you are better off adding RAM or a dedicated SSD volume.

Note that a read-only cache also consumes RAM: roughly 1 GB per 1 TB of cache is needed for the mapping tables, and DSM enforces a maximum cache size based on installed memory. On a 4 GB unit, that caps you at a little over 1 TB even with big SSDs; the wizard shows the limit.

Creating the cache

Install the SSDs. On M.2 slots they appear under Storage Manager → HDD/SSD as M.2 Drive 1 and 2. Then Storage Manager → SSD Cache → Create:

  • Choose Read-only cache or Read-write cache. For read-write, both SSDs are selected and mirrored.
  • Select the volume to mount the cache on.
  • Select the drives. If the drives are larger than the RAM-based limit, allocate only part of them; the rest is left unpartitioned, which also helps endurance through over-provisioning.
  • Tick "Skip sequential I/O".

Creation is instant; the cache warms up over hours to days. During this time hit rates in the Performance tab climb from zero.

When an SSD dies

A read-only cache can lose a drive without data loss; the volume just slows down. A read-write cache holds dirty data that has not reached the HDDs, so losing both SSDs before a flush loses that data and can leave the volume needing a check. The RAID 1 pairing covers a single failure; for the rest:

  • Enable email notifications for SSD health in Control Panel → Notification.
  • Watch the estimated lifespan in Storage Manager → HDD/SSD → the SSD → Health Info, which uses the drive's wear indicator.
  • Before any maintenance that pulls the SSDs, remove the cache from Storage Manager first; it flushes dirty blocks and detaches cleanly. Removing a read-write cache on a busy volume can take a long time.

From SSH, the cache device shows up as an additional md device and a flashcache/dm mapping:

cat /proc/mdstat
sudo dmsetup ls
sudo smartctl -a /dev/nvme0n1 | grep -i -E "percentage used|data units written"

Is it paying off?

Storage Manager → SSD Cache → the cache → Performance tab shows hit rate and cache usage. After a week of normal use, hit rates above 60-70% on a workload the advisor recommended are typical; single digits mean the workload is sequential and the cache is wasted. Test something concrete: time a find across a share with many small files before and after, or a page load in a Docker web app that hits its database.

Problems

  • "The SSD cache creation failed because the system memory is insufficient" or a lower size limit than expected: the RAM cap. Add memory or allocate less of the SSD.
  • Read-write option greyed out: only one SSD, or the two SSDs differ in size. Both must be present and the same capacity.
  • Performance dropped after adding the cache: usually a very slow or overheating SSD (some M.2 drives throttle in the DS918+ slots without airflow). Check temperatures under Health Info; a cheap heatsink or a different drive fixes it.
  • Volume shows as "Crashed" after SSD removal without detaching: this is the read-write cache scenario. Do not power cycle repeatedly; contact Synology support with the unit still on, as the dirty blocks may be recoverable from the remaining SSD.

For a file server full of photos and video, spend the money on RAM or more HDDs. For a NAS that runs applications, a modest read-write cache on good SSDs is the most noticeable upgrade there is, as long as you treat the SSD pair as part of the volume, because it is.