On Wed, 17 Feb 2021 19:04:34 -0500 Greg Troxel <g...@lexort.com> wrote:
> > Sad Clouds <cryintotheblue...@gmail.com> writes: > > > On Wed, 17 Feb 2021 13:15:39 -0500 > > Greg Troxel <g...@lexort.com> wrote: > > > >> > >> Suppose I create a 16G zvol on a pool that is a disklabel > >> partition on an SSD. I would expect read/write performance that > >> is near the native SSD read/write speed. > > > > Why would you expect that? In other words, you're expecting that a > > complex file system like ZFS would have near zero overheads, which > > is not possible. When you take into considerations things like > > checksums, compression, encryption, etc, then the overheads could > > be quite significant. > > I have not enabled compression or encryption, and I forgot about > checksums. > > However, the use case for zvol is having zfs being a logical volume > manager, and it would seem reasonably feasible to get high > efficiencies via allocation of large numbers of blocks at once. So > 10-20% slower wouldn't surprise me. > > Have you used zvols? What was your experience? Not used it on NetBSD. Used a bit on Solaris and Linux at home, but never really cared about throughput performance. My personal feeling about ZFS - it's designed to provide good data integrity, but a bit complicated and has too many features/options. I prefer simpler designs. With regard to zvols, the following is normally recommended for Linux swap: zfs create -V 8G -b $(getconf PAGESIZE) \ -o logbias=throughput -o sync=always -o checksum=off \ -o compression=off -o dedup=off -o primarycache=metadata \ -o com.sun:auto-snapshot=false <pool>/swap Also, several tuning options for "zfs create": atime=off - Disable atime updates. recordsize=16K - For small files and random I/O. recordsize=1M - For large files and sequential I/O. xattr=sa - Linux only, store xattr directly in inodes.
