From owner-freebsd-bugs@freebsd.org Thu May 30 00:03:25 2019 Return-Path: Delivered-To: freebsd-bugs@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 3B7B215B15CA for ; Thu, 30 May 2019 00:03:25 +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 C2D2A8DBCA for ; Thu, 30 May 2019 00:03:24 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id 78D6515B15C9; Thu, 30 May 2019 00:03:24 +0000 (UTC) Delivered-To: bugs@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 4F96F15B15C8 for ; Thu, 30 May 2019 00:03:24 +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 C2C1D8DBC8 for ; Thu, 30 May 2019 00:03:23 +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 196061DB43 for ; Thu, 30 May 2019 00:03:23 +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 x4U03MuC002711 for ; Thu, 30 May 2019 00:03:22 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id x4U03Mt9002703 for bugs@FreeBSD.org; Thu, 30 May 2019 00:03:22 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: bugs@FreeBSD.org Subject: [Bug 238229] scrub exceeds I/O qlen scrub_max_active limit, causes latency on 11.3-BETA1 Date: Thu, 30 May 2019 00:03:22 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 11.2-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: Sceiemu@md5hashing.net X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: bugs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version rep_platform op_sys bug_status bug_severity priority component assigned_to reporter Message-ID: 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-bugs@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 May 2019 00:03:25 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D238229 Bug ID: 238229 Summary: scrub exceeds I/O qlen scrub_max_active limit, causes latency on 11.3-BETA1 Product: Base System Version: 11.2-STABLE Hardware: Any OS: Any Status: New Severity: Affects Only Me Priority: --- Component: kern Assignee: bugs@FreeBSD.org Reporter: Sceiemu@md5hashing.net I freebsd-update'd an 11.2 pool+system to 11.3-BETA1 for the purpose of see= ing if sequential scrub was implemented and to test if so. During the scrub, I watched the output of iostat -t da -x 1. Usually, the = qlen field remains at a low value related to what was configured in /etc/sysctl.conf. In this case, I started with the default of 2 for vfs.zfs.vdev.scrub_max_active, and tweaked it to 3, and 4. I noticed that while the qlen would often report that same number, if would rise up to as = high as 24 and fluctuate around higher values for seconds at a time. Interactive performance that accessed the disk was noticeably impacted. I noticed this during the actual scrub phase, I did not make note of what was happening du= ring the earlier scan phase. Other items in the sysctl.conf were: vfs.zfs.vdev.async_read_max_active=3D4 vfs.zfs.vdev.async_read_min_active=3D2 vfs.zfs.vdev.async_write_max_active=3D4 vfs.zfs.vdev.async_write_min_active=3D1 vfs.zfs.vdev.sync_write_max_active=3D4 vfs.zfs.vdev.sync_write_min_active=3D2 vfs.zfs.vdev.sync_read_min_active=3D2 vfs.zfs.vdev.sync_read_max_active=3D5 vfs.zfs.top_maxinflight=3D15 The only vdev was a single hard disk, with GELI on the pool partition. The disk controller was standard intel AHCI on supermicro x9 board. It scrubbed 100G in about 45 minutes, which seems reasonable for sequential scrub on this old disk drive. Was this qlen behavior correct, perhaps a side-effect of how sequential scr= ub works? --=20 You are receiving this mail because: You are the assignee for the bug.=