From owner-freebsd-geom@FreeBSD.ORG Mon Feb 10 07:02:23 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 6A4C5A20 for ; Mon, 10 Feb 2014 07:02:23 +0000 (UTC) Received: from mail-lb0-x232.google.com (mail-lb0-x232.google.com [IPv6:2a00:1450:4010:c04::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id E8AF21ADD for ; Mon, 10 Feb 2014 07:02:22 +0000 (UTC) Received: by mail-lb0-f178.google.com with SMTP id u14so4534117lbd.9 for ; Sun, 09 Feb 2014 23:02:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=Xb+RAViPNOLm4bebvYY5JS6tjeZMjqc6EOQiPOV9ZRM=; b=BpwMrYHy1bLG9aTEEG4iqNNn31kwyT4iipsaGej/SPFfc7aX99UHRNCWt0JzgMIj7P CdrFIcUQ4eg9TwyXyWQGDqa32fOXUXHgYVRZIMBkk/5z2XjrwuUoZdHbkPyvDAlvxU9S gNUwEIAp+i8pynM5Z2yXzHQcB0ibtpd8ihwK8+qgWzzFiiQjFI4/kDTwXubA5TmSN8uh 7qsQ4rZ5JZaxoptVlbZwjnb+0Aa3Dl6Ecm4xMy6YplWdpo53nxTjZqFqr9+HLRIop0Tr zgsDwvrho4dm4jOuavFfW5SkVI//FdgvA6EmZg+ULxiEoVEhO2PltLaUUIK/UybqYfOh 3gsQ== MIME-Version: 1.0 X-Received: by 10.152.23.132 with SMTP id m4mr766023laf.34.1392015740900; Sun, 09 Feb 2014 23:02:20 -0800 (PST) Received: by 10.112.5.193 with HTTP; Sun, 9 Feb 2014 23:02:20 -0800 (PST) Date: Mon, 10 Feb 2014 10:32:20 +0330 Message-ID: Subject: how to mount r/w encrypted partition when it is mount ad read-only? From: s m To: freebsd-geom@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 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: Mon, 10 Feb 2014 07:02:23 -0000 hello all i have an encrypted user partition which is encrypted with geli. user is mounted read-only. i want to mount it r/w for a short time, copy some files on it and mount it read-only again. with unencrypted partitions, we can change mount options. for example if an unencrypted user partition is read-only mounted, we can mount it r/w by "mount -rw /usr" command. but for encrypted partitions this command doesn't work and error "device busy" occurs. is there any way to mount r/w encrypted partition when it is mounted as read-only? thanks in advance, sam From owner-freebsd-geom@FreeBSD.ORG Mon Feb 10 11:06:46 2014 Return-Path: Delivered-To: freebsd-geom@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D7A12ED for ; Mon, 10 Feb 2014 11:06:46 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (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 C2DE71FD2 for ; Mon, 10 Feb 2014 11:06:46 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id s1AB6k4t080036 for ; Mon, 10 Feb 2014 11:06:46 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.8/8.14.8/Submit) id s1AB6kGi080034 for freebsd-geom@FreeBSD.org; Mon, 10 Feb 2014 11:06:46 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 10 Feb 2014 11:06:46 GMT Message-Id: <201402101106.s1AB6kGi080034@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-geom@FreeBSD.org Subject: Current problem reports assigned to 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: Mon, 10 Feb 2014 11:06:46 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/183866 geom [geom] graid cannot remove loader detected BIOS RAIDS o kern/183803 geom [geom] FreeBSD 10 Beta 2 geom module does not understa o kern/181704 geom [geom] ggatec crash the system when I write something o kern/179889 geom [geli] geli stopped work after updating RELEASE 9.* so o kern/178684 geom gpart(8) cannot get my GEOM tree o kern/178359 geom [geom] [patch] geom_eli: support external metadata f kern/176744 geom [geom] [patch] BIO_FLUSH not recorded by devstats o kern/170038 geom [geom] geom_mirror always starts degraded after reboot o kern/169539 geom [geom] [patch] fix ability to run gmirror on MSI MegaR a bin/169077 geom bsdinstall(8) does not use partition labels in /etc/fs f kern/165745 geom [geom] geom_multipath page fault on removed drive o kern/165428 geom [glabel][patch] Add xfs support to glabel o kern/164254 geom [geom] gjournal not stopping on GPT partitions o kern/164252 geom [geom] gjournal overflow o kern/164143 geom [geom] Partition table not recognized after upgrade R8 a kern/163020 geom [geli] [patch] enable the Camellia-XTS on GEOM ELI o kern/162690 geom [geom] gpart label changes only take effect after a re o kern/162010 geom [geli] panic: Provider's error should be set (error=0) o kern/161979 geom [geom] glabel doesn't update after newfs, and glabel s o bin/161807 geom [patch] add option for explicitly specifying metadata o kern/161752 geom [geom] glabel(8) doesn't get gpt label change o bin/161677 geom gpart(8) Probably bug in gptboot o kern/160409 geom [geli] failed to attach provider f kern/159595 geom [geom] [panic] panic on gmirror unload in vbox [regres f kern/159414 geom [isp] isp(4)+gmultipath(8) : removing active fiber pat p kern/158398 geom [headers] [patch] includes o kern/158197 geom [geom] geom_cache with size>1000 leads to panics o kern/157879 geom [libgeom] [regression] ABI change without version bump o kern/157863 geom [geli] kbdmux prevents geli passwords from being enter o kern/157739 geom [geom] GPT labels with geom_multipath o kern/157724 geom [geom] gpart(8) 'add' command must preserve gap for sc o kern/157723 geom [geom] GEOM should not process 'c' (raw) partitions fo o kern/157108 geom [gjournal] dumpon(8) fails on gjournal providers o kern/155994 geom [geom] Long "Suspend time" when reading large files fr o bin/154570 geom [patch] gvinum(8) can't be built as part of the kernel o kern/154226 geom [geom] GEOM label does not change when you modify them o kern/150858 geom [geom] [geom_label] [patch] glabel(8) is not compatibl o kern/150626 geom [geom] [gjournal] gjournal(8) destroys label o kern/150555 geom [geom] gjournal unusable on GPT partitions o kern/150334 geom [geom] [udf] [patch] geom label does not support UDF o kern/149762 geom volume labels with rogue characters o bin/149215 geom [panic] [geom_part] gpart(8): Delete linux's slice via o kern/147667 geom [gmirror] Booting with one component of a gmirror, the o kern/145818 geom [geom] geom_stat_open showing cached information for n o kern/145042 geom [geom] System stops booting after printing message "GE o kern/143455 geom gstripe(8) in RELENG_8 (31st Jan 2010) broken o kern/142563 geom [geom] [hang] ioctl freeze in zpool o kern/141740 geom [geom] gjournal(8): g_journal_destroy concurrent error o kern/140352 geom [geom] gjournal + glabel not working o kern/135898 geom [geom] Severe filesystem corruption - large files or l o kern/134113 geom [geli] Problem setting secondary GELI key o kern/133931 geom [geli] [request] intentionally wrong password to destr o bin/132845 geom [geom] [patch] ggated(8) does not close files opened a o bin/131415 geom [geli] keystrokes are unregulary sent to Geli when typ o kern/131353 geom [geom] gjournal(8) kernel lock o kern/129674 geom [geom] gjournal root did not mount on boot o kern/129645 geom gjournal(8): GEOM_JOURNAL causes system to fail to boo o kern/129245 geom [geom] gcache is more suitable for suffix based provid o kern/127420 geom [geom] [gjournal] [panic] Journal overflow on gmirrore o kern/124973 geom [gjournal] [patch] boot order affects geom_journal con o kern/124969 geom gvinum(8): gvinum raid5 plex does not detect missing s o kern/123962 geom [panic] [gjournal] gjournal (455Gb data, 8Gb journal), o kern/123122 geom [geom] GEOM / gjournal kernel lock o kern/122738 geom [geom] gmirror list "losts consumers" after gmirror de o kern/122067 geom [geom] [panic] Geom crashed during boot o kern/120091 geom [geom] [geli] [gjournal] geli does not prompt for pass o kern/115856 geom [geli] ZFS thought it was degraded when it should have o kern/115547 geom [geom] [patch] [request] let GEOM Eli get password fro o kern/113837 geom [geom] unable to access 1024 sector size storage o kern/113419 geom [geom] geom fox multipathing not failing back o kern/107707 geom [geom] [patch] [request] add new class geom_xbox360 to o kern/94632 geom [geom] Kernel output resets input while GELI asks for o kern/90582 geom [geom] [panic] Restore cause panic string (ffs_blkfree o bin/90093 geom fdisk(8) incapable of altering in-core geometry o kern/87544 geom [gbde] mmaping large files on a gbde filesystem deadlo o bin/86388 geom [geom] [geom_part] periodic(8) daily should backup gpa o kern/84556 geom [geom] [panic] GBDE-encrypted swap causes panic at shu o kern/79251 geom [2TB] newfs fails on 2.6TB gbde device o kern/79035 geom [vinum] gvinum unable to create a striped set of mirro o bin/78131 geom gbde(8) "destroy" not working. 80 problems total. 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. From owner-freebsd-geom@FreeBSD.ORG Sat Feb 15 07:56:36 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 325B766A; Sat, 15 Feb 2014 07:56:36 +0000 (UTC) Received: from microbel.pvv.ntnu.no (microbel.pvv.ntnu.no [IPv6:2001:700:300:1900::1:2]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id DC8F01037; Sat, 15 Feb 2014 07:56:35 +0000 (UTC) Received: from 242.243.251.212.customer.cdi.no ([212.251.243.242] helo=nobby.localnet) by microbel.pvv.ntnu.no with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1WEa6v-0002WJ-Gw; Sat, 15 Feb 2014 08:56:31 +0100 From: Ulf Lilleengen To: freebsd-geom@freebsd.org Subject: Re: Allowing arbitrary MBR slice alignment Date: Sat, 15 Feb 2014 08:54:44 +0100 Message-ID: <7737397.rILaIf05sy@nobby> User-Agent: KMail/4.10.5 (FreeBSD/10.0-RELEASE; KDE/4.10.5; amd64; ; ) In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Spam-Score: -0.9 (/) X-Spam-Report: Status=No hits=-0.9 required=5.0 tests=ALL_TRUSTED, TVD_RCVD_IP version=3.3.1 Cc: Warren Block , ae@freebsd.org, marcel@freebsd.org, 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 07:56:36 -0000 On Friday 14. February 2014 09.24.34 Warren Block wrote: > 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. *snip* > 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. > IMHO, 4k alignment should be default in freebsd as well, unless there are some actual disadvantages for the users. I think the majority of users would like good performance. But allowing to override it is a good start :) Ulf 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-- From owner-freebsd-geom@FreeBSD.ORG Sat Feb 15 21:27:19 2014 Return-Path: Delivered-To: freebsd-geom@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 57AA41000; Sat, 15 Feb 2014 21:27:19 +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 162461AAE; Sat, 15 Feb 2014 21:27:18 +0000 (UTC) Received: from wonkity.com (localhost [127.0.0.1]) by wonkity.com (8.14.8/8.14.8) with ESMTP id s1FLRFFj046241 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 15 Feb 2014 14:27:16 -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 s1FLRF2I046238; Sat, 15 Feb 2014 14:27:15 -0700 (MST) (envelope-from wblock@wonkity.com) Date: Sat, 15 Feb 2014 14:27:15 -0700 (MST) From: Warren Block To: Marcel Moolenaar Subject: Re: Allowing arbitrary MBR slice alignment In-Reply-To: <29DD155A-790F-4D28-8FFF-FED5466BC336@xcllnt.net> Message-ID: References: <29DD155A-790F-4D28-8FFF-FED5466BC336@xcllnt.net> 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]); Sat, 15 Feb 2014 14:27:16 -0700 (MST) 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 21:27:19 -0000 On Sat, 15 Feb 2014, Marcel Moolenaar wrote: > On Feb 14, 2014, at 8:24 AM, Warren Block wrote: > >> 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. > > 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). Sure, 4K * 63. But that only works if the user is not concerned about precise location or size of slices. It's okay if dealing with FreeBSD, but restricts interoperability with MBRs created on or for use with other systems. > Are you absolutely sure that 4K alignment resulted in non-CHS > alignment? gpart has never managed to create a slice starting at block 2048 for me, either with -a4k or -b2048 or both. It always becomes block 2079, the next multiple of 63. In effect, the value of -a is forced to 63 when creating MBR slices, even when the user asks for something else. Block 2079 is one block short of being 4K-aligned. >> 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. Sorry, not intentional. Arguable? Using '-a4k -b1m' and getting '-a63 -b2079' was pretty surprising the first time I saw it. "Astonishing" is not too strong a word. :) >> 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. You're right, the wording was imprecise. How about: At present, the only way to create MBR slices with arbitrary 4K-aligned starting positions and sizes is with fdisk(8), a legacy tool. > What is missing is good behaviour when -a 4K is specified. Yes, keeping in mind that other systems with which FreeBSD must interact operate under different alignment rules, or no rules at all. >> 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. >> > > 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. #2 is only a partial solution. If an original MBR is not CHS-aligned, 'gpart recover' would still create a new MBR that differs. And it would not be possible to create a partition at a non-CHS-aligned location. Is #3 what I suggested, or another method? Thanks!