ZFS What value of sync is better for a swap on zvol?

A

Annalesa

sync=disabled or sync=always; logbias=throughput?
I saw
Fixit# zfs create -V 2G -o org.freebsd:swap=on -o checksum=off -o compression=off -o dedup=off -o sync=disabled -o primarycache=none zroot/swap
in the freebsd wiki.
https://wiki.freebsd.org/RootOnZFS#ZFS_Swap_Volume
and I also saw $ zfs create -V 4G -b $(getconf PAGESIZE) \
-o logbias=throughput -o sync=always \
-o primarycache=metadata \
-o com.sun:auto-snapshot=false rpool/swap
in the FAQ of openzfsopenzfs, but it's for linux.
https://openzfs.github.io/openzfs-d....html#using-a-zvol-for-a-swap-device-on-linux
 
no log, no sync, no cache, no checksum - if the system is already under memory pressure you just want to get that data on there as fast as possible with the lowest overhead - disks are already abysmally slow compared to RAM.
Yes, also NVMe/PCIe is already an order of magnitude slower, let alone SAS/SATA SSDs or - god beware- spinning rust (just don't use that for swap!)

compression is debateable - on a halfway decent CPU compression usually gives better throughput as those slow disks have to deal with less data. I'd say if this system isn't some glorified doorstopper nicked from a museum junkyard, always use compression
 
I suspect that "-o logbias=throughput -o sync=always" is correct - if only because it's not the sort of thing that someone would suggest if their knowledge were shallow.

I presume the point of it is to speed-up the release of buffers, sync=disabled tells ZFS that there's no hurry.
 
Avoid swap on zpool/zfs as that may lead to deadlocks. Use a disk partition or a separate disk for swap. Also, if possible adjust your workload (such as "make -j <N>") to avoid swapping. Though this is difficult. Even with 64GB machine "make -j6 buildworld" (on a 8 core, 16 hypeprthreads) my system swap some as llvm/lld are hogs.
 
AI,
sync=disabled
Maximize write speed and bypass the ZIL
Bypasses the ZIL entirely; data is committed in normal transaction groups (TXGs).
Highly stable native integration; very low risk of deadlock.
 
If it's mainly used for hibernation, how should the value of sync be set? Although hibernation is currently unavailable on my computer, it might come in handy someday. Maybe the 15.1
 
For hibernating, saving the entire state of memory would be last thing the system has to do before shutting down so i suppose the sync state doesn’t matter. It has to ensure everything is synced. But even here, restoring from a partition would be far easier and likely to be less error prone.
 
Alain De Vos said:
AI,
sync=disabled
Maximize write speed and bypass the ZIL
Bypasses the ZIL entirely; data is committed in normal transaction groups (TXGs).
Highly stable native integration; very low risk of deadlock.
Click to expand...
The point of sync=disabled is to lie to code that requires an assurance that data has been committed to non-volatile storage, and to do buffered asynchronous writes instead. Lying to the VM system achieves nothing, and buffering swap writes is counterproductive.

What I think this is about, is that -o logbias=throughput -o sync=always , causes swap writes to be written directly to a txg, but as synchronous writes they close their txg allowing an immediate write to the pool. This isn't likely to have much effect under thrashing, but it may help the VM system to page more smoothly.
 
bob2112 said:
I don't see any point to that.
Click to expand...
Agreed.

Below is a script I use to add a swap, should I need it, to a zpool. This is typically used on machines with internal SSDs, where I put swap on an external device or spinning disk to avoid unnecessary writes to SSD.

sh: 
#!/bin/sh -

# -b 4096 \
zfs create -b 16384 \
        -o org.freebsd:swap=on \
        -o checksum=off \
        -o primarycache=metadata \
        -o compress=off \
        -o dedup=off \
        -o sync=disabled \
        -o snapshot_limit=0 \
        -V $2 $1/SWAPVOL

There's no sense caching swap to RAM. Though some Linux systems I maintain at $JOB use a compressed RAM disk for swap, similar to what one might use ESTOR on an IBM mainframe for. But that's a separate topic.
 
You must log in or register to reply here.
Back
Top