Date: Sun, 1 Jun 2014 09:00:53 -0600 (MDT) From: Warren Block <wblock@wonkity.com> To: "Michael W. Lucas" <mwlucas@michaelwlucas.com> Cc: hackers@freebsd.org Subject: Re: fdisk(8) vs gpart(8), and gnop Message-ID: <alpine.BSF.2.00.1406010836350.24305@wonkity.com> In-Reply-To: <20140601004242.GA97224@bewilderbeast.blackhelicopters.org> References: <20140601004242.GA97224@bewilderbeast.blackhelicopters.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?alpine.BSF.2.00.1406010836350.24305>