From owner-freebsd-hackers@FreeBSD.ORG Sun Jun 1 02: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 462676D3 for ; Sun, 1 Jun 2014 02:00:55 +0000 (UTC) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "funkthat.com", Issuer "funkthat.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 1E36D2160 for ; Sun, 1 Jun 2014 02:00:54 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id s5120rqW092470 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 31 May 2014 19:00:54 -0700 (PDT) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id s5120rsu092469; Sat, 31 May 2014 19:00:53 -0700 (PDT) (envelope-from jmg) Date: Sat, 31 May 2014 19:00:53 -0700 From: John-Mark Gurney To: "Michael W. Lucas" Subject: Re: fdisk(8) vs gpart(8), and gnop Message-ID: <20140601020053.GR43976@funkthat.com> Mail-Followup-To: "Michael W. Lucas" , hackers@freebsd.org References: <20140601004242.GA97224@bewilderbeast.blackhelicopters.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140601004242.GA97224@bewilderbeast.blackhelicopters.org> User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Sat, 31 May 2014 19:00:54 -0700 (PDT) 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 02:00:55 -0000 Michael W. Lucas wrote this message on Sat, May 31, 2014 at 20:42 -0400: > $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. > > 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 gpart's -a will not properly align MBR's slices due to enforced CHS... # mdconfig -a -t swap -s 1gb md0 # gpart create -s mbr md0 md0 created # gpart add -t freebsd -a 4k md0 md0s1 added # gpart show md0 => 63 2097089 md0 MBR (1.0G) 63 63 - free - (32K) 126 2097018 1 freebsd (1.0G) 2097144 8 - free - (4.0K) As you can see, 126 % 8 == 6, and should be 0 w/ the -a 4k... Luckily, if you provide the -a 4k parameter when creating partitions in a bsdlabel, they will be properly aligned, so this isn't a "big" issue since no performance critical data is stored unaligned... > sometimes need to use fdisk, when exactly is that? fdisk can be used to break the CHS requirements that gpart enforces, but per above, as along as -a is provided when you create your partitions, you'll be fine as gpart can "see" through the fact that the slice is unaligned, and align the partition properly... This does mean though that if you ever move over the slice to another slice that has difference alignment, then everything is messed up... fdisk does not force the CHS alignement, and so you can avoid it, though, you cannot use (w/o turning on debug flags which you should never do) fdisk on a system where one of it's slices/partitions are mounted, unlike you can w/ gpart... So, even though you could, I'd still recommend not using fdisk, and only using gpart... > 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. I've never used this since I've always put ZFS on top of GELI, and if you use a sector size smaller than 4k, your performance won't be very good, and iirc, you can't use a sector size larger than page size due to some other reasons (I think the machine will panic)... > 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. I'd leave out the gnop for UFS as it doesn't look at the underlying sector size for anything (unlike ZFS)... As kib mentioned, UFS does everything at least fragment aligned (default 4k), and when it comes to superblocks and cg's, everything is block aligned (32k)... If you try to newfs w/ a smaller fragment size than 4k on a gnop'd device, you end up w/: # newfs -f 2048 -b 16384 /dev/md0s1a.nop /dev/md0s1a.nop: 1023.9MB (2097016 sectors) block size 16384, fragment size 2048 using 7 cylinder groups of 155.50MB, 9952 blks, 39808 inodes. super-block backups (for fsck_ffs -b #) at: 160, 318624, 637088, 955552, 1274016, 1592480, 1910944 newfs: wtfs: 2048 bytes at sector 20160: Invalid argument We should probably fail earlier, as I completely missed the last line, since I saw so many lines of what I'm used to seeing... > Are my beliefs correct? > > I need to get this part of the book correct, or the rest of it will go > wildly astray... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not."