mirror of
https://git.proxmox.com/git/mirror_zfs.git
synced 2024-12-26 03:09:34 +03:00
dde9380a1b
Currently, the `zvol_threads` variable, which controls the number of worker threads which process items from the ZVOL queues, is set to the number of available CPUs. This choice seems to be based on the assumption that ZVOL threads are CPU-bound. This is not necessarily true, especially for synchronous writes. Consider the situation described in the comments for `zil_commit()`, which is called inside `zvol_write()` for synchronous writes: > itxs are committed in batches. In a heavily stressed zil there will be a > commit writer thread who is writing out a bunch of itxs to the log for a > set of committing threads (cthreads) in the same batch as the writer. > Those cthreads are all waiting on the same cv for that batch. > > There will also be a different and growing batch of threads that are > waiting to commit (qthreads). When the committing batch completes a > transition occurs such that the cthreads exit and the qthreads become > cthreads. One of the new cthreads becomes he writer thread for the batch. > Any new threads arriving become new qthreads. We can easily deduce that, in the case of ZVOLs, there can be a maximum of `zvol_threads` cthreads and qthreads. The default value for `zvol_threads` is typically between 1 and 8, which is way too low in this case. This means there will be a lot of small commits to the ZIL, which is very inefficient compared to a few big commits, especially since we have to wait for the data to be on stable storage. Increasing the number of threads will increase the amount of data waiting to be commited and thus the size of the individual commits. On my system, in the context of VM disk image storage (lots of small synchronous writes), increasing `zvol_threads` from 8 to 32 results in a 50% increase in sequential synchronous write performance. We should choose a more sensible default for `zvol_threads`. Unfortunately the optimal value is difficult to determine automatically, since it depends on the synchronous write latency of the underlying storage devices. In any case, a hardcoded value of 32 would probably be better than the current situation. Having a lot of ZVOL threads doesn't seem to have any real downside anyway. Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov> Fixes #392 |
||
---|---|---|
cmd | ||
config | ||
dracut | ||
etc | ||
include | ||
lib | ||
man | ||
module | ||
patches | ||
scripts | ||
udev | ||
.gitignore | ||
AUTHORS | ||
autogen.sh | ||
ChangeLog | ||
configure | ||
configure.ac | ||
COPYING | ||
COPYRIGHT | ||
DISCLAIMER | ||
Makefile.am | ||
Makefile.in | ||
META | ||
OPENSOLARIS.LICENSE | ||
PKGBUILD-zfs-modules.in | ||
PKGBUILD-zfs.in | ||
README.markdown | ||
zfs_config.h.in | ||
zfs-modules.spec.in | ||
zfs-script-config.sh.in | ||
ZFS.RELEASE | ||
zfs.spec.in |
Native ZFS for Linux! ZFS is an advanced file system and volume manager which was originally developed for Solaris. It has been successfully ported to FreeBSD and now there is a functional Linux ZFS kernel port too. The port currently includes a fully functional and stable SPA, DMU, and ZVOL with a ZFS Posix Layer (ZPL) on the way!
$ ./configure
$ make pkg
Full documentation for building, configuring, and using ZFS can be found at: http://zfsonlinux.org