I added NVMe caching to my media NAS, and the real win wasn't the files

Published Aug 27, 2026, 4:30 PM EDT Jeff's been involved in the IT industry since before the Internet and spent more than 20 years working in technical support, system administration, network administration, and consulting roles. He holds an undergraduate degree in English, a Master's degree in English with a focus on professional writing and editing, and another Master's degree in Computing & Information Systems. After teaching university English and computer science for a few years, Jeff launched his writing career. He's written for Macworld, Tom's Hardware, groovyPost, The Mac Observer, and more before beginning here at XDA. I’d had a spare 500GB WD Blue NVMe sitting around long enough for SSD caching to become one of those projects I figured I should try. My UGREEN DXP4800 Pro made the most sense for it because that NAS runs Jellyfin and the rest of my media library stack, so it’s doing a lot more than just storing big media files. I installed the SSD, enabled caching in UGOS, and expected the usual NAS upgrade problem, where the benchmark shows something changed but day-to-day use feels exactly the same. That wasn’t what happened. The improvement was obvious almost immediately, but not in the part of the workload I’d originally assumed would matter. SSD caching started making sense once apps got involved The media files were never the interesting part here It’s easy to think of SSD cache as making a hard-drive array behave more like solid-state storage. That’s where I started, too, and it’s also why the idea had never seemed especially urgent. Jellyfin streaming already worked fine from the array, and my media files weren’t sitting there waiting for some dramatic storage upgrade. A movie doesn’t become more playable because the disks can feed it faster than they already could. The more interesting part was everything happening before and around playback. My DXP4800 Pro isn’t just serving video files. Jellyfin and the rest of the media stack constantly deal with databases, metadata, artwork, configuration files, and the smaller bits of data that make the applications usable. None of that sounds very impressive when you’re talking about NAS performance, but it’s exactly the stuff I’m interacting with every time I open one of those apps. Once I looked under the hood of UGOS, the setup made more sense. UGOS had put my entire storage volume behind a Linux bcache layer, including the Docker data used by Jellyfin and the rest of my media stack. I’d only allocated 50GB of the 500GB SSD to the cache while I figured out whether it was worth using, and the rest remained free. The applications weren’t being moved onto the SSD. Instead, frequently accessed blocks from anywhere on the volume could be served from the NVMe device. The SSD cache isn’t moving Jellyfin or the rest of the app stack onto NVMe storage. UGOS is using Linux bcache at the block level, so frequently accessed data from anywhere on the cached volume can be served from the SSD while the original files remain on the hard-drive array. The first improvement was obvious in everyday app use Jellyfin felt faster before I checked the cache statistics Jellyfin was the first thing that caught my attention. Opening it and navigating the interface felt noticeably faster, not in a way that made me wonder whether I was imagining it because I’d just installed new hardware. The difference was clear enough to notice during normal use. That matters more to me than a benchmark result because I use Jellyfin regularly and can tell when it starts to feel sluggish. The same general change showed up elsewhere in the application stack. Pages that had taken a little longer to populate were more responsive, which made the NAS feel quicker even though the actual hard-drive array hadn’t changed at all. That matters because the cache didn’t somehow turn four spinning disks into NVMe storage. It just reduced some of the waiting in the places where I was actually noticing it. I still didn’t want to rely entirely on that impression, so I checked what bcache was doing under the hood in UGOS. During active use, I could see reads coming from both the RAID array and the NVMe cache, rather than everything going back to the hard drives. Some one-second samples showed more read data coming from the SSD side than from the backing array. That was enough to confirm the responsiveness I was noticing wasn’t just wishful thinking after installing new hardware. Small random workloads are where cache earns its keep Metadata and databases care more about latency than bandwidth A media server is a somewhat awkward storage workload because the files everyone notices are huge, while much of the work around them is tiny. The video itself might be tens of gigabytes, but Jellyfin still has to process databases, posters, metadata, and configuration data to build the interface around it. That data doesn’t need enormous throughput. It does benefit from lower latency. UGOS had configured my cache in writearound mode, which makes the SSD primarily useful as a read cache rather than a place to absorb incoming writes. That fits this workload surprisingly well. The things that felt quicker were interfaces and application data I was repeatedly reading, not huge files I was writing to the array. Bcache is also designed to let large sequential I/O bypass the cache rather than crowding out the smaller, repeatedly accessed blocks that are more useful to keep around. The statistics backed that up. When I checked, bcache had already recorded 160,594 cache hits and 256,195 misses, for an overall hit ratio of 38%, even though the system still reported 99% of the cache as available. It had also bypassed 4.7GB of traffic rather than trying to cache everything that crossed the volume. That finally gave me a useful way to think about what the SSD was doing, rather than treating it as a generic storage-speed upgrade. Most NAS workloads still do not need SSD cache Large sequential transfers barely benefit from faster flash storage There are still plenty of NAS setups where I wouldn’t bother with this. If the box mainly holds backups, movies, disk images, or other large files, hard drives are already quite good at reading and writing such data sequentially. The network can also become the bottleneck before the disks do, especially once you stop dealing with tiny random accesses. Adding an NVMe SSD doesn’t automatically change any of that. It’s particularly easy to overestimate what cache will do for media streaming. Jellyfin doesn’t need NVMe-level throughput to play an ordinary video file, and the cache won’t suddenly improve picture quality or make transcoding easier. It also won’t fix a slow client or a network problem elsewhere in the chain. If those are the reasons the server feels slow, the SSD is solving the wrong problem. Start small if you’re testing SSD cache for the first time. I only allocated 50GB of a 500GB NVMe drive, which was enough to confirm that my workload benefited before committing more space to the cache. There’s also something to be said for not adding complexity without a reason. A cache means another drive, another feature to configure, and another variable to remember if performance starts acting strangely later. I already had the WD Blue doing nothing, so this was a low-cost experiment for me, and starting with only 50GB made it even easier to treat it that way. If I’d been buying an SSD specifically for this job, I would have wanted a much clearer idea of what I expected it to improve. That limitation is exactly why this upgrade finally worked The cache helped the workloads I actually interact with Those limitations don’t make me want to pull the SSD back out. If anything, they’re why I’m happier with the result. I stopped judging the cache by whether it made every NAS operation faster and started judging it by whether the applications I actually use felt better. After checking the bcache statistics, I also had evidence that a meaningful share of those reads was being served from NVMe. My media files don’t need to live on fast storage for the DXP4800 Pro to feel responsive. The big files can stay on the hard drives, where they belong for capacity reasons and where sequential performance is already good enough for what I’m doing. The interface, metadata, databases, and application data are the things I’m poking at over and over again. Cutting down the delay there changes my experience with the NAS much more than making an occasional bulk transfer finish a little sooner. That’s also why I wouldn’t tell someone to add SSD cache just because their NAS has an empty M.2 slot. I’d look at what the system is doing first. A mostly idle backup target and a NAS running Jellyfin with a full media management stack will expose completely different bottlenecks. The useful question is whether there’s a workload on the box that actually benefits from faster access to repeatedly used data. SSD cache makes sense when you stop expecting miracles My 500GB WD Blue didn’t turn the DXP4800 Pro into an all-flash NAS, and that’s fine. I’m only using 50GB of it for cache right now, and even that was enough to make the difference noticeable in the applications I use most. The array is still doing the heavy lifting for the media library, while the SSD handles some reads that benefit from lower latency. That split finally made SSD caching click for me. I didn’t need the whole storage system to get faster. The useful question is whether there’s a workload on the box that actually benefits from faster access to repeatedly used data. If you already have an SSD sitting idle, this is the kind of workload I’d look for before dismissing caching or expecting too much from it. Don’t judge it only by copying a huge file and watching the transfer rate. Pay attention to the applications running on the NAS, the data they keep touching, and the places where you actually find yourself waiting. Once I did that and confirmed what bcache was serving from the SSD, the cache stopped feeling like an obscure storage feature and started feeling like a very specific upgrade that finally had a job. UGREEN DXP4800 Pro $720 $800 Save $80 CPU Intel Core i3-1315U Memory 8GB (expandable to 96GB) Drive Bays 4 x SATA, 2 x M.2 NVMe SSD Ports 1 x USB-C (10Gbps) 1 x USB-A (10Gbps) 1 x SD Card 3.0 1 x USB-A (5Gbps 2 x USB-A (480Mbps 2.GbE LAN 10GbE LAN Caching 2 x M.2 NVMe SSD (up to 8TB) Adding even a small SSD cache to the DXP4800 Pro NAS dramatically improved my Jellyfin server's responsiveness.