From owner-freebsd-bugs@freebsd.org Sat May 19 11:15:14 2018 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 F2E85EAA2B5 for ; Sat, 19 May 2018 11:15:13 +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 721E16B9EE for ; Sat, 19 May 2018 11:15:13 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id 2BAA9EAA2B4; Sat, 19 May 2018 11:15:13 +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 17A7EEAA2B1 for ; Sat, 19 May 2018 11:15:13 +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.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mxrelay.ysv.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A51AC6B9E6 for ; Sat, 19 May 2018 11:15:12 +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 DE2569C8A for ; Sat, 19 May 2018 11:15:11 +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 w4JBFBNG013146 for ; Sat, 19 May 2018 11:15:11 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id w4JBFB5t013145 for bugs@FreeBSD.org; Sat, 19 May 2018 11:15:11 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 228359] rebuild gmirror + ufs + ssd +trim Date: Sat, 19 May 2018 11:15:11 +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.1-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: freebsd@ihead.ru 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.26 Precedence: list List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 May 2018 11:15:14 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D228359 Bug ID: 228359 Summary: rebuild gmirror + ufs + ssd +trim Product: Base System Version: 11.1-RELEASE Hardware: amd64 OS: Any Status: New Severity: Affects Some People Priority: --- Component: kern Assignee: bugs@FreeBSD.org Reporter: freebsd@ihead.ru Assume the situation. Have gmirror with 2 ssd components (ada0, ada1). UFS over gmirror. One component (e.g., ada1) becomes broken and should be replaced. gmirror forget gm0 replace broken drive with new one gmirror insert gm0 ada1 gmirror rebuid gm0 ada1 (if autosync was disabled) Wait some time until synchronization done. Now what we have? ada0 fine, but ada1 is fully dd'ed. From drive side ada1 is fully written. Now we start write large volume of data to fs, and see (systat -vmstat) that ada1 performs poorly (low write speed, high busy percentage). When we remove large file from fs, TRIM is sent to ada1 and it begin perform better (on new big write, hight write speed, less busy percentage). Now the question. Is there a way to send TRIM commands to ada1 after rebuild according UFS st= ate to allow drive know what "regions" should be considered as currently unused? The way I found: is to create a large file and to delete it, but it is not good, because of low overall performance during creation of a file. --=20 You are receiving this mail because: You are the assignee for the bug.=