Re:Demystifying OpenZFS 2.0
by y04nn on Thursday November 18, 2021 @12:46PM
(#29268249)
That explains the results I've got last week when I was doing some tests on an slow external HDD and a SLOG file placed on my internal SSD, the write speed dropped much faster that I expected. I found it disappointing that ZFS needs to keep the data in RAM and on the SLOG dev. You really need a lot of RAM to make full use of it. And a larger SLOG dev than RAM space available makes no sense then? A real write cache would be awesome for ZFS.
[ Parent
| on HN ]
Re:Demystifying OpenZFS 2.0
by magicalhippo on Thursday November 18, 2021 @06:03PM
(#29271728)
> And a larger SLOG dev than RAM space available makes no sense then?
Exactly, and it's even worse. By default ZFS only stores about 5 seconds worth of writes in the ZIL, so if you have a NAS with say a 10Gbe link that's less than 10GB in the ZIL (and hence SLOG) at any time.
> A real write cache would be awesome for ZFS.
Agreed. It's a real shame the write-back cache code never got merged, I think it's one of the major weaknesses of ZFS today.
Re:Demystifying OpenZFS 2.0
by rincebrain on Friday November 19, 2021 @02:01AM
(#29274547)
I haven't tried Nexenta in a long long time, but it seems like it was part of their allocation classes code [1]. The comment at the top of the file says the implementation there doesn't support WBC, but [2] seems to suggest otherwise...
So if you really wanted to, you could try looting code from there, though I believe Nexenta's implementation of that was either orthogonal or significantly different from the one that landed in OpenZFS...
[1] - https://github.com/Nexenta/illumos-nexenta/blob/release-5.3/...
[2] - https://github.com/Nexenta/illumos-nexenta/blob/release-5.3/...