Date: Sat, 15 Feb 2014 09:52:58 -0800 From: Marcel Moolenaar <marcel@xcllnt.net> To: Warren Block <wblock@wonkity.com> Cc: "Andrey V. Elsukov" <ae@FreeBSD.org>, Marcel Moolenaar <marcel@FreeBSD.org>, freebsd-geom@FreeBSD.org Subject: Re: Allowing arbitrary MBR slice alignment Message-ID: <29DD155A-790F-4D28-8FFF-FED5466BC336@xcllnt.net> In-Reply-To: <alpine.BSF.2.00.1402140918560.88288@wonkity.com> References: <alpine.BSF.2.00.1402140918560.88288@wonkity.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--Apple-Mail=_DAC27FBB-E938-4F37-914F-C36F5348B165 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Feb 14, 2014, at 8:24 AM, Warren Block <wblock@wonkity.com> wrote: > The Problem >=20 > More and more disk devices have native 4K blocks. The ability to = align MBR slices to arbitrary values is consequently becoming more = important. Misaligned filesystems might read or write at less than half = the speed of aligned filesystems on the same disk. >=20 > Microsoft recognized this problem, and at least since the release of = Vista in 2007, MBR-formatted disks created by Microsoft operating = systems have started the first or main filesystem slice at block 2048 = (1M). Despite the official standard for MBR alignment to CHS values, = this second non-CHS but 4K-aligned de facto standard has become = extremely common. Aligning to 4K *and* CHS is possible. If there are 63 sectors per track, then a 4K aligned partition that starts at a track boundary starts in track 8 (LBA 504). Are you absolutely sure that 4K alignment resulted in non-CHS alignment? > When MBR slices are created with gpart(8) on FreeBSD, their starting = block and size are silently rounded to multiples of CHS values. This = happens even when specific values for -a (alignment) or -b (starting = block) are given. This silent rounding violates POLA. That's argumentative. > At present, the only way to create an MBR with 4K-aligned slices on = FreeBSD is with fdisk(8), a legacy tool. False. With some math, you can do the same thing with gpart. What is missing is good behaviour when -a 4K is specified. > Suggested Solution >=20 > gpart(8) should be allowed to override the CHS rounding with -a and -b = values when creating MBR slices. If CHS rounding occurs when the = options are not given, gpart(8) should give a warning that default = values were used to avoid surprising the user. >=20 > The warning is really secondary. Primarily and pragmatically, = gpart(8) needs the ability to create MBR slices with arbitrary alignment = so FreeBSD can deal gracefully with modern storage hardware. >=20 There are alternatives to consider: 1. Don't change anything 2. Align to both CHS and the specified alignment (-a). 3. Add an option to allow precise control over the behaviour and thus avoid causing POLA violations when the MBR scheme suddenly behaves differently and creates incompatible slices. --=20 Marcel Moolenaar marcel@xcllnt.net --Apple-Mail=_DAC27FBB-E938-4F37-914F-C36F5348B165 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlL/qXoACgkQpgWlLWHuifbhLACfWo3bAZQgoN1XfyWsv6++BEPn OMEAoIvRxDWXRTGRK7fZhRhQcTp+HLHl =00UN -----END PGP SIGNATURE----- --Apple-Mail=_DAC27FBB-E938-4F37-914F-C36F5348B165--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?29DD155A-790F-4D28-8FFF-FED5466BC336>