Date: Sat, 31 May 2014 19:00:53 -0700 From: John-Mark Gurney <jmg@funkthat.com> To: "Michael W. Lucas" <mwlucas@michaelwlucas.com> Cc: hackers@freebsd.org Subject: Re: fdisk(8) vs gpart(8), and gnop Message-ID: <20140601020053.GR43976@funkthat.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
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."
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20140601020053.GR43976>