From owner-freebsd-geom@FreeBSD.ORG Sat Feb 15 17:53:01 2014 Return-Path: Delivered-To: freebsd-geom@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 93D2E4DA; Sat, 15 Feb 2014 17:53:01 +0000 (UTC) Received: from mail.xcllnt.net (mail.xcllnt.net [50.0.150.214]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 5C4981AF1; Sat, 15 Feb 2014 17:53:01 +0000 (UTC) Received: from macbook-air.wifi.xcllnt.net (atc.xcllnt.net [50.0.150.213]) (authenticated bits=0) by mail.xcllnt.net (8.14.7/8.14.7) with ESMTP id s1FHqxbg031650 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 15 Feb 2014 09:53:00 -0800 (PST) (envelope-from marcel@xcllnt.net) Content-Type: multipart/signed; boundary="Apple-Mail=_DAC27FBB-E938-4F37-914F-C36F5348B165"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) Subject: Re: Allowing arbitrary MBR slice alignment From: Marcel Moolenaar In-Reply-To: Date: Sat, 15 Feb 2014 09:52:58 -0800 Message-Id: <29DD155A-790F-4D28-8FFF-FED5466BC336@xcllnt.net> References: To: Warren Block X-Mailer: Apple Mail (2.1827) Cc: "Andrey V. Elsukov" , Marcel Moolenaar , freebsd-geom@FreeBSD.org X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Feb 2014 17:53:01 -0000 --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 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--