From owner-freebsd-fs@freebsd.org Tue May 17 21:11:25 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 8A665B3F2D6 for ; Tue, 17 May 2016 21:11:25 +0000 (UTC) (envelope-from steven@multiplay.co.uk) Received: from mail-wm0-x22f.google.com (mail-wm0-x22f.google.com [IPv6:2a00:1450:400c:c09::22f]) (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 15BB019FD for ; Tue, 17 May 2016 21:11:24 +0000 (UTC) (envelope-from steven@multiplay.co.uk) Received: by mail-wm0-x22f.google.com with SMTP id g17so50917814wme.1 for ; Tue, 17 May 2016 14:11:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=multiplay-co-uk.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=18HaE95cOAcNXvLcgKRPFkuzI+tn9EgBFp0adEt+bLM=; b=YS/lDuk7Jwu3N2EsuJ4/VFu60UCK20GpgHV9LTqiw/AhwGwJnbNGW9Q7eTpFxbVHyy tV+tzTNYJGG1duBa2R3QQunJwgP2WSytUmWSjLyt2KTHbbzsxEYZbPFaicnFbhTBB7C2 0Nxxz7JTgyLzAZyO382/5cP9IkAmutNg3fhj3yZZxbCzgUDouUj0esrPCK08pmiwLY+x 7iCgd73li5/H8I1+Unr8NvSdgyq6Z8v9hcnqGDteu8I3Y3eDy6mPAJFhVYkDLb/a5mMO fDxKDKeY+iqe+EIII7HiOf5WIlF+T3QXuWACDuqgqkVwyOLhs/ZA3AQ1LRgXkALZ7Yv8 2sqw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=18HaE95cOAcNXvLcgKRPFkuzI+tn9EgBFp0adEt+bLM=; b=Kcg7Rql9vGP9LQwwtuPWcSrS7lu0RIwnJacIrH54jUmoMZ2pn4sVfcBCV7p+oUt0rX v2cvzaxH4KW2iqKe5oqDbcGK92AZSyhvTqsHCKRr+ZHvqQVq8oCZhVYmEC7wYtzTe3E3 3knms84pJ2IYFJN6LD3Ty2EyWyjtCplnX+3mDQ+Ny/weFiNfuKCEHq8zx7z2dI+Gnk8r Gd0OC6liQaLkGTDcSxJEpKmzHFv1VMfx/VKiFQg0K6vio6tkJBDQ/UrqxO4lOPVHzsQ4 4VZqGS9X3BVXKU9di1YJ2NRAJJIvQwuZwAvbPcW5K26DlYQofPCBMKP2AKZRCJTEG2c5 4Qkg== X-Gm-Message-State: AOPr4FWICj2RBIai881B0XxcNPvt4doGJEtSoW3ooHJOIkRWBzOQx+cD+Njx8p8i7xVHRFHA6HPopTv9Tr/IYlwa MIME-Version: 1.0 X-Received: by 10.194.139.104 with SMTP id qx8mr3425725wjb.14.1463519483422; Tue, 17 May 2016 14:11:23 -0700 (PDT) Received: by 10.28.93.203 with HTTP; Tue, 17 May 2016 14:11:23 -0700 (PDT) In-Reply-To: <86shxgsdzh.fsf@WorkBox.Home> References: <8441f4c0-f8d1-f540-b928-7ae60998ba8e@lexa.ru> <16e474da-6b20-2e51-9981-3c262eaff350@lexa.ru> <1e012e43-a49b-6923-3f0a-ee77a5c8fa70@lexa.ru> <86shxgsdzh.fsf@WorkBox.Home> Date: Tue, 17 May 2016 22:11:23 +0100 Message-ID: Subject: Re: ZFS performance bottlenecks: CPU or RAM or anything else? From: Steven Hartland To: "Brandon J. Wandersee" Cc: Alex Tutubalin , "freebsd-fs@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.22 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 May 2016 21:11:25 -0000 Raidz is limited essential limited to a single drive performance per dev for read and write while mirror is single drive performance for write its number of drives for read. Don't forget mirror is not limited to two it can be three, four or more; so if you need more read throughput you can add drives to the mirror. To increase raidz performance you need to add more vdevs. While this doesn't have to be double i.e. the same vdev config as the first it generally a good idea. Don't forget that while it rebalances write performance of a multi vdev raidz will be limited to the added vdev. On Tuesday, 17 May 2016, Brandon J. Wandersee wrote: > > Alex Tutubalin writes: > > > On 5/17/2016 3:29 PM, Daniel Kalchev wrote: > > > >> Not true. You can have N-way mirror and it will survive N-1 drive > failures. > > I agree, but 3-way mirror does not looks economical compared to raidz2. > > If you're already planning for multiple simultaneous drive failures, > "economical" isn't really a factor, is it? Those disks have to get > replaced regardless of the redundancy scheme you assign to them. ;) > > Whether the concern is performance or capacity, mirrors will offer the > most flexibility. Increasing either the performance or capacity of a > RAIDZ pool necessitates either replacing every disk in the pool or > doubling the number of disks in the pool, all at once. Mirrors allow you > to grow a pool and increase/decrease redundancy asymmetrically. True, > four disks in a two-mirror stripe will see you restoring a backup if one > disk from each mirror dies, but (arguably) six disks in a two-mirror > stripe offer both better redundancy and better performance. > > Speaking strictly about performance, RAIDZ performance is pretty much > fixed, while mirrored performance will (I believe) increase slightly as > you add disks and increase greatly as you add vdevs. > > -- > > :: Brandon J. Wandersee > :: brandon.wandersee@gmail.com > :: -------------------------------------------------- > :: 'The best design is as little design as possible.' > :: --- Dieter Rams ---------------------------------- > _______________________________________________ > freebsd-fs@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-fs > To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org > " >