From owner-freebsd-fs@freebsd.org Mon May 13 13:24:56 2019 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id AA519158FFFD for ; Mon, 13 May 2019 13:24:56 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 2F6D1817CA for ; Mon, 13 May 2019 13:24:56 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id E724C158FFFC; Mon, 13 May 2019 13:24:55 +0000 (UTC) Delivered-To: fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D4C0A158FFFB for ; Mon, 13 May 2019 13:24:55 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.ysv.freebsd.org (mxrelay.ysv.freebsd.org [IPv6:2001:1900:2254:206a::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.ysv.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 5B3C4817C7 for ; Mon, 13 May 2019 13:24:55 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.ysv.freebsd.org (Postfix) with ESMTPS id 8BDA6867A for ; Mon, 13 May 2019 13:24:54 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id x4DDOs1M031937 for ; Mon, 13 May 2019 13:24:54 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id x4DDOscQ031936 for fs@FreeBSD.org; Mon, 13 May 2019 13:24:54 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: fs@FreeBSD.org Subject: [Bug 237807] ZFS: ZVOL writes fast, ZVOL reads abysmal... Date: Mon, 13 May 2019 13:24:54 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 12.0-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: crest@rlwinm.de X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: fs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 May 2019 13:24:56 -0000 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.=