Synology SNV3400-400G Review 400GB NVMe SSD for Cache

5
SNV3400 400G
SNV3400 400G

Many of our readers will know of Synology as the producer of a range of user-friendly NAS devices scaling from a single drive to hundreds. Well, back in June Synology announced that they would be producing their own SSDs. These SSDs would come in two varieties: primary storage disks for all-flash NAS deployments, and drives intended for use as SSD cache devices. Previously we looked at the former type in the SAT5200-960G, and today we are looking at the latter in the SNV3400-400G. Unlike the SAT5200 drive, the SNV3400-400G is a NVMe drive in the M.2 2280 (80mm) form factor.

We will be looking at the SNV3400-400G as an individual drive, though the more likely deployment scenario for this drive would be as a cache drive attached to a Synology NAS. We are aware of the limitations of looking at a drive like this out of the context of its intended use, but still consider it a worthwhile exercise.

Synology SNV3400-400G Overview

The Synology SNV3400-400G is a fairly standard looking double-sided M.2 2280 (80mm) form-factor drive.

SNV3400 400G Front
SNV3400 400G Front

The front of the drive is populated by the Phison PS5012-E12DC controller. This is an enterprise-focused controller that supports hardware power loss protection circuitry. The SNV3400-400G does not have PLP capacitors present though; those are reserved for SNV3500-400G model.

Also present on the front of the drive is the DRAM cache and half of the Toshiba NAND.

SNV3400 400G Back
SNV3400 400G Back

Hidden beneath the label on the rear of the drive is the other half of the NAND.

Between the two sides of the PCB there are four 128GB NAND packages, which means there is 512GB of NAND present on the drive. With an accessible capacity of 400GB, that leaves 112GB reserved by the controller. This large portion of the drive is leveraged by the controller as a spare area for wear leveling and to help mitigate against the effects of write amplification, especially when the user-accessible portion of the drive is mostly full. Synology seems to be using a lot of spare area in their SSDs.

Synology SNV3000 Series Specs

The Synology SNV3400-400G is a member of the SNV3000 series of SSDs. There are only two models, and both are 400GB in capacity.

SNV3400 400G Specs
SNV3400 400G Specs

The primary differentiating factor between these two models is the presence of Power Loss Protection circuitry on the SNV3500-400G model. That drive is also M.2 22110 form-factor to allow the physical space on the package to fit the capacitors. The drives share a decent but not great endurance of 0.68 DWPD. Given the small size of the drives that still does not result in a particularly high lifetime endurance rating of 500TBW, but it is still acceptable. Very few users are going to write a fraction of that in NAS arrays. The recently reviewed WD Red SA500 1TB SSD, which is also intended for use as a NAS cache drive, has a higher lifetime endurance rating simply due to its larger capacity, despite the lower DWPD endurance on the Red drive. On the other hand, the Seagate Ironwolf 510 480GB drive has a much higher endurance of 875TBW, so the Synology drive is in no way the market leader here. We are a little surprised at this fact just given the sheer amount of spare area present on the drive.

Also of note is the write speeds, which by NVMe drive standards are very low. 550 MB/s for sequential writes is even within the realm of performance achievable by SATA drives. Synology is once again targeting reliability over performance with their SSD drives.

SNV3400 400 CrystalDiskInfo
SNV3400 400 CrystalDiskInfo

Unlike the SAT5200-960G, CrystalDiskInfo is able to parse most of the SMART attributes from this drive, and can properly tally the host reads and writes. We see the drive is operating at PCIe 3.0 x4 on NVMe 1.3.

Test System Configuration

We are using the following configuration for this test:

  • Motherboard: ASUS PRIME X570-P
  • CPU: AMD Ryzen 5 3600 (6C/12T)
  • RAM: 2x 16GB DDR4-3200 UDIMMs

Our testing uses the Synology SNV3400-400G as the boot drive for the system, installed in the M.2_1 slot on the motherboard. The drive is filled to 85% capacity with data and then some is deleted, leaving around 60% used space on the volume.

Next, we are going to get into our performance testing.

5 COMMENTS

  1. Would have been nice to see an ms-sql benchmark and to get the size of the PLP protected cache, which could play a big part in SQL/ESX (synchronous IO). Even though it only have 500-650 MB/s write performance, it might be faster then all other drives in a SQL environment?

  2. Ops, my mistake, sorry.
    But if it had, would you had investigated the cache size? And it’s performance gain on synchronous I/O (e.g SQL and ESX)?
    Why I’m bringing it up it’s because it’s always messing in reviews of PLP drives, even though one could claim it’s one of the most important advantages of PLP supported drives in my opinion, just to conside for future reviews 😉

  3. It’s something I would like to look at, yes. But thus far I have only reviewed one drive with PLP and it was a SATA drive that was not targeting high performance. If/when I start reviewing more drives targeting that segment, my testing methodology will likely adapt.

  4. Could the relatively poor write performance indicate the controller is not using unused cells as an SLC cache but is writing directly to multi-level cells? This avoids the need for frequent coffee breaks to compress the SLC to MLC, with associated throughput dropouts and reliability risk, since the data isn’t saved in its final form until long after the write cycle is claimed to be complete.
    Benchmarking may need to be done with nearly-full drives to check this and other cell reuse cases. Understandably, few testers have time to write fresh multiples of the drive capacity for each test pass; certainly not if you want to publish before the product is EOL!

LEAVE A REPLY

Please enter your comment!
Please enter your name here

This site uses Akismet to reduce spam. Learn how your comment data is processed.