Date: Mon, 13 May 2019 13:24:54 +0000 From: bugzilla-noreply@freebsd.org To: fs@FreeBSD.org Subject: [Bug 237807] ZFS: ZVOL writes fast, ZVOL reads abysmal... Message-ID: <bug-237807-3630-JSXNdhNe8R@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-237807-3630@https.bugs.freebsd.org/bugzilla/> References: <bug-237807-3630@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D237807 --- Comment #6 from crest@rlwinm.de --- There are three caching levels (all, metadata, none). At the default level = of all metadata and data get cached. This offers the best performance in most cases, but it can become a problem if it leads to double buffering (e.g. on= a VM host with data being cached once by the host and again by the guest OS). This can cause both caches to fight for resources. Disabling all caching requires ZFS to walk the B-tree on disk for every access which is very slow. Limiting caching to metadata is a compromise between the two extremes. Limi= ted to metadata caching ZFS caches everything but the actual data. This avoids = the need to (re-)read metadata from disk without double caching. The rule of thumb is to cache data just once per physical system as close to the user as possible (it's better to cache inside a VM than outside of it). Also keep in mind that the L2ARC is a pure victim cache. If the primary cac= he is limited to metadata it will never contain anything but metadata to be evicted to the secondary cache. Can you tell us more about your setup? What are the ZVOLs used for? What el= se is running on the system? --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-237807-3630-JSXNdhNe8R>