A log device whose flush is cheap took 4K sync writes on our hard-drive-class RAIDZ2 test pool from 110 to 4,277 IOPS. A log device that has to honor every flush reached only 252. That gap, not capacity or sequential speed, is what you buy when you pick a SLOG, and it is why power-loss protection and Optane still decide this category.
A special vdev is the other SSD job in a ZFS pool, and on the same pool it cut a cold find across 200,000 small files from 10.32 s to 0.38 s. We measured both on OpenZFS 2.4.1 under Ubuntu 26.04 in October 2026. The 2.4 release matters here because it lets a special vdev take the sync log when no SLOG exists, so special-vdev drives now need the same flush and endurance properties.
Quick picks for SLOG and special vdev SSDs
Each pick below fills one role. The first three are Optane, which Intel no longer makes; two of the three are new old stock from marketplace sellers, and the 900P was sold by Amazon itself:
| Pick | Role | PLP (vendor) | Endurance | Price band |
|---|---|---|---|---|
| Intel Optane DC P4800X 375GB U.2 | Best SLOG overall | Enhanced PLP: Yes | 30 DWPD | $420 to $450 |
| Intel Optane 900P 280GB add-in card | SLOG sold by Amazon | Enhanced PLP: No | 5.11 PBW | $300 to $320 |
| Intel Optane P5800X 400GB U.2 | Premium SLOG | Enhanced PLP: Yes | 100 DWPD | $740 to $760 |
| Micron 7450 PRO 480GB M.2 | M.2 SLOG or special vdev | PLP on the M.2 2280 model | 800 TBW, 1 DWPD | $640 to $650 |
| Samsung PM893 240GB SATA | SATA special vdev mirror | PLP | 438 TBW | $350 to $370 |
Prices come from Amazon US on October 21, 2026, and enterprise SSDs moved weekly during the 2026 flash shortage, so check the current price and the seller before you order. Among Amazon US listings open to a regular, non-Business account on October 21, a new-old-stock P4800X cost less than any new 480GB PLP NAND drive.
What the SLOG and special vdev measured
Each row is the median of five 15-second fio runs on the same RAIDZ2 pool, so a single noisy run cannot move the result. The 4K test wrote to a recordsize=4K dataset:
| Configuration | 4K sync IOPS (median) | Avg latency | 8K WAL fdatasync avg |
|---|---|---|---|
| No log device | 110 | 9.1 ms | 9,857 µs |
| SLOG that must honor flushes | 252 | 3.96 ms | 7,229 µs |
| SLOG with cheap flushes (PLP or Optane stand-in) | 4,277 | 233 µs | 101 µs |
| No log, 3-way special mirror present (cheap-flush disks) | 2,198 | 454 µs | 125 µs |
| sync=disabled (reference, unsafe) | 8,705 | 114 µs | n/a |
A WAL-style test shows the ceiling. With the cheap-flush log, 8K sequential writes with fdatasync reached 799 IOPS, the same as sync=disabled at 800, because the log had removed the whole sync penalty. No log can make the pool faster than the pool itself, and for this 8K sequential workload our throttle held it at about 800. So buy a SLOG to close the gap to async speed, not to make a slow pool fast.
How it was measured
Read the numbers as ZFS behavior, not as device benchmarks. The rig was built to isolate one variable, the cost of a flush:
- Pool: RAIDZ2 of four 8 GiB virtual disks, each QEMU-throttled to 200 IOPS to behave like hard drives
- Flush-honoring log: a 4 GiB disk with cache=none on the host’s consumer NVMe without PLP; raw fsync averaged 3.86 ms
- Cheap-flush log: a 4 GiB disk with cache=unsafe; raw fsync averaged 15 µs, modeling PLP or Optane latency but not their power safety
- Special vdev: a 3-way mirror of 8 GiB virtual disks, unthrottled, with cache=unsafe, so its flushes were as cheap as the PLP or Optane stand-in
- Runs: fio psync at queue depth 1, five 15-second runs per configuration, median reported
Our VM ran Ubuntu 26.04.1 with OpenZFS 2.4.1 and fio 3.41 on a shared Proxmox node, so individual runs were noisy; the cheap-flush 4K runs spread from 1,279 to 8,986 IOPS. That is why the tables quote medians. No physical Optane or PLP drive was tested, so the drive specs below are vendor-stated, and the lab only shows what ZFS does with a fast or slow flush.
Read the diagram as the buying decision. Only sync writes touch the log, and the log is read back only after a crash, so a SLOG needs a fast, safe flush and little capacity. Metadata and small blocks go to the special vdev and stay there, so a special vdev needs redundancy and room to grow.
1. Intel Optane DC P4800X 375GB: best SLOG overall
Buy the P4800X 375GB as your SLOG if you have a U.2 port. Intel rates it at 30 drive writes per day with Enhanced Power Loss Data Protection, and 3D XPoint acknowledges a flush without the long NAND program cycle. Among Amazon US listings open to a regular account on the check date, it was cheaper than any new 480GB PLP NAND drive, so the best device was also the cheaper one.
Skip it if your board has no U.2 or SFF-8639 port, because you will need an adapter card or cable. It is new old stock from third-party sellers, so check the serial number against Intel’s warranty lookup when it arrives. The OpenZFS workload tuning page says Optane devices remain the best SLOG devices but are no longer manufactured, and the P4800X is on the known-good list of the OpenZFS hardware page.
2. Intel Optane 900P 280GB: the SLOG Amazon sells itself
Only one Optane listing was sold by Amazon.com itself on the check date: the Optane 900P 280GB add-in card, with limited stock. It plugs into a PCIe x4 slot, so no U.2 cabling is needed, and Intel rates the 280GB card at 5.11 PB written, far more than a log device will see.
Intel’s spec page lists Enhanced Power Loss Data Protection as No for the 900P, which reads worse than it is. The OpenZFS hardware page says 3D XPoint drives do not require special power failure protection circuitry for reliability, though its known-good SLOG list names only the enterprise P4800X, P4801X and P1600X, not the consumer 900P. Skip it if you need M.2, a vendor-stated PLP checkbox, or a drive on that OpenZFS list.
3. Intel Optane P5800X 400GB: premium SLOG
For sustained sync traffic, the P5800X 400GB is the PCIe 4.0 Optane, rated at 100 drive writes per day. It suits a SLOG behind 25GbE NFS or iSCSI, where the log sees sync writes for hours, because the endurance headroom is the reason to pay for it.
For a homelab on 1 or 10GbE it is overkill, since our WAL test was already capped by the pool, not the log. It costs about 2.5 times the 900P, and like the P4800X it is new old stock from a marketplace seller, so check the serial on arrival.
4. Micron 7450 PRO 480GB M.2: best M.2 PLP drive for SLOG or special
When all you have is an M.2 2280 slot, pick the Micron 7450 PRO 480GB. Micron lists power-loss protection on the M.2 22×80 model, so flushes are acknowledged from the drive’s protected cache, which is the property that moved our log from 252 to 4,277 IOPS.
Use it as a special vdev member too, because on OpenZFS 2.4 that role takes sync-write wear, as Step 5 shows. The 960GB version ran about $790 to $810. Skip it for a RAIDZ2 special mirror on a budget, because that needs three of them.
5. Samsung PM893: best SATA special vdev mirror
For a SATA-only NAS, the Samsung PM893 240GB and 480GB are SATA drives with power-loss protection, and SATA ports are what most NAS boxes have spare. Our 200,000-file test put only 65.7 MiB of metadata on the special vdev, so even 240GB holds the metadata for a very large pool.
Expect about $350 to $370 for the 240GB and $610 to $630 for the 480GB, both from a third-party seller. Skip SATA if you plan to put small blocks on special with special_small_blocks across a big dataset, or if your pool is sync-heavy on 2.4, where the special vdev also takes the ZIL. The U.2 Samsung PM9A3 960GB at about $690 to $710 is the NVMe step up for that case.
Compare the drives
Here are the five picks side by side on the properties that matter for each role:
| Drive | Interface | Media | PLP (vendor wording) | Best role |
|---|---|---|---|---|
| Optane P4800X 375GB | U.2, PCIe 3.0 x4 | 3D XPoint | Enhanced PLP: Yes | SLOG |
| Optane 900P 280GB | Add-in card, PCIe 3.0 x4 | 3D XPoint | Enhanced PLP: No | SLOG |
| Optane P5800X 400GB | U.2, PCIe 4.0 x4 | 3D XPoint | Enhanced PLP: Yes | SLOG on fast networks |
| Micron 7450 PRO 480GB | M.2 2280, PCIe 4.0 | TLC NAND | PLP on the M.2 2280 model | SLOG or special |
| Samsung PM893 240GB | SATA 2.5-inch | TLC NAND | PLP | Special vdev |
Two drives you will see recommended elsewhere are missing for availability reasons. Intel’s Optane P1600X M.2 would be the ideal small SLOG, but it was out of stock on Amazon on the check date, and Kingston DC2000B and DC600M PLP drives were offered only to Amazon Business accounts.
Step 1: Check whether your workload is sync at all
A SLOG helps only synchronous writes. Async writes never touch it, and our iostat shows that directly. Watch the pool while your real workload runs:
sudo zpool iostat -vy tank 10 1During a 4K sync write test, the log took 196 writes per second while the RAIDZ2 took 89:
logs - - - - - -
scsi-0QEMU_QEMU_HARDDISK_slog1 10.4M 3.74G 0 196 0 1.54MRun the same test without sync and the log stays at zero operations, because every write goes to the RAIDZ2 at the transaction group commit:
logs - - - - - -
scsi-0QEMU_QEMU_HARDDISK_slog1 8K 3.75G 0 0 0 0NFS exports, iSCSI zvols, databases and VM disks issue sync writes; media libraries and SMB file copies mostly do not. If your log column stays at zero, skip the SLOG and spend the money on disks, such as the ones in our NAS hard drive guide.
Step 2: Add and size the SLOG
Adding a log is one command, and unlike a special vdev on RAIDZ it can always be removed again, even from a RAIDZ2 pool:
sudo zpool add tank log /dev/disk/by-id/scsi-0QEMU_QEMU_HARDDISK_slog1Use the /dev/disk/by-id/ name of your own drive. In round one, with the flush-honoring log, a mirrored log performed the same as a single log within noise, so mirror it for availability, not speed.
Size it small. The OpenZFS workload tuning page says only about 4GB is needed, and no larger than the maximum ARC if a workload needs more. Our log held 10.5 MB during steady sync runs and 139 MB at about 70 MB/s of sync writes, roughly throughput times the seconds between transaction group commits. The dirty data limit (about 410 MB on this 4 GiB VM) caps how much unsynced data, and so log content, can pile up. A 375GB Optane is therefore mostly spare area, which is fine because it adds endurance.
Step 3: Plan the special vdev redundancy
A special vdev holds pool metadata, so losing it loses the pool. zpoolconcepts(7) says its redundancy should match the pool, and ZFS enforces that. A 2-way mirror on our RAIDZ2 pool was refused:
invalid vdev specification
use '-f' to override the following errors:
mismatched replication level: pool and new vdev with different redundancy, raidz and mirror vdevs, 2 vs. 1 (2-way)A 3-way mirror was accepted, so budget three special SSDs for a RAIDZ2 pool:
sudo zpool add tank special mirror /dev/disk/by-id/scsi-0QEMU_QEMU_HARDDISK_spec1 /dev/disk/by-id/scsi-0QEMU_QEMU_HARDDISK_spec2 /dev/disk/by-id/scsi-0QEMU_QEMU_HARDDISK_spec3Treat that as permanent on RAIDZ. zpool-remove(8) does not allow removing a top-level vdev from a pool with RAIDZ vdevs, and our attempt failed:
cannot remove mirror-5: invalid config; all top-level vdevs must have the same sector size and not be raidz.On an all-mirror pool the same removal worked and copied 16.8M back to the data vdevs, with all 50,000 test files still present. Metadata written before the special vdev existed stays where it was, so add it when the pool is new or rewrite the data afterwards.
Step 4: Decide on special_small_blocks
With the default settings, the special vdev holds metadata (plus the ZIL when there is no log, see Step 5), and the metadata is small. These are the sizing numbers from our pool:
- Small files: about 344 bytes of metadata per 4 KiB file (65.7 MiB for 200,000 files)
- Large files at recordsize=128K: 0.78 MiB of metadata per GiB of data
- Large files at recordsize=16K: 5.5 MiB per GiB
Metadata alone made the cold walks fast: find dropped from 10.32 s to 0.38 s, find -ls from 10.33 s to 1.66 s, and creating the 200,000 files from 28.29 s to 6.23 s. The gain is SSD-class special disks set against throttled hard-drive-class data disks, which is the layout a real special mirror creates. Setting special_small_blocks also moves small data blocks onto the SSDs. We created the test dataset with it:
sudo zfs create -o special_small_blocks=16K tank/smallOn an existing dataset, zfs set applies the same property to new writes only. Keep the value below the recordsize: at or above it, every data block goes to special, which is the fastest way to fill the mirror.
With it set, the same 200,000 files added 847 MiB to the special vdev, and a cold read of all of them took 19.3 s instead of 250.2 s on the RAIDZ2. A 64 MiB file with 128K records stayed on the RAIDZ2.
Watch the fill level. Our special vdev stopped taking small blocks at 77.1% full, because ZFS reserves 25% for metadata, and new small blocks went to the RAIDZ2 without an error. That spill is silent, so size the special mirror for the small blocks you expect, not just the metadata.
Step 5: Know what OpenZFS 2.4 does with no log device
On OpenZFS 2.4, a pool with a special vdev and no log device puts the ZIL on the special vdev. That is why the table shows 2,198 IOPS for 4K sync writes with special present and no log, 20 times the plain pool. Our special disks had cheap flushes, so 2,198 is what a PLP-class special mirror gives; consumer SSDs without PLP would likely land nearer the flush-honoring 252 IOPS row (not measured).
Setting the zil_special_is_slog module parameter does not move the ZIL back to the hard drives; in our lab the ZIL blocks stayed on special even with it set to 0 after an export and import. What it controls is whether the data of large sync writes is copied into that ZIL. For 1M sync writes the default of 1 gave 18.5 to 25.8 MiB/s across two runs, and 0 gave 6.3 MiB/s with the data written straight to the RAIDZ2.
So on 2.4, special-vdev drives absorb sync-write wear as well as metadata. Give them PLP and real endurance, or add a dedicated SLOG, which always takes the ZIL ahead of special; with both present, the log took 8,930 writes per second and special 19.
What to watch after you add the SSDs
Your SSDs only pay off if the right traffic reaches them, and three numbers tell you whether it does:
- Log write ops in zpool iostat -v: zero means the workload is async and the SLOG is idle
- Special CAP in zpool list -v: plan to expand before 75%, where small blocks start to spill
- Special write ops on 2.4 without a log: high counts mean the special drives are taking the ZIL
For the pool layout itself, our RAIDZ2 width guide covers vdev width, and the ZFS RAID levels guide compares mirrors and RAIDZ. A Proxmox Backup Server datastore is a good special vdev candidate, as our PBS box build explains, and our NVMe for Proxmox guide covers PLP drives for VM storage.
