so i have a zpool, i have a 800GB slog, but not more then 8GB get used when transfering large files. any idea how i might make it use the slog more? because it can be annoying when transfering large file or many files
What is the use case and how is the storage accessed?
NFS most of the times, sync is set to default for zfs
SLOG isn’t supposed to be huge. It’s a buffer, not an alternate storage location.
It sounds like you either want to set your NFS asynchronous, or zfs set sync=disabled pool/nfsdataset. What you have to remember here is that everything that gets written to SLOG also has to get copied into the main pool… So even if you could manage to get more than 8GiB of data into your LOG vdev, it wouldn’t likely be much of a performance win, because it would need to still dump every last bit of that onto the storage vdevs also.
If you don’t trust your NFS server to run asynchronously–and I’m honestly not sure whether you should or not–the only other way to remove the performance hit of sync writes is a hardware swap. If you use enterprise grade SSDs with power loss protection, they can return instantly from a sync call, because their power loss protection is sufficient to call the DRAM cache “non volatile” since the PLP will keep it hot until the drive regains power and can then commit the cache to the metal.
Before we go any farther, though… Can you describe any actual problem you’re having, along with the metrics to quantify it?
i know it aint a alternative, it’s that it bothers me a bit when i transfer a 30gb file i see it go from 500mb to 240mb a second when the log gets around 8gb full, i am using enterprise ssd’s as well, 1gb a second write. i have two mirrored to each other. there is nothing really wrong, i just dont get why if it has so much space avalible why it wont use it
By default zfs flushes transactions every five seconds, so from there you can guess how much space will get used on your ZIL SLOG based on how fast you can write out to your pool.
Most folks SLOGs are way smaller than 800GB, you just need to size it to be large enough to hold transactions until they get flushed out to the main pool. You could increase the transaction timeout zfs_txg_timeout parameter and see what happens but that comes with its own risks and caveats.
Your prior posts indicated you upsized mirror ZIL SLOGs, too. What’s your pool layout, and what are you trying to accomplish?
my pool layout is 2 26tb WD red nas pro drives, 2 intel dc3700p 800gb (could be wrong been a little while.)
how do i set the time value?
First, about your pool: I’m assuming your layout is a mirror vdev? WD specifies the max transfer rate at ~270MB/sec (presumably on the outer sectors), and that’s more or less the speed you’re seeing. ZFS is behaving as designed.
Makes sure you understand exactly how ZFS is writing. Our host has a nice page about how the ZIL works. The ZIL is not a write buffer, it’s not a write cache, it’s a safety thing for sync writes. It is not tiered storage in which you write out fast to the SSDs and then at some point in the background it gets copied to your slow disk pool.
Now, the DC3700 are good drives, with power loss protection, low latency, all the good stuff. If you are willing to risk more in-flight data being lost if somehow that mirrored ZIL SLOG fails before stuff is written to the pool, you can do this. But note that zfs_txg_timeout affects async writes, too, and you might not want that. Those writes aren’t sent to your ZIL, they just live in memory, and are you okay with possibly losing however many seconds of data are aggregating in RAM if the power goes out?
Tuning zfs_txg_timeout varies per operating system; see your OS or distribution’s documentation for more details.
1 Like
I thought it was a write cache…
Yes it is mirrored.
Am on nixos
edit: i also wasn’t planning on a large slog, it’s that i could only get my hands on the 800gb ones
edit2:i cant find how to change it for my operating system
Have you checked: