I'm trying to understand this part of the conversation properly, too: can it be summarized: the OP is not using sync writes so when he/she started using sync writes and a SLOG the performance would drop because of the sync writes despite the SLOG... ( ? ) And sync writes without a SLOG would be terrible in terms of performance but sync writes with a SLOG would still be slower than non-sync writes without the SLOG in this case?
I suspect that the informative speed comparisons are sync vs async writes and SLOG vs no SLOG. Comparing sync writes with SLOG vs async writes of any kind seems to only be informative of sync vs async writes and not really about the SLOG. This is because of the extremely different ways in which sync and async writes behave.
I think a relevant takeaway is that if you're going to use sync writes with a SLOG you should use an appropriate SLOG, such as a one with PLP. If you do not, you might as well use async writes since using a SLOG without PLP defeats much of the purpose of sync writes. To quote from jreco
With reasonable workflows I think one would expect async writes with SLOG|without SLOG to be the fastest, followed by sync writes with an appropriate SLOG, followed by sync writes where the ZIL lives in the pool.
Writes to the pool are *always* handled through the pool transaction group mechanism and this represents the maximum possible performance for the system. This also happens to be the exact data flow for async writes.
Sync writes do exactly the same thing, except that before the write returns success to the user, it *also* calls an additional function to commit the transaction to the ZIL/SLOG.
To my way of thinking, that means "extremely different ways" is a poor way to describe it, because functionally they are extremely similar, except that sync writes add one more step, one that requires a complete traversal of all the steps needed to commit the data to storage, which is generally a slow-ish operation.
The one more step is always going to take more time. The poster was talking about having an SSD without power loss protection acting as a SLOG, which doesn't have the correct characteristics to act as a SLOG. Therefore the best course of action would be just to ditch that, and gain back the unnecessary loss of speed. Ditching the additional step is *always* faster.
That might be the wrong way to think about it.
The poster was talking about having an SSD without power loss protection acting as a SLOG, which doesn't have the correct characteristics to act as a SLOG. Therefore the best course of action would be just to ditch that, and gain back the unnecessary loss of speed. Ditching the additional step is *always* faster.
What I've learnt from this conversation and linked posts is that actually, no slog at all and "sync writes off" is the fastest way to write data, although the trade-off is "risk to data in power loss scenario", and that if I want the full protection that ZFS can offer, then I need a slog that has the ability to protect against power lose....
I have seen a lot of people praising optane, and although the ARK page on intel's site state they don't have PLP, because they write directly to storage (no DRAM buffer ech), that these can make good SLOG drives?
The problem I have is justifying the cost of a 280Gb PCIe optane drive as a Slog knowing that probably less than 10Gb will ever be used at any one time... (I know it'll aid wear levelling as its not actually the same 10Gb that gets used over and over) So i'm not researching the metrics of partitioning it up for use as a SLOG and L2ARC...
Its actually a radiator bracket (steal i think) i had spare from installing my water cooled graphics card in my PC.... So its abit of a bodge.... the tape on the end is just to ensure it doesn't short against anything.
In other news... the migration of data off of my Synology box has been completed, so the 6 reds could come out and be added to two more white label (but in essence the same reds) and be added into my chassis in Raid2Z! Threw in a 240Gb Sandisk SSD as a L2ARC for good measure.