From owner-freebsd-fs@FreeBSD.ORG Wed Jul 17 18:22:33 2013 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 177447B6 for ; Wed, 17 Jul 2013 18:22:33 +0000 (UTC) (envelope-from gezeala@gmail.com) Received: from mail-la0-x22c.google.com (mail-la0-x22c.google.com [IPv6:2a00:1450:4010:c03::22c]) by mx1.freebsd.org (Postfix) with ESMTP id 8CB5D224 for ; Wed, 17 Jul 2013 18:22:32 +0000 (UTC) Received: by mail-la0-f44.google.com with SMTP id er20so1795395lab.31 for ; Wed, 17 Jul 2013 11:22:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=yaEL1JjazyUBwi1Dsigqj7eHj8ZWc7148BhP83wQ7BM=; b=ZTA6qiWTLmMNVUI5c+7Fkja23IZE6aO4a7KjD2KZMsu/k3DrxpD1/fjROAhn6YPwJb VqukGDCxkvnDyXfPatndid7BcJmNNKKXjcJIoyEZKuoHXCJwBQDLTs58Q38wdm2IfLaN +jPf9lekFuwmUjXfilxYB3s+2jdytGg3LklV3bl38suNuDYOfyHowAD3XHJYDWEDH9rO 17LHK25wRVbjVQrrJ8sdieeOglbrmBc4H40J5zS91ORv/IzjXFpKYfJkr1eRG0l+t/Od xqEsQo2iGlaZQIiszI+dwjotHw1UrSZNeBAjEE0iXR7YzhS3QuXGM52hujc8UNquFBIp JqTQ== X-Received: by 10.112.51.16 with SMTP id g16mr3707852lbo.0.1374085351426; Wed, 17 Jul 2013 11:22:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.114.82.72 with HTTP; Wed, 17 Jul 2013 11:21:51 -0700 (PDT) In-Reply-To: References: <2EF46A8C-6908-4160-BF99-EC610B3EA771@alumni.chalmers.se> <51D437E2.4060101@digsys.bg> <20130704000405.GA75529@icarus.home.lan> <20130704171637.GA94539@icarus.home.lan> <2A261BEA-4452-4F6A-8EFB-90A54D79CBB9@alumni.chalmers.se> <20130704191203.GA95642@icarus.home.lan> <43015E9015084CA6BAC6978F39D22E8B@multiplay.co.uk> <3CFB4564D8EB4A6A9BCE2AFCC5B6E400@multiplay.co.uk> <51D6A206.2020303@digsys.bg> From: =?ISO-8859-1?Q?Gezeala_M=2E_Bacu=F1o_II?= Date: Wed, 17 Jul 2013 11:21:51 -0700 Message-ID: Subject: Re: Slow resilvering with mirrored ZIL To: Warren Block Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: FreeBSD Filesystems X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jul 2013 18:22:33 -0000 On Wed, Jul 17, 2013 at 10:35 AM, Warren Block wrote: > On Wed, 17 Jul 2013, Gezeala M. Bacu=F1o II wrote: > > If ZFS goes on a bare drive, it will be aligned by default. If ZFS is >> going in a partition, yes, align that partition to 4K boundaries or larg= er >> multiples of 4K, like 1M. >> >> Your statement is enlightening and concise, exactly what I need. Thanks. >> >> The gnop/ashift workaround is just to get ZFS to use the right >> block size. So if you don't take care to get partition alignment right, >> you might end up using the right >> block size but misaligned. >> >> And yes, it will be nice to be able to just explicitly tell ZFS th= e >> block size to use. >> >> >> We do add the entire drive (no partitions) to ZFS, perform gnop/ashift >> and other necessary steps and then verify ashift=3D12 through zdb. >> >> The gpart/gnop/ashift steps, if I understand correctly (do correct me if >> I'm stating this incorrectly), is needed for further SSD performance >> tuning. Taking into consideration leaving a >> certain chunk for wear leveling and also if the SSD has a size that may >> be too big for L2ARC. >> > > Well, there are several things going on. > > Partitions can be used for a couple of things. Limiting the size of spac= e > available to ZFS, leaving an unallocated part of the drive for wear > leveling. Note that ZFS on FreeBSD now has TRIM, which should make leavi= ng > unused space on SSDs unnecessary. > > Aligning partitions preserves performance. If a partition is misaligned, > writes can slow down to half speed. For example, a 4K filesystem block > written to an aligned partition writes a single block. If the partition i= s > misaligned, that 4K write is split over two disk blocks. Each block has = to > be read, partly modified, then written, taking roughly twice as long. > > Finally, ZFS's ashift controls the minimum size of block ZFS uses. > ashift=3D12 (12 bits) sets that to 4K blocks (2^12=3D4096). Again, a > performance thing, matching the filesystem block size to device block siz= e. > > It would be interesting to see a benchmark of ZFS on a 4K drive with > different ashift values. Right on again. I forgot to include on my reply, that it is for a specific use case similar to ours, wherein we dedicate the entire drive to the pool. I believe it is totally time to put all these howto/faq stuff on a central FreeBSD repository, I think there's another thread requesting for the same thing. Scenarios: a] maximizing pool and drive size, don't need to partition -- these are the steps. a.1] new drives a.2] used drives b] For those with limited drives, limited enclosures etc -- these are the steps you may want to check out c] zfs-on-root d] and so on.. This will help a lot on deciding which steps to follow and which are necessary or not, therefore, avoiding all these repeated questions (just like mine) on ZFS setup/performance/tuning. https://wiki.freebsd.org/ZFSTuningGuide (WIP) - outdated, and there's no section for initial zpool/drive(s) setup.