From owner-freebsd-fs@FreeBSD.ORG Wed Jul 17 17:01:31 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 97C63308 for ; Wed, 17 Jul 2013 17:01:31 +0000 (UTC) (envelope-from gezeala@gmail.com) Received: from mail-la0-x22d.google.com (mail-la0-x22d.google.com [IPv6:2a00:1450:4010:c03::22d]) by mx1.freebsd.org (Postfix) with ESMTP id 193E0DC3 for ; Wed, 17 Jul 2013 17:01:30 +0000 (UTC) Received: by mail-la0-f45.google.com with SMTP id fr10so1706083lab.18 for ; Wed, 17 Jul 2013 10:01:30 -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=OCDhufSUWjnloz7XeBjVA+ybkZOpW2Ct111XH49MBew=; b=dP1xVA+ZqlZn+naAq4Iv7ONDKwjydCRy2FmifMLTssVUIWDQZXEYD3lpowObeeNZNx Z/fgn4flPZzHvu1eeavqlbDY0iZQckaa/Pvl5DIsR14g+VzMD9JTqD4UzYZH5OasmaU8 PGeW3Akeyaii/FEpHFMZvZc72TMDQrZS2OucqaZqO/HKiOSN53Omzhhzy1HVS0mPW07H CTzgJNx079B9pMsWhW5N3z+aTig6QYaK8SPFMrYj0qcymXagTrGYm63UXMGeXs2ED1MW 9KxR4qh9DAvZVpzRkNZbL9MKxjLH/lFet3FGP36joGfhJFL8uRhvZ4CGgeUPRkGV5rMb jf1g== X-Received: by 10.112.97.132 with SMTP id ea4mr3514560lbb.80.1374080490052; Wed, 17 Jul 2013 10:01:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.114.82.72 with HTTP; Wed, 17 Jul 2013 10:00:49 -0700 (PDT) In-Reply-To: References: <51D42107.1050107@digsys.bg> <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 10:00:49 -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 17:01:31 -0000 On Tue, Jul 16, 2013 at 6:47 PM, Warren Block wrote: > On Tue, 16 Jul 2013, Gezeala M. Bacu=F1o II wrote: > > On Fri, Jul 5, 2013 at 6:08 PM, Freddie Cash wrote: >> >> >>> ZFS- on-Linux has added this as "-o ashift=3D" property for zpool creat= e. >>> >>> There's a threat on the illumos list about standardising this s across >>> all >>> ZFS- using OSes. >>> >>> >>> >>> +1 on this. We tested zfs-on-linux last year and it does automatically >> handle disk partitioning for correct alignment. What we do is just add >> ashift=3D12 option during zpool create. No more gpart/gnop/ashift/import >> steps. >> >> http://zfsonlinux.org/faq.**html#**HowDoesZFSonLinuxHandlesAdvace** >> dFormatDrives >> >> >> Back to FreeBSD ZFS, >> >> After reading the thread, I'm still at a loss on this (too much info I >> guess).. regarding gpart/gnop/ashift tweaks for alignment, do we still >> need >> to perform gpart on newly purchased (SSD/SATA/SAS) Advanced Format drive= s? >> Or, skip gpart and proceed with gnop/ashift only? >> > > 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 large= r > 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 en= d > up using the right block size but misaligned. > > And yes, it will be nice to be able to just explicitly tell ZFS the 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.