From owner-freebsd-hackers@FreeBSD.ORG Sun Jun 1 15:00:55 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 99BB67AE for ; Sun, 1 Jun 2014 15:00:55 +0000 (UTC) Received: from wonkity.com (wonkity.com [67.158.26.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "wonkity.com", Issuer "wonkity.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 2CFB9233B for ; Sun, 1 Jun 2014 15:00:55 +0000 (UTC) Received: from wonkity.com (localhost [127.0.0.1]) by wonkity.com (8.14.8/8.14.8) with ESMTP id s51F0r7w024484 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 1 Jun 2014 09:00:53 -0600 (MDT) (envelope-from wblock@wonkity.com) Received: from localhost (wblock@localhost) by wonkity.com (8.14.8/8.14.8/Submit) with ESMTP id s51F0rC0024481; Sun, 1 Jun 2014 09:00:53 -0600 (MDT) (envelope-from wblock@wonkity.com) Date: Sun, 1 Jun 2014 09:00:53 -0600 (MDT) From: Warren Block To: "Michael W. Lucas" Subject: Re: fdisk(8) vs gpart(8), and gnop In-Reply-To: <20140601004242.GA97224@bewilderbeast.blackhelicopters.org> Message-ID: References: <20140601004242.GA97224@bewilderbeast.blackhelicopters.org> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (wonkity.com [127.0.0.1]); Sun, 01 Jun 2014 09:00:54 -0600 (MDT) Cc: hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Jun 2014 15:00:55 -0000 On Sat, 31 May 2014, Michael W. Lucas wrote: > Folks, > > $SUBJECT have been two contentious points of discussion in private > mail, Twitter, the BSDCan bar track, and random people passing on the > street. I was very surprised at the number of knowledgeable people who > have different ideas on this and argue about it at length. That is surprising, but then there are still fervent supporters of bare bsdlabel partitions, too. (Less of them lately. Presumably many are offline because some disk partitioning tool written in the last couple of decades has blown away their bsdlabels, but I digress.) > I'm hoping to verify what seems to be correct. > > First, is fdisk EVER necessary? I *believe* that gpart's '-a 4k' > handles all alignment issues for the 512B/4KB sector issues. If you > sometimes need to use fdisk, when exactly is that? Yes, fdisk is still necessary, but only to create aligned MBR slices. Well, it can only deal with MBR anyway, but unlike gpart, it does not force a standards-compliant CHS value for slice starting location. (It still happily complains about it, though.) The confusing workaround with gpart is to let it create the MBR slice aligned to imaginary CHS values, working out to block 2079 on modern disks. This is unaligned to 4K or other reasonable power of two values. gpart will, however, align bsdlabels inside the slice. If asked. > Similarly, I *believe* that you need to "gnop -S 4096 $device" any > time you want to use ZFS, so that 1) zfs sets ashift=12 and 2) you can > later replace a 512B-sector drive with a 4096KB-sector drive without > ZFS having a hissy fit about mismatched sector sizes. It's mystifying to me that ZFS will happily check device block sizes and use the largest block size detected. Yet there is no command-line way to specify a a block size, and so there is this ridiculous hack of a workaround. Many people also confuse using gnop to force 4K blocks with alignment. > Finally, while UFS isn't picky about changing the underlying sector > size on a dump/restore, I believe it's a good idea to always gnop the > underlying disk. Disks lie about sector size, and while it's OK to > assume a 4k-sector disk, assuming a 512b-sector disk on a 4k-sector > disk causes write multiplication. With the latest defaults on newfs (4K fragments), I don't think this is an issue. A benchmark would be the empirical way to really tell. It would not hurt to recommend using 4K fragments with newfs for pre-9.0 versions of FreeBSD, where the old default was 2K.