From owner-freebsd-geom@FreeBSD.ORG Fri Feb 14 16:24:44 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 2E1B8DB2; Fri, 14 Feb 2014 16:24:44 +0000 (UTC) Received: from wonkity.com (wonkity.com [67.158.26.137]) (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 829AD1A9F; Fri, 14 Feb 2014 16:24:39 +0000 (UTC) Received: from wonkity.com (localhost [127.0.0.1]) by wonkity.com (8.14.8/8.14.8) with ESMTP id s1EGOY7f089766 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 14 Feb 2014 09:24:35 -0700 (MST) (envelope-from wblock@wonkity.com) Received: from localhost (wblock@localhost) by wonkity.com (8.14.8/8.14.8/Submit) with ESMTP id s1EGOYej089763; Fri, 14 Feb 2014 09:24:34 -0700 (MST) (envelope-from wblock@wonkity.com) Date: Fri, 14 Feb 2014 09:24:34 -0700 (MST) From: Warren Block To: freebsd-geom@FreeBSD.org Subject: Allowing arbitrary MBR slice alignment Message-ID: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (wonkity.com [127.0.0.1]); Fri, 14 Feb 2014 09:24:35 -0700 (MST) Cc: ae@FreeBSD.org, marcel@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: Fri, 14 Feb 2014 16:24:44 -0000 The Problem 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. 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. 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. Using 'gpart restore' to create or recreate slices can result in a restored disk with different slice sizes and locations. Not only does that violate POLA, it has the potential to cause problems, like a supposedly identical partition being too small to hold a restore of the original data, or partitions being rounded to values that no longer all fit on the same disk: http://www.freebsd.org/cgi/query-pr.cgi?pr=bin/169542 At present, the only way to create an MBR with 4K-aligned slices on FreeBSD is with fdisk(8), a legacy tool. GPT is an alternative, but not a replacement. Many systems with broken BIOS or UEFI implementations will not boot from GPT disks. Metadata conflicts mean that some GEOM classes like gmirror(8) cannot coexist with the GPT backup table at the end of the disk. MBR partitioning is still needed. Suggested Solution 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. 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.