4 ms·
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 drop
by y04nn 5y ago
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.
- magicalhippo 5y ago> 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.
- rincebrain 5y agoI 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/usr/src/uts/common/fs/zfs/special.c https://github.com/Nexenta/illumos-nexenta/blob/release-5.3/... [2] - https://github.com/Nexenta/illumos-nexenta/blob/release-5.3/usr/src/common/zfs/zpool_prop.c#L214 https://github.com/Nexenta/illumos-nexenta/blob/release-5.3/...