From owner-freebsd-fs@freebsd.org Tue Apr 26 17:25:20 2016 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8E0B1B1D303 for ; Tue, 26 Apr 2016 17:25:20 +0000 (UTC) (envelope-from brandon.wandersee@gmail.com) Received: from mail-io0-f196.google.com (mail-io0-f196.google.com [209.85.223.196]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 65D9F1026 for ; Tue, 26 Apr 2016 17:25:20 +0000 (UTC) (envelope-from brandon.wandersee@gmail.com) Received: by mail-io0-f196.google.com with SMTP id k129so3009650iof.3 for ; Tue, 26 Apr 2016 10:25:20 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:references:user-agent:from:to:cc:subject :in-reply-to:date:message-id:mime-version; bh=Pw1um7OqUWHx6jgNb1q2I2T9sb1HhvnRkQf5HNPGFWo=; b=Hy+SjD8qjLemvohMxMOoBRLblYSInlvPHge+vVhLsSfRPNY+58EFfjUQR/LFL8y95A QmO9oSAKTD1wOADZ9KsnMvpHbgTg6dLc8zxo58T4PJzTdOso1zbYoxL+BMm6YIoHTF9e Y7O4N+ARELOhsuRpwF+asyoC+LqkvjfjNgYRKwaxNZu/jZtTiuqprKs8KBleerXQqtyo +wkUAFV6flUlujHHuqZtrcN90eNA+u5UUiZFI7hEzrDdbuc4aC/eoBQDrH2Ws4mols4r AkJtMxaebLo+Wo+jm56ySaGkm3eM9cc6iVk59r/v3bp/mSwFsBFY68jQg29MPjYMUGrj UAIw== X-Gm-Message-State: AOPr4FVAobkHMLrsOLU2mL0rCIkFQEXHtS8t69jRptVpXbfy+1oAJAewWwjwnpgAZwBcaw== X-Received: by 10.107.15.15 with SMTP id x15mr5008595ioi.139.1461690720480; Tue, 26 Apr 2016 10:12:00 -0700 (PDT) Received: from WorkBox.Home.gmail.com (63-231-164-200.mpls.qwest.net. [63.231.164.200]) by smtp.gmail.com with ESMTPSA id cy7sm2045879igc.17.2016.04.26.10.11.58 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 26 Apr 2016 10:11:59 -0700 (PDT) References: <571F62AD.6080005@quip.cz> <571F687D.8040103@internetx.com> <571F6EA4.90800@quip.cz> <571F7AED.2040500@quip.cz> User-agent: mu4e 0.9.16; emacs 24.5.1 From: Brandon J. Wandersee To: Miroslav Lachman <000.fbsd@quip.cz> Cc: krad , FreeBSD FS Subject: Re: How to speed up slow zpool scrub? In-reply-to: <571F7AED.2040500@quip.cz> Date: Tue, 26 Apr 2016 12:11:57 -0500 Message-ID: <86lh409twi.fsf@WorkBox.Home> MIME-Version: 1.0 Content-Type: text/plain X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Apr 2016 17:25:20 -0000 Miroslav Lachman writes: > krad wrote on 04/26/2016 16:02: >> Erk, i would try to move your system off those data disks as you have >> two pools competing for the disk spindles. This is never ideal. You can >> by all means backup your os to those data pools but keep them on >> separate physical mediums. A couple of small SSD would do the trick >> nicely and could probably be added with no down time. You would probably >> want to find a suitable window though to make sure the box reboots >> nicely though. > > The system pool is really small - only 15GB and scrub is done relatively > fast. This machine cannot handle additional disks so I cannot move > system to other devices anyway. I tried system on USB flashdisk (read > only) in the past but it was slow and USB disk broke early. > I see no sign that the partitions are encrypted, so I can't think of a reason that the system and data can't reside on the same pool. The physical effort of the read arms on the disks isn't the only resource to consider---each pool has its own ARC, for example, and if you have compression enabled each pool will compete for CPU cycles. Having two pools grabbing at such limited resources is going to noticeably hurt performance. All that said, running even a single relative large pool on a low-powered dual-core CPU and 5G of RAM will noticeably limit *every* ZFS operation. I would bet that while you might be able to shave some time off the scrub, at best it's still going to take at least an entire day on that hardware. As a side note, I'm not so sure it's a good idea to use two different redundancy methods on the same set of disks, though I can't say exactly what the downsides would be (if any). It just seems odd. -- :: Brandon J. Wandersee :: brandon.wandersee@gmail.com :: -------------------------------------------------- :: 'The best design is as little design as possible.' :: --- Dieter Rams ----------------------------------