From owner-freebsd-current@freebsd.org Tue Dec 26 22:44:22 2017 Return-Path: Delivered-To: freebsd-current@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 38BDDE87E9F for ; Tue, 26 Dec 2017 22:44:22 +0000 (UTC) (envelope-from steven@multiplay.co.uk) Received: from mail-lf0-x22b.google.com (mail-lf0-x22b.google.com [IPv6:2a00:1450:4010:c07::22b]) (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 AAC896AB9C for ; Tue, 26 Dec 2017 22:44:21 +0000 (UTC) (envelope-from steven@multiplay.co.uk) Received: by mail-lf0-x22b.google.com with SMTP id f18so40699386lfg.8 for ; Tue, 26 Dec 2017 14:44:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=multiplay-co-uk.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=nTLoASJvOeeknc/nOPNJ7K/xOyi0QdS+RIR5lVxOIW8=; b=Skpv5hlsaI/hwfSGN6DaYSRoAk45TUd6xfxh8zID2pgA9dn/dv+29oUhfhabSancHj 36ESvKXUYV/7j3tL5ER8eCyrnla21/7j4uB1rxp0tRfOdf713yu9mUhOx+lcXqMy95tT 4d44FSaqBeIc+9xf+oOxWYnawUZpxkImmX9leYFdZBYkmf5XwupswN1c6/T/BzgV8G/V ZDGk3FkccmLPrfJHIX/eaaViyiXkLecBRovKLMOIrgnfYyiTC8XK0aNQi1BZOHYyNxOI vJJO4VnzqM6KoaWvkSHrMJDmRBgiKhmFKKkrmfP4iohVE3qFkpkyu7/nZ9kg6Lb9Gg2c 3Nxw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=nTLoASJvOeeknc/nOPNJ7K/xOyi0QdS+RIR5lVxOIW8=; b=gOmg8eByz0g6p59CYDkM+WP24csZMwBOcVP3RW7VDGJooe9EKKub7nA4bD2w7eHou3 k3KBnExWLchadYTqMOw2bmz0+kktRcjB1MBlYVchrXjn14AlDdsX4zJA5Y+26UNOvbFt PxPPQqQahxdzVf608VrmiTQMf6oz0PDuvkAs+IwucPAdigXe3BgyrJqj9zJLq0FtsYZO JM7890NHx1qh5JXljw15QB2v+AL2k4lUXiJJaNTU9aefZi4UBkvRwp1ZaaHgO5D3Gx+k 1B9HrAUQt8O3KLOidsJNlN0bAQ7qd+hgx7cMwBh0TrRx4SSetFAHKY76tsynIziHlVYE fO9g== X-Gm-Message-State: AKGB3mLqDtL0aTeMB5O9L+WYgJlFJBD36LZTyEk3TEw2Qgew5ccUEEHr hTYxZCtMH8vXoL0wbMMDtFvndp07pX8dv7tegA85Ww== X-Google-Smtp-Source: ACJfBosPXwd8/HvjUSbQz0ipp2NRVSz/d6O0Ay1fRtswMkxGHllrCiCgY/nuHeCsR8HhGT5E5rigpepndEyUZ8RvIDw= X-Received: by 10.25.44.195 with SMTP id s186mr2764621lfs.19.1514328258935; Tue, 26 Dec 2017 14:44:18 -0800 (PST) MIME-Version: 1.0 References: <201712261731.vBQHVr7d057227@pdx.rh.CN85.dnsmgr.net> <20171226212355.76494782@thor.intern.walstatt.dynvpn.de> In-Reply-To: <20171226212355.76494782@thor.intern.walstatt.dynvpn.de> From: Steven Hartland Date: Tue, 26 Dec 2017 22:44:08 +0000 Message-ID: Subject: Re: ZFS: alignment/boundary for partition type freebsd-zfs To: "O. Hartmann" Cc: Alan Somers , Allan Jude , FreeBSD CURRENT , "Rodney W. Grimes" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Dec 2017 22:44:22 -0000 Yes it does know how to figure out based on stripe size On Tue, 26 Dec 2017 at 20:25, O. Hartmann wrote: > Am Tue, 26 Dec 2017 09:31:53 -0800 (PST) > "Rodney W. Grimes" schrieb: > > > > On Tue, Dec 26, 2017 at 10:04 AM, O. Hartmann > > > wrote: > > > > > > > Am Tue, 26 Dec 2017 11:44:29 -0500 > > > > Allan Jude schrieb: > > > > > > > > > On 2017-12-26 11:24, O. Hartmann wrote: > > > > > > Running recent CURRENT on most of our lab's boxes, I was in nee= d > to > > > > replace and > > > > > > restore a ZFS RAIDZ pool. Doing so, I was in need to partition > the > > > > disks I was about > > > > > > to replace. Well, the drives in question are 4k block size > drives with > > > > 512b emulation > > > > > > - as most of them today. I've created the only and sole partito= n > on > > > > each 4 TB drive > > > > > > via the command sequence > > > > > > > > > > > > gpart create -s GPT adaX > > > > > > gpart add -t freebsd-zfs -a 4k -l nameXX adaX > > > > > > > > > > > > After doing this on all drives I was about to replace, somethin= g > drove > > > > me to check on > > > > > > the net and I found a lot of websites giving "advices", how to > prepare > > > > large, modern > > > > > > drives for ZFS. I think the GNOP trick is not necessary any > more, but > > > > many blogs > > > > > > recommend to perform > > > > > > > > > > > > gpart add -t freebsd-zfs -b 1m -a 4k -l nameXX adaX > > > > > > > > > > > > to put the partition boundary at the 1 Megabytes boundary. I > didn't do > > > > that. My > > > > > > partitions all start now at block 40. > > > > > > > > > > > > My question is: will this have severe performance consequences > or is > > > > that negligible? > > > > > > > > > > > > Since most of those websites I found via "zfs freebsd > alignement" are > > > > from years ago, > > > > > > I'm a bit confused now an consideration performing all this > > > > days-taking resilvering > > > > > > process let me loose some more hair as the usual "fallout" ... > > > > > > > > > > > > Thanks in advance, > > > > > > > > > > > > Oliver > > > > > > > > > > > > > > > > The 1mb alignment is not required. It is just what I do to leave > room > > > > > for the other partition types before the ZFS partition. > > > > > > > > > > However, the replacement for the GNOP hack, is separate. In > addition to > > > > > aligning the partitions to 4k, you have to tell ZFS that the driv= e > is 4k: > > > > > > > > > > sysctl vfs.zfs.min_auto_ashift=3D12 > > > > > > > > > > (2^12 =3D 4096) > > > > > > > > > > Before you create the pool, or add additional vdevs. > > > > > > > > > > > > > I didn't do the sysctl vfs.zfs.min_auto_ashift=3D12 :-(( when I > created the > > > > vdev. What is > > > > the consequence for that for the pool? I lived under the impression > that > > > > this is necessary > > > > for "native 4k" drives. > > > > > > > > How can I check what ashift is in effect for a specific vdev? > > > > > > > > > > It's only necessary if your drive stupidly fails to report its physic= al > > > sector size correctly, and no other FreeBSD developer has already > written a > > > quirk for that drive. Do "zdb -l /dev/adaXXXpY" for any one of the > > > partitions in the ZFS raid group in question. It should print either > > > "ashift: 12" or "ashift: 9". > > > > And more than likely if you used the bsdinstall from one of > > the distributions to setup the system you created the ZFS > > pool from it has the sysctl in /boot/loader.conf as the > > default for all? recent? bsdinstall's is that the 4k default > > is used and the sysctl gets written to /boot/loader.conf > > at install time so from then on all pools you create shall > > also be 4k. You have to change a default during the > > system install to change this to 512. > > > I never used any installation scripts so far. > > Before I replaced the pool's drives, I tried to search for informations o= n > how-to. This > important tiny fact must have slipped through - or it is very bad > documented. I didn't > find a hint in tuning(7), which is the man page I consulted first. > > Luckily, as Allan Jude stated, the disk recognition was correct (I guess > stripesize > instead of blocksize is taken?). > > > > > > -aLAn > > > > > _______________________________________________ > > > freebsd-current@freebsd.org mailing list > > > https://lists.freebsd.org/mailman/listinfo/freebsd-current > > > To unsubscribe, send any mail to " > freebsd-current-unsubscribe@freebsd.org" > > > > > > > > > -- > O. Hartmann > > Ich widerspreche der Nutzung oder =C3=9Cbermittlung meiner Daten f=C3=BCr > Werbezwecke oder f=C3=BCr die Markt- oder Meinungsforschung (=C2=A7 28 Ab= s. 4 BDSG). >