Add an NVMe SSD Cache to Your NAS in 2026: Boost Performance

Adding an NVMe SSD to a NAS can speed up storage access. But the cache only works if it sits at the right level. On Linux, an SSD cache is a block cache. It sits between the filesystem and the hard drives. So you do not format the SSD and you do not mount it as a folder. You attach it to the data volume. This tutorial uses lvmcache, which is dm-cache managed by LVM. It is the official tool provided by the lvm2 package on Debian and Ubuntu Server. On an off-the-shelf NAS (Synology, QNAP…), the method is different. You create the cache from the SSD cache wizard in the vendor’s storage manager, not from the command line. Check the vendor’s compatibility list before buying an SSD.

One key point before you start: lvmcache can only accelerate an LVM logical volume. Your data must already be on an LV, whether it sits on a single disk or on an mdadm array. If your data is on a plain ext4 or XFS partition outside LVM, you must first migrate it to LVM. This tutorial does not cover that migration.

Prerequisites

• A Linux-based NAS (Debian, Ubuntu Server or similar) with a free internal M.2 slot that supports NVMe (PCIe). If the slot is SATA-only, an NVMe SSD will not be detected in it. Check your motherboard manual.
• An M.2 2280 NVMe SSD, for example the Sabrent Rocket 4 Plus 8 To or the Western Digital WDBLACK SN850X 8 To. Both are PCIe 4.0 SSDs. In a PCIe 3.0 slot they work, but at that slot’s speed. 8 TB is far more than a cache needs. You can use only part of it for the cache.
• Data on an LVM volume. In the examples, the volume group is called nas and the data volume data. Adjust these names to your system.
• An up-to-date, tested backup of your data. You are changing the storage layout: the backup is not optional.
• Root access (sudo) over SSH from your local network.

Step-by-step installation

Step 1: Install and identify the SSD

Shut down the NAS and unplug it. Insert the SSD into the motherboard’s M.2 slot, then secure it with its screw. Boot up, then list the devices:

lsblk -o NAME,SIZE,TYPE,MODEL,SERIAL,MOUNTPOINTS

Check: a new disk line should appear, for example nvme0n1. It should show your SSD’s size and model, with no mount point and no partitions. Write down its name and its serial number. If you have several NVMe SSDs, the name nvme0n1 may point to another disk. Go by the model and serial number.

Step 2: Install the tools

sudo apt update
sudo apt install lvm2 thin-provisioning-tools nvme-cli smartmontools fio

thin-provisioning-tools provides cache_check, cache_dump and cache_repair. LVM calls these tools to check the cache metadata when the volume is activated. Without them, a cached volume may refuse to activate.

Check:

command -v cache_check && sudo nvme list && sudo smartctl -H /dev/nvme0n1

The first command should print a path such as /usr/sbin/cache_check. nvme list should show your SSD, and smartctl should report PASSED.

Step 3: Check the existing data volume

sudo vgs
sudo lvs -a -o lv_name,vg_name,lv_size,lv_attr,devices
findmnt /srv/data   # replace with your volume's mount point

Check: the nas group and the data volume should appear, and findmnt should show /dev/mapper/nas-data as the source. If your volume does not appear in lvs, your data is not on LVM. Stop here: lvmcache will not be able to accelerate it.

Step 4: Add the SSD to the volume group

⚠️ Warning: destructive command. wipefs erases the signatures on the target disk, and pvcreate initializes it for LVM. All data on this SSD will be lost. Run lsblk again right before and make sure the name matches the new SSD, with the right model and serial number. Never run these commands on a data disk.

lsblk -o NAME,SIZE,MODEL,SERIAL,MOUNTPOINTS /dev/nvme0n1
sudo wipefs --all /dev/nvme0n1
sudo pvcreate /dev/nvme0n1
sudo vgextend nas /dev/nvme0n1

Check:

sudo pvs

/dev/nvme0n1 should appear with nas in the VG column, and its space should show as free (PFree).

Step 5: Create the cache volume on the SSD

The SSD name at the end of the command is essential. It forces LVM to put this volume on the SSD, not on the hard drives. Pick a size that fits your “hot” data. The example uses 500 GiB:

sudo lvcreate -n fast -L 500G nas /dev/nvme0n1

Check:

sudo lvs -o lv_name,lv_size,devices nas

The fast line should show /dev/nvme0n1(…) in the Devices column.

Step 6: Attach the cache to the data volume

Stop the services that use the volume (shares, containers), then unmount it as a precaution:

sudo umount /srv/data
sudo lvconvert --type cache --cachevol fast --cachemode writethrough nas/data
sudo mount /srv/data   # if the volume is listed in /etc/fstab

writethrough is the default and safest mode. Every write goes to both the cache and the hard drives. So losing the SSD loses no data. writeback speeds up writes, but according to the LVM documentation, losing the cache device can then cause data loss. Do not use it with a single SSD.

Check:

sudo lvs -a -o lv_name,lv_attr,lv_size,cache_mode,devices nas

The data volume should have a C as the first character of Attr (cached volume) and show writethrough under CacheMode. The fast volume now appears in brackets, as [fast_cvol], as an internal component.

Step 7: Measure the effect of the cache

The test must go through the cached data volume, never directly to the SSD. You write a test file to the data volume’s filesystem, read it several times, then delete it:

cd /srv/data
sudo fio --name=cachetest --filename=/srv/data/fio-test.bin --size=4G \
  --rw=randread --bs=4k --direct=1 --ioengine=libaio --iodepth=16 \
  --runtime=60 --time_based --group_reporting
sudo rm -f /srv/data/fio-test.bin

Run this test two or three times. dm-cache gradually promotes the most-read blocks to the SSD, so the first pass often performs close to the hard drives alone. With a write-back cache or a very large file, results may vary.

Check: watch the cache counters:

sudo lvs -o lv_name,cache_used_blocks,cache_total_blocks,cache_read_hits,cache_read_misses,cache_dirty_blocks nas/data

cache_used_blocks and cache_read_hits should rise after the repeated reads. If a field does not exist in your version, lvs -o help | grep cache lists the available fields.

Verification checks

• The cache survives a reboot: reboot, then run sudo lvs -a nas and findmnt /srv/data again. The volume should be active and mounted.
• The metadata is read without errors: sudo journalctl -b | grep -i -E "cache|lvm" should show no cache_check errors.
• Kernel-side status: sudo dmsetup status nas-data shows a cache line with counters for used blocks, hits and misses.

Security and best practices

• Stay in writethrough as long as the cache sits on a single SSD. Switching to writeback only makes sense if the cache itself is redundant, for example two mirrored SSDs.
• The cache is not a backup. It adds no extra redundancy.
• Monitor SSD wear with sudo smartctl -a /dev/nvme0n1 (fields Percentage Used and Media and Data Integrity Errors). An M.2 slot without a heatsink can run hot: check the reported temperature.
• Remove the cache cleanly: sudo lvconvert --uncache nas/data stops the cache and deletes the cache volume. With --splitcache, the fast volume is kept.
• Never expose the NAS admin interface to the Internet, nor SSH, SMB/Samba or the Docker socket. For remote access, use a VPN (WireGuard, for example).

Troubleshooting common errors

• Symptom: at boot, the volume does not activate and the log mentions cache_check. Cause: the thin-provisioning-tools package is missing. Fix: install it, then run sudo vgchange -ay nas. If the volume is needed at boot, rebuild the initramfs with sudo update-initramfs -u.
• Symptom: lvcreate put the fast volume on the hard drives. Cause: the SSD name was not given at the end of the command. Fix: delete that volume with sudo lvremove nas/fast (it holds nothing yet), then recreate it with /dev/nvme0n1 added.
• Symptom: lvconvert refuses the operation. Cause: the fast and data volumes are not in the same volume group, or there is not enough free space. Fix: check with sudo vgs and sudo lvs -a. Both volumes must be in nas.
• Symptom: performance does not change. Cause: the workload is mostly sequential, or the data is read only once. A cache only speeds up blocks that are read again. Fix: watch cache_read_hits over several days of real use before drawing conclusions.
• Symptom: the SSD does not appear in lsblk. Cause: the M.2 slot is SATA-only, it is disabled in the BIOS, or it shares PCIe lanes with another port. Fix: check the motherboard manual.

FAQ

What are the benefits of an NVMe SSD cache on a NAS?

Frequently read blocks (databases, VMs, thumbnails, photo libraries) are served from the SSD instead of the hard drives. The gain depends heavily on the workload. For large files read only once, such as streamed movies, it is small.

Can the cache be configured for specific users only?

No. A block cache (dm-cache, bcache) applies to a whole volume, not to users. To target specific data, put it on a dedicated volume and cache only that one.

Should I format the SSD as XFS or ext4?

No. The SSD is used as an LVM physical volume. Only the data volume has a filesystem. That filesystem stays unchanged and is mounted as before.

What about bcache?

bcache is another block cache solution built into the kernel. However, it requires preparing the data disk with make-bcache, which is destructive on an existing volume. For a NAS already on LVM, lvmcache is simpler to add.

What are the costs associated with this installation?

The only purchase is the NVMe SSD. The software used (lvm2, thin-provisioning-tools) is free and provided by the distribution.

Read also

• Comparison cache ssd nvme nas
• Remplacer un disque defaillant dans un nas
• Migrer synology vers un nas diy