Using a special vdev? No SLOG needed anymore! (Maybe)

[winnielinnie]

OpenZFS 2.4 introduces a new feature that allows using a pool’s special vdev as SLOG as well.

The description make it seem like this feature is handled automatically and seamlessly, such that the user does not need to specify their special vdev to also be used as a SLOG device?

If that’s the case, then the TrueNAS developers don’t need to do anything special? This will happen automatically in the presence of a special vdev?

If someone is already using a mirrored special vdev, then this technically gives their “SLOG” automatic redundancy and reduces or obsoletes the need for extra devices or custom partitioning.

I may not be a user of a special vdev, but for those who are, this looks like a win-win!

[winnielinnie]

@mav This part I am unclear about:

@amotin on GitHub

The code tries to guess whether data block is going to be written to normal or special vdev (it can not be done precisely before compression) and prefer indirect writes for blocks written to a special vdev to avoid double-write. For blocks that are going to be written to normal vdev, special vdev by default plays as SLOG, reducing write latency by the cost of higher special vdev wear, but it is tunable via module parameter.

Why is there any “guessing”? I thought the only rule that determines if the ZIL (or SLOG) is used is whether or not the write is async or sync?

Does this mean that a sync write, even if it’s going to the special vdev because of a dataset “small blocks” policy, will skip the ZIL/SLOG entirely, and just report the write as successful once it commits to the special vdev device?

---

What if the pool already has a SLOG, and then a special vdev is later added? Which device will then be used for sync writes? Does OpenZFS 2.4 “determine” which device is “faster”? If that’s the case, isn’t it possible that the dedicated SLOG device will never be used and should just be removed from the pool?

[mav]

Does this mean that a sync write, even if it’s going to the special vdev because of a dataset “small blocks” policy, it will skip the ZIL/SLOG entirely, and just report the write as successful once it commits to the special vdev device?

No. It will be logged. Sync requires it. The guessing is whether the data are going to be finally written onto normal or special vdev, and respectively whether the special should behave as ZIL (possibly using indirect writes) or as SLOG (double-writing data inline).

What if the pool already has a SLOG, and then a special vdev is later added? Which device will then be used for sync writes?

The decision is made per-allocation. SLOG will always be first, but in case of overflow special will be used, and if also overflown – normal.

[etorix]

@winnielinnie

I may not be a user of a special vdev, but for those who are, this looks like a win-win!

Not necessarily: If the special vdev does not have PLP, a proper SLOG should still be preferred.

[winnielinnie]

Then for all intents and purposes, a user who currently does not have a dedicated SLOG device, but they already have a special vdev, they will see a performance gain when using sync writes (NFS, VMs, sync=always, et al) without any extra configuration?^[1]

If their special vdev is already very fast and redundant, what would be the argument for purchasing and adding a dedicated SLOG?^[2] This assumes that their special vdev device is as fast or faster than what they would have purchased for a SLOG device.

---

1. With OpenZFS 2.4. ↩︎

2. Other than power-loss protection, as @etorix mentioned, which would most likely err towards enterprise users. ↩︎

[mav]

@winnielinnie

If their special vdev is already very fast and redundant, what would be the argument for purchasing and adding a dedicated SLOG?

SLOG has lower redundancy requirements than special vdev (if rollback of few transactions on device failure is acceptable), and they have different performance requirements (special is flushed once per TXG, while SLOG – usually on every write). But if you can afford devices with sync write latency of SLOG (or just any latency better than HDD is fine) and capacity and redundancy of special – sure, you don’t need to have both. Same as it should rarely make sense to have SLOG with SSD-only pool.