From owner-freebsd-geom@FreeBSD.ORG Sun Feb 16 03:28:15 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 38CCEAD5; Sun, 16 Feb 2014 03:28:15 +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 0497E1721; Sun, 16 Feb 2014 03:28:14 +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 s1G3S6Z2033949 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 15 Feb 2014 19:28:07 -0800 (PST) (envelope-from marcel@xcllnt.net) Content-Type: multipart/signed; boundary="Apple-Mail=_0C6238AE-2843-44C4-B449-12B6CCDF2ED7"; 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 19:28:06 -0800 Message-Id: <73BC4100-2F81-41AD-BED7-0A920AE69C76@xcllnt.net> References: <29DD155A-790F-4D28-8FFF-FED5466BC336@xcllnt.net> 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: Sun, 16 Feb 2014 03:28:15 -0000 --Apple-Mail=_0C6238AE-2843-44C4-B449-12B6CCDF2ED7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Feb 15, 2014, at 1:27 PM, Warren Block wrote: >=20 >> Are you absolutely sure that 4K alignment resulted in non-CHS >> alignment? >=20 > 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. >=20 > Block 2079 is one block short of being 4K-aligned. I'm sorry, I probably wasn't clear. You suggest a change to gpart to allow non-CHS alignment, stating that 4K alignment is getting to be the standard. I have no problem accepting that 4K alignment is to be standard nowadays, but what I don't know is whether it's done at the cost of 30+ years of CHS alignment for the MBR scheme. If CHS is entirely dropped, then we just need to see what needs it (e.g. msdosfs) and make sure that once we stop CHS alignment we don't break our own code and don't break interoperability. There's a very good reason why the MBR scheme aligns to CHS and it's a deliberate choice to have it do so. All I'm asking is that we take the same care in removing that behaviour as there was when it was put in. >> 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 > #2 is only a partial solution. If an original MBR is not CHS-aligned, = 'gpart recover' would still create a new MBR that differs. The problem with recovery of a scheme that has ill-defined characteristics is that you'll have to make guesses and you can never guarantee that the recovered partition is identical to the original. One can argue that recovery without redundancy is something that should not even be attempted. > Is #3 what I suggested, or another method? I would expect that if the MBR scheme forces CHS alignment, that -a 4K would result in alignment for both. This is not the same as a specific option that tells the MBR scheme to not align to CHS at all. This would be a clear indication that 1) the user/operator takes responsibility for the end result and 2) that a change in default behaviour is asked for. gpart does allow for that with the -f option. It's for passing operational flags. For example ``gpart add -t freebsd -a 4K -f A ${dev}'' could be used to tell gpart that that alignment is to be taken from the user without enforcing other alignment. Note however that the alignment is actually handled by the user space utility, whereas the scheme-enforced CHS alignment is done by the kernel. Given the current implementation it's actually hard to have a defaukt behaviour of aligning to what the user asked for as well as to what the scheme enforces. --=20 Marcel Moolenaar marcel@xcllnt.net --Apple-Mail=_0C6238AE-2843-44C4-B449-12B6CCDF2ED7 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 iEYEARECAAYFAlMAMEYACgkQpgWlLWHuifao6QCeItl+lTB8eAKliHbovy+DKMbJ C9wAn2GO/T/MjcPSBzKMoUq9hqqXO2sS =8zfI -----END PGP SIGNATURE----- --Apple-Mail=_0C6238AE-2843-44C4-B449-12B6CCDF2ED7-- From owner-freebsd-geom@FreeBSD.ORG Mon Feb 17 11:06:47 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 7A381D28 for ; Mon, 17 Feb 2014 11:06:47 +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 6590A11B9 for ; Mon, 17 Feb 2014 11:06:47 +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 s1HB6lfJ033040 for ; Mon, 17 Feb 2014 11:06:47 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.8/8.14.8/Submit) id s1HB6kYn033038 for freebsd-geom@FreeBSD.org; Mon, 17 Feb 2014 11:06:46 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 17 Feb 2014 11:06:46 GMT Message-Id: <201402171106.s1HB6kYn033038@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, 17 Feb 2014 11:06:47 -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 Mon Feb 17 17:40:27 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 445906F1; Mon, 17 Feb 2014 17:40:27 +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 AB2151B67; Mon, 17 Feb 2014 17:40:26 +0000 (UTC) Received: from wonkity.com (localhost [127.0.0.1]) by wonkity.com (8.14.8/8.14.8) with ESMTP id s1HHeN5K039119 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 17 Feb 2014 10:40:23 -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 s1HHeMSL039116; Mon, 17 Feb 2014 10:40:23 -0700 (MST) (envelope-from wblock@wonkity.com) Date: Mon, 17 Feb 2014 10:40:22 -0700 (MST) From: Warren Block To: Marcel Moolenaar Subject: Re: Allowing arbitrary MBR slice alignment In-Reply-To: <73BC4100-2F81-41AD-BED7-0A920AE69C76@xcllnt.net> Message-ID: References: <29DD155A-790F-4D28-8FFF-FED5466BC336@xcllnt.net> <73BC4100-2F81-41AD-BED7-0A920AE69C76@xcllnt.net> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (wonkity.com [127.0.0.1]); Mon, 17 Feb 2014 10:40:23 -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: Mon, 17 Feb 2014 17:40:27 -0000 On Sat, 15 Feb 2014, Marcel Moolenaar wrote: > On Feb 15, 2014, at 1:27 PM, Warren Block wrote: >> >>> 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. > > I'm sorry, I probably wasn't clear. > > You suggest a change to gpart to allow non-CHS alignment, stating > that 4K alignment is getting to be the standard. > > I have no problem accepting that 4K alignment is to be standard > nowadays, but what I don't know is whether it's done at the cost > of 30+ years of CHS alignment for the MBR scheme. > > If CHS is entirely dropped, then we just need to see what needs > it (e.g. msdosfs) and make sure that once we stop CHS alignment > we don't break our own code and don't break interoperability. > > There's a very good reason why the MBR scheme aligns to CHS and > it's a deliberate choice to have it do so. > > All I'm asking is that we take the same care in removing that > behaviour as there was when it was put in. Agreed, that's entirely reasonable. >>> 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. > > The problem with recovery of a scheme that has ill-defined > characteristics is that you'll have to make guesses and you > can never guarantee that the recovered partition is identical > to the original. > > One can argue that recovery without redundancy is something > that should not even be attempted. Sorry, s/recover/restore/. Let me try again: 'gpart restore' should recreate the partitioning as shown in the input, or give an error if it is not possible. Either of these is preferable to creating partitioning which has been silently adjusted. >> Is #3 what I suggested, or another method? > > I would expect that if the MBR scheme forces CHS alignment, > that -a 4K would result in alignment for both. This is not > the same as a specific option that tells the MBR scheme to > not align to CHS at all. This would be a clear indication > that 1) the user/operator takes responsibility for the end > result and 2) that a change in default behaviour is asked > for. > > gpart does allow for that with the -f option. It's for > passing operational flags. > > For example ``gpart add -t freebsd -a 4K -f A ${dev}'' > could be used to tell gpart that that alignment is to be > taken from the user without enforcing other alignment. That would be better than the current situation, although the second flag ends up saying "and this time, really do what I said to do". When the user supplies -a or -b values, I suggest it implicitly means "...and override any default assumptions". The current behavior could be retained by supplying -a63, although admittedly that might not work all the time. Maybe a special value of '-a chs'? Or actually, just the default when -a or -b are not supplied. > Note however that the alignment is actually handled by the > user space utility, whereas the scheme-enforced CHS alignment > is done by the kernel. Given the current implementation it's > actually hard to have a defaukt behaviour of aligning to what > the user asked for as well as to what the scheme enforces. For me, alignment to the LCM of CHS and and -a value would be unexpected when an explicit -a value was given. A warning would help, but on FreeBSD I expect pretty much any program to use the values as supplied, and at most, give a warning if they were really bizarre. Thanks! From owner-freebsd-geom@FreeBSD.ORG Mon Feb 17 19:08:38 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 D532A17E; Mon, 17 Feb 2014 19:08:38 +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 95175162C; Mon, 17 Feb 2014 19:08:38 +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.8/8.14.8) with ESMTP id s1HJ8VGb018573 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 17 Feb 2014 11:08:32 -0800 (PST) (envelope-from marcel@xcllnt.net) Content-Type: multipart/signed; boundary="Apple-Mail=_B739D10C-E07C-40CB-939F-216EB463D05B"; 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: Mon, 17 Feb 2014 11:08:29 -0800 Message-Id: <868C9E58-8039-4782-BC74-5C820D1B4F5C@xcllnt.net> References: <29DD155A-790F-4D28-8FFF-FED5466BC336@xcllnt.net> <73BC4100-2F81-41AD-BED7-0A920AE69C76@xcllnt.net> 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: Mon, 17 Feb 2014 19:08:39 -0000 --Apple-Mail=_B739D10C-E07C-40CB-939F-216EB463D05B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Feb 17, 2014, at 9:40 AM, Warren Block wrote: >=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 >>> #2 is only a partial solution. If an original MBR is not = CHS-aligned, 'gpart recover' would still create a new MBR that differs. >>=20 >> The problem with recovery of a scheme that has ill-defined >> characteristics is that you'll have to make guesses and you >> can never guarantee that the recovered partition is identical >> to the original. >>=20 >> One can argue that recovery without redundancy is something >> that should not even be attempted. >=20 > Sorry, s/recover/restore/. Let me try again: > 'gpart restore' should recreate the partitioning as shown in the = input, > or give an error if it is not possible. Either of these is preferable > to creating partitioning which has been silently adjusted. Agreed. >=20 >>> Is #3 what I suggested, or another method? >>=20 >> I would expect that if the MBR scheme forces CHS alignment, >> that -a 4K would result in alignment for both. This is not >> the same as a specific option that tells the MBR scheme to >> not align to CHS at all. This would be a clear indication >> that 1) the user/operator takes responsibility for the end >> result and 2) that a change in default behaviour is asked >> for. >>=20 >> gpart does allow for that with the -f option. It's for >> passing operational flags. >>=20 >> For example ``gpart add -t freebsd -a 4K -f A ${dev}'' >> could be used to tell gpart that that alignment is to be >> taken from the user without enforcing other alignment. >=20 > That would be better than the current situation, although the second = flag ends up saying "and this time, really do what I said to do". >=20 > When the user supplies -a or -b values, I suggest it implicitly means = "...and override any default assumptions". The current behavior could = be retained by supplying -a63, although admittedly that might not work = all the time. Maybe a special value of '-a chs'? Or actually, just the = default when -a or -b are not supplied. This is where things get tricky... First there's architecture and layering. The whole point gpart is to abstract the details of the actual implementation and present is simple, be it low-level, and common user interface. Things like '-a chs' are meaningless to non-MBR schemes and as such become warts in the interface and usage. That's ugly. It's for this reason that gpart uses aliases for partition types and not the "raw" and scheme-specific encoding. It is still possible to use the scheme-specific encoding, but it's done in a way that makes it clear that the interpretation of the partition type is scheme-specific. Any scheme implementation can impose whatever is necessary to create a valid partitioning. For MBR this means that partitions are always aligned to CHS. In combination with "-a 4K" is would assume that this means both CHS *and* 4K alignment because the user may not be aware (and should not have to worry) about any implied alignment or rounding. Having "-a 4K" imply that the scheme implementation is to trust that the user knows what she is doing and knows about scheme-specific constraints is counter to the design and in practice absolutely false. It's for this reason that it's better to introduce a special flag (just like the common "force" flag) that serves as the unambiguous signal that the user takes full responsibility for the results. I don't think therefore that a special flag will say "and this time do what I say". It'll will say "Set the usage mode from 'cooked', to 'raw' and take everything I say literally". That's a good way to keep both sides of the interface from having to guess. In short: Don't revert the design and intent of gpart. Let it be the common interface to all partitioning schemes. This means that you want be be able to say "-a 4K" or "-b 2000" without regard for the scheme and know that the scheme will round or adjust accordingly. The gpart utility will lose its power if that is being meddled with, because it's power comes from the fact that you do not have to know the particulars of the scheme in use, nor even the scheme being used in order to work with it. This is key in having it be scriptable. You want a way to let gpart (and the kernel) know that you are aware of the scheme and are going to do things that should not be interpreted as coming from behind a "veil of ignorance" so to speak. --=20 Marcel Moolenaar marcel@xcllnt.net --Apple-Mail=_B739D10C-E07C-40CB-939F-216EB463D05B 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 iEYEARECAAYFAlMCXi0ACgkQpgWlLWHuifa4aACfcS0Yl+oIoV/ZROmmKkMkTP6S kvIAn19DvtYkmlh1qF5tyuGavxCmDb+T =JpvV -----END PGP SIGNATURE----- --Apple-Mail=_B739D10C-E07C-40CB-939F-216EB463D05B-- From owner-freebsd-geom@FreeBSD.ORG Tue Feb 18 17:40:19 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 9BFFA731; Tue, 18 Feb 2014 17:40: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 44CD01FDE; Tue, 18 Feb 2014 17:40:19 +0000 (UTC) Received: from wonkity.com (localhost [127.0.0.1]) by wonkity.com (8.14.8/8.14.8) with ESMTP id s1IHeG29048633 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 18 Feb 2014 10:40:17 -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 s1IHeFIm048630; Tue, 18 Feb 2014 10:40:16 -0700 (MST) (envelope-from wblock@wonkity.com) Date: Tue, 18 Feb 2014 10:40:15 -0700 (MST) From: Warren Block To: Marcel Moolenaar Subject: Re: Allowing arbitrary MBR slice alignment In-Reply-To: <868C9E58-8039-4782-BC74-5C820D1B4F5C@xcllnt.net> Message-ID: References: <29DD155A-790F-4D28-8FFF-FED5466BC336@xcllnt.net> <73BC4100-2F81-41AD-BED7-0A920AE69C76@xcllnt.net> <868C9E58-8039-4782-BC74-5C820D1B4F5C@xcllnt.net> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (wonkity.com [127.0.0.1]); Tue, 18 Feb 2014 10:40:17 -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: Tue, 18 Feb 2014 17:40:19 -0000 On Mon, 17 Feb 2014, Marcel Moolenaar wrote: > In short: Don't revert the design and intent of gpart. Let it > be the common interface to all partitioning schemes. This means > that you want be be able to say "-a 4K" or "-b 2000" without > regard for the scheme and know that the scheme will round or > adjust accordingly. The gpart utility will lose its power if > that is being meddled with, because it's power comes from the > fact that you do not have to know the particulars of the scheme > in use, nor even the scheme being used in order to work with it. > This is key in having it be scriptable. > > You want a way to let gpart (and the kernel) know that you are > aware of the scheme and are going to do things that should not > be interpreted as coming from behind a "veil of ignorance" so > to speak. This is entirely too reasonable for me to argue. :) What needs to be done to proceed? From owner-freebsd-geom@FreeBSD.ORG Tue Feb 18 19:21:36 2014 Return-Path: Delivered-To: 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 E46B3FB1; Tue, 18 Feb 2014 19:21:36 +0000 (UTC) Received: from mail.myota.org (mail.myota.org [85.10.206.105]) by mx1.freebsd.org (Postfix) with ESMTP id 7219919B4; Tue, 18 Feb 2014 19:21:36 +0000 (UTC) Received: from mobile.client (192.133.167.190.d.dyn.codetel.net.do [190.167.133.192] (may be forged)) (authenticated bits=128) by mail.myota.org (8.14.7/8.14.7) with ESMTP id s1IJLTaP057557; Tue, 18 Feb 2014 20:21:32 +0100 (CET) (envelope-from mail@ma17.ata.myota.org) Received: from submit.client ([127.0.0.1]) by schlappy.local (8.14.7/8.14.7) with ESMTP id s1IJLJ2X086289; Tue, 18 Feb 2014 20:21:24 +0100 (CET) (envelope-from mail@ma17.ata.myota.org) Received: (from mu@schlappy.local) by schlappy.local (8.14.7/8.14.7/Submit) id s1IJLJSm086288; Tue, 18 Feb 2014 20:21:19 +0100 (CET) (envelope-from mail@ma17.ata.myota.org) Date: Tue, 18 Feb 2014 20:21:19 +0100 From: Andre Albsmeier To: symbolics@gmx.com Subject: Re: GEOM mentor request Message-ID: <20140218192119.GA86251@schlappy> References: <20131101103158.GA35397@lemon> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20131101103158.GA35397@lemon> X-Echelon: NCSA, F-15, TWA, secret, Minox X-Advice: Drop that crappy M$-Outlook, I'm tired of your viruses! User-Agent: Mutt/1.5.21 (2010-09-15) X-Greylist: Not delayed on 85.10.206.105, ACL: AUTH(59), Origin: DO, OS: FreeBSD 9.x X-Virus-Scanned: clamav-milter 0.98.1 at colo X-Virus-Status: Clean Cc: geom@freebsd.org, hackers@freebsd.org, mail@ma17.ata.myota.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: Tue, 18 Feb 2014 19:21:37 -0000 On Fri, 01-Nov-2013 at 10:31:58 +0000, symbolics@gmx.com wrote: > Hi hackers, > > I have been studying the GEOM documentation and source recently. Is > anyone actively maintaining this subsystem at the moment? I would like > to give it some attention. A few example things I'd like to work on (in > no particular order): > ... > + Probably other bits I can't remember right now. Well, in case you are looking for a probably easy task: Teach gstripe and geli about TRIM as it was done with gmirror in http://svnweb.freebsd.org/base?view=revision&revision=237930 http://svnweb.freebsd.org/base?view=revision&revision=237929 I wanted to have a look a this since more than one year now but time never permitted it (and that's why I am replying to your message after more than 3 months ;-)). -Andre From owner-freebsd-geom@FreeBSD.ORG Sat Feb 22 03:05:25 2014 Return-Path: Delivered-To: freebsd-geom@smarthost.ysv.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 AA1E26C7; Sat, 22 Feb 2014 03:05:25 +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 7BEF21DD6; Sat, 22 Feb 2014 03:05:25 +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 s1M35Pif001431; Sat, 22 Feb 2014 03:05:25 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.8/8.14.8/Submit) id s1M35Pln001430; Sat, 22 Feb 2014 03:05:25 GMT (envelope-from linimon) Date: Sat, 22 Feb 2014 03:05:25 GMT Message-Id: <201402220305.s1M35Pln001430@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-geom@FreeBSD.org From: linimon@FreeBSD.org Subject: Re: bin/186814: gpart(8) when cloning does not transfer label name 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, 22 Feb 2014 03:05:25 -0000 Old Synopsis: Gpart when cloning does not transfer label name New Synopsis: gpart(8) when cloning does not transfer label name Responsible-Changed-From-To: freebsd-bugs->freebsd-geom Responsible-Changed-By: linimon Responsible-Changed-When: Sat Feb 22 03:04:45 UTC 2014 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=186814