SCALE 25.10 - Is it worth to use SLOG (mirrored) with NVMe drives as primary storage drives

TrueNAS General
, , ,
1

Hi there,

I have planned quite new server which be used for audio postproduction (about 16 workstations connected to it via 10GbE). While planning, I was considering a TrueNAS, although I had no previous experience with it.

Most of the data requests sent/received from the server would be relatively small – not large files typical of video applications, although of course, such files are also used in audio post-production. The Pro Tools (DAW) software that will be used with this server is quite sensitive to data latency, so I tried to find the fastest possible solution within a reasonable budget.

Server platform: AIC SB201-HK; CPU: 2* Intel Xeon 4510 (12 Cores), 128 GB RAM (4*32GB) DDR5, 24* SSD U.2 drive bays; SSD SATA drives (2x) for system.

Primary storage: 12* Kingston SSD DC3000ME 7,68TB PCIe 5.0 NVMe U.2

The motherboard has 2 M.2 slots, so I put 2x KINGSTON 960 GB DC2000B PCIe 4.0 M.2 2280 Enterprise SSDs in there - but of course I overlooked that they were PCIe 4.0 (unfortunately)…

Question 1:

I’m not sure if such a SLOG mirror will help, since write requests (probably) aren’t always synchronized, and such master drives are significantly faster than this SLOG device. I also read here about problems with failed SLOG and thought that maybe it’s better not to use those drives for SLOG, but just as another vdev.

Question 2:

I can create vdev with 12 drives RADZ2 or 2* 6 drives in RAIDZ1. I probably can’t lose more than two disks of capacity. I have also planned one spare drive. From your experience - would it be real difference in such configuration - with NVMe PCIe drives? Maybe some tips about other parameters (recordsize) for setting file server for such application?

Thanks for reading this message from a newbie and for your insight! :slight_smile:

2

Welcome to TrueNAS and the forums!

ZFS SLOG / LOG is not a write cache. Your RAM is the write cache. The way the write cache works, is that whence an asynchronous write is in RAM, the writing application, (Samba), is told the write is complete. Even though the data is not on stable media, like HDDs, SSDs or NVMes.

For synchronous writes, the write is still to RAM, but another copy is written to ZIL, (ZFS Intent Log), which is internal to the data vDevs. Or it is written to external ZIL, aka SLOG, (Separate intent Log), if available. THEN, the writing application is told that the write is done. After that, unless their is a server crash, the RAM copy is eventually written to stable media.

So, using a ZIL or SLOG with synchronous wrtites is almost certainly SLOWER for most users than asynchronous writes.

The benefit is that software like Databases & VMs can be certain a write completed to stable media before moving on to the next write. Those can be highly sensitive to missing, out of order, or damaged writes.

NFS and iSCSI use synchronous writes, which can benefit from SLOG. However, if you are using MS-Windows and Samba / SMB shares, SLOG is of no real benefit.

Failed SLOG is a tricky situation. It only maters if it fails after a crash or power loss, AND it had data in it, AND you did not have the SLOG Mirrored. Basically quite rare, but something an Enterprise Data Center would not bother risking for a cheap Mirror device. (Even if that cheap Mirror device was $10,000… nothing to an Enterprise user.)

But generally, many users don’t need a SLOG. I don’t know about “Pro Tools (DAW)” software, you can research it and see if it uses NFS or synchronous writes.

I can’t advise on your 2nd question… Yes, 2 RAID-Z1 vDevs have more I/O operations per second because both can be doing something at the same time. But, the alternative is that if you loose 2 drives in the same RAID-Z1 vDev, your entire pool is gone. Or, loose 1 drive and have a URE in another disk, you loose a file. (URE = Unrecoverable Read Error)

1 Like
3

Arwen - many thanks for your explanations. Pro Tools (it is just a digital audio workstation application) will use here SMB - not iSCSI or NFS, AFP support was unfortunately dropped by TrueNAS. Probably I have to consider what will be the risk of not saving cache from RAM to stable media.

From what you have explained here - I can assume in case of synchronous writes (if they are used - I have no idea, probably even manufacturer of Pro Tools doesn’t know that:-)) using SLOG will be even slower - as main vdev consists of faster drives, even getting into account some time needed to calculate checksums etc. Taking into account that drives for SLOG which I have are PCIe 4.0 and drives for main vdev are PCIe 5.0, I see there is no reason to use SLOG here.

Again, many thanks for help!