From owner-freebsd-geom@FreeBSD.ORG Mon May 23 09:55:30 2011 Return-Path: Delivered-To: freebsd-geom@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 73CCF106566B; Mon, 23 May 2011 09:55:30 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from forward5.mail.yandex.net (forward5.mail.yandex.net [77.88.46.21]) by mx1.freebsd.org (Postfix) with ESMTP id 04D098FC16; Mon, 23 May 2011 09:55:29 +0000 (UTC) Received: from smtp4.mail.yandex.net (smtp4.mail.yandex.net [77.88.46.104]) by forward5.mail.yandex.net (Yandex) with ESMTP id 2E6D0120367E; Mon, 23 May 2011 13:55:28 +0400 (MSD) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1306144528; bh=qoSg5boAADyM07gpCLn3zQICI/vETOupOxh9/Okj2No=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:Content-Type; b=kSutd4CL/N88VHYSxp41T7IRYThyFlfZUwgl7RzWE0jER9/AvCMYffwWvbiDTdaT/ xBTiP5qn1dflCU4cjP5Hl6nzOwxBlnqH+KyhAn9Vc6O+vNox+sIec+puPsUujQQHI9 0GRQ/QiJkJXhT9hVTZt/JefCDNKqp6YNWARuL9MA= Received: from [127.0.0.1] (ns.kirov.so-cdu.ru [77.72.136.145]) by smtp4.mail.yandex.net (Yandex) with ESMTPSA id C7018649806F; Mon, 23 May 2011 13:55:27 +0400 (MSD) Message-ID: <4DDA2F0B.2040203@yandex.ru> Date: Mon, 23 May 2011 13:55:23 +0400 From: "Andrey V. Elsukov" User-Agent: Mozilla Thunderbird 1.5 (FreeBSD/20051231) MIME-Version: 1.0 To: freebsd-geom@FreeBSD.org X-Enigmail-Version: 1.1.1 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig30AE321BAD0215151CE039B2" X-Yandex-Spam: 1 Cc: Marcel Moolenaar , Warner Losh , Poul-Henning Kamp Subject: [RFC] Remove requirement of alignment to track from MBR scheme X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 May 2011 09:55:30 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig30AE321BAD0215151CE039B2 Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: quoted-printable Hi, Since after r221788 many people report about lost of access to their MBR partitions, i prepared new patch: =09 http://people.freebsd.org/~ae/mbr_geometry.diff It removes from GEOM_PART_MBR constraints to alignment to track. Now it is possible to create MBR partitions with exactly specified start offset and size, and they will not be recalculated by kernel. Also the patch adds new option "-g" to the gpart(8) utility. This option can be specified for "add" and "resize" subcommands. gpart(8) uses information about provider's "geometry" and does partition alignment how it did before for MBR. With these changes we give to users the choice how align their partitions and also we still able to use some "broken" partition tables. --=20 WBR, Andrey V. Elsukov --------------enig30AE321BAD0215151CE039B2 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (MingW32) iQEcBAEBAgAGBQJN2i8OAAoJEAHF6gQQyKF67JYIALbrRY+/m4eNWtblIp4W5jg6 UfdqIjfCMGYlLV/OBXOUQeV2RPgocVYJ5hd6jufp7/pV1O3171KFdRByfWyvCsKx SkPU6pLY/9lm1DaWMvUUSQBhyENUSixm+RHbL3LYtMK5EnUVjidFXVCYJsS6qUBi t8sFNwkHKl7zesXSxnjc1if1KfGcU5BZZX6Y8BHdTsWfU2q4J3MIqEWNkPD4oVtc gWZT3whdZf3LadGfkZY4OIWNHYqEPzZN+si1Ofy7aVH4NpwAanYLyw6QZYNTbgIm rCHHp3Y8nOXI7MQQQ3P8hV4r0Jdvu26dOTkP/YU1Ay+/jsSoHnTjDYJiebt0LPk= =mlTB -----END PGP SIGNATURE----- --------------enig30AE321BAD0215151CE039B2-- From owner-freebsd-geom@FreeBSD.ORG Mon May 23 11:06:59 2011 Return-Path: Delivered-To: freebsd-geom@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1DA80106566B for ; Mon, 23 May 2011 11:06:59 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 036638FC1E for ; Mon, 23 May 2011 11:06:59 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p4NB6wpJ051668 for ; Mon, 23 May 2011 11:06:58 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p4NB6wGZ051666 for freebsd-geom@FreeBSD.org; Mon, 23 May 2011 11:06:58 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 23 May 2011 11:06:58 GMT Message-Id: <201105231106.p4NB6wGZ051666@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 Cc: Subject: Current problem reports assigned to freebsd-geom@FreeBSD.org X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 May 2011 11:06:59 -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/157108 geom [gjournal] dumpon(8) fails on gjournal providers o kern/155994 geom [geom] Long "Suspend time" when reading large files fr 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/144905 geom [geom][geom_part] panic in gpart_ctlreq when unpluggin 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/134922 geom [gmirror] [panic] kernel panic when use fdisk on disk 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 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 f kern/128276 geom [gmirror] machine lock up when gmirror module is used 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/121364 geom [gmirror] Removing all providers create a "zombie" mir 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/114532 geom [geom] GEOM_MIRROR shows up in kldstat even if compile f kern/113957 geom [gmirror] gmirror is intermittently reporting a degrad 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. 52 problems total. From owner-freebsd-geom@FreeBSD.ORG Mon May 23 13:05:45 2011 Return-Path: Delivered-To: freebsd-geom@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C5DC9106564A for ; Mon, 23 May 2011 13:05:45 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 1F5448FC14 for ; Mon, 23 May 2011 13:05:44 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id QAA12256; Mon, 23 May 2011 16:05:42 +0300 (EEST) (envelope-from avg@FreeBSD.org) Message-ID: <4DDA5BA4.2000807@FreeBSD.org> Date: Mon, 23 May 2011 16:05:40 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.17) Gecko/20110504 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: "Andrey V. Elsukov" , freebsd-geom@FreeBSD.org References: <4DDA2F0B.2040203@yandex.ru> In-Reply-To: <4DDA2F0B.2040203@yandex.ru> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: Subject: Re: [RFC] Remove requirement of alignment to track from MBR scheme X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 May 2011 13:05:45 -0000 on 23/05/2011 12:55 Andrey V. Elsukov said the following: > Hi, > > Since after r221788 many people report about lost of access to their > MBR partitions, i prepared new patch: > > http://people.freebsd.org/~ae/mbr_geometry.diff > > It removes from GEOM_PART_MBR constraints to alignment to track. > Now it is possible to create MBR partitions with exactly specified > start offset and size, and they will not be recalculated by kernel. > > Also the patch adds new option "-g" to the gpart(8) utility. This > option can be specified for "add" and "resize" subcommands. > gpart(8) uses information about provider's "geometry" and does > partition alignment how it did before for MBR. > > With these changes we give to users the choice how align their > partitions and also we still able to use some "broken" partition > tables. My personal opinion is that removing geometry enforcement (or even consideration) is a correct decision. -- Andriy Gapon From owner-freebsd-geom@FreeBSD.ORG Mon May 23 16:32:48 2011 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1E5C5106566B; Mon, 23 May 2011 16:32:48 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id BF8828FC17; Mon, 23 May 2011 16:32:47 +0000 (UTC) Received: from [10.30.101.53] ([209.117.142.2]) (authenticated bits=0) by harmony.bsdimp.com (8.14.4/8.14.3) with ESMTP id p4NGEo75003737 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES128-SHA bits=128 verify=NO); Mon, 23 May 2011 10:14:56 -0600 (MDT) (envelope-from imp@bsdimp.com) Mime-Version: 1.0 (Apple Message framework v1084) From: Warner Losh In-Reply-To: <4DDA2F0B.2040203@yandex.ru> Date: Mon, 23 May 2011 10:14:45 -0600 Message-Id: <6DF62987-141B-4BB3-8E8D-9966EBAC828B@bsdimp.com> References: <4DDA2F0B.2040203@yandex.ru> To: "Andrey V. Elsukov" X-Mailer: Apple Mail (2.1084) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (harmony.bsdimp.com [10.0.0.6]); Mon, 23 May 2011 10:14:57 -0600 (MDT) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Marcel Moolenaar , Warner Losh , Poul-Henning Kamp , freebsd-geom@freebsd.org Subject: Re: [RFC] Remove requirement of alignment to track from MBR scheme X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 May 2011 16:32:48 -0000 On May 23, 2011, at 3:55 AM, Andrey V. Elsukov wrote: > Hi, >=20 > Since after r221788 many people report about lost of access to their > MBR partitions, i prepared new patch: > =09 > http://people.freebsd.org/~ae/mbr_geometry.diff >=20 > It removes from GEOM_PART_MBR constraints to alignment to track. > Now it is possible to create MBR partitions with exactly specified > start offset and size, and they will not be recalculated by kernel. >=20 > Also the patch adds new option "-g" to the gpart(8) utility. This > option can be specified for "add" and "resize" subcommands. > gpart(8) uses information about provider's "geometry" and does > partition alignment how it did before for MBR. >=20 > With these changes we give to users the choice how align their > partitions and also we still able to use some "broken" partition > tables. This looks fairly good. I have one or two minor questions... Since we don't have a good review tool for the project, this may seem a = little fragmented, but here goes: + if (pp->sectorsize > 4096) + return (EOPNOTSUPP); What's the motivation for this? This seems unrelated to the problem at = hand. It may be good, but 4096-byte sector size is very new and I'm not = sure MS-DOS can cope... :) There has been a long tradition in the MBR, = however, of supporting different sector sizes to allow old-old-old = school floppies that had 128 or 256 byte sectors to work, as well as = allowing the supper-compressed 1.77MB floppies to work with their = 1024-byte (or was that 2048-byte?) sectors. Not sure this really = matters for reading, and for writing this case is so far beyond the edge = I'm not even sure why I bring it up[*] In any event, I'd be tempted to use a #define for 4096 like = MBR_MAX_SECTOR_SIZE. - msize =3D MIN(pp->mediasize / pp->sectorsize, UINT32_MAX); + msize =3D MIN(pp->mediasize / pp->sectorsize, 2 * UINT32_MAX); Why this change? I think that it is in two places. The rest looks good. Thanks for coming up with such a complete patch = after my grumpy email... Warner [*] I guess old farts like to bring up this stuff to show how old they = are :)= From owner-freebsd-geom@FreeBSD.ORG Mon May 23 16:50:23 2011 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C2291106564A; Mon, 23 May 2011 16:50:23 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from forward9.mail.yandex.net (forward9.mail.yandex.net [77.88.61.48]) by mx1.freebsd.org (Postfix) with ESMTP id 48F8D8FC15; Mon, 23 May 2011 16:50:23 +0000 (UTC) Received: from smtp6.mail.yandex.net (smtp6.mail.yandex.net [77.88.61.56]) by forward9.mail.yandex.net (Yandex) with ESMTP id D3BB2CE1277; Mon, 23 May 2011 20:50:20 +0400 (MSD) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1306169420; bh=5lPzeZkwLR/+uixxI+ZJX+E51kwz5AAst8HdEojL0M4=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type; b=pumlzOBlGp16tvyMTURwaJWKuaILIrHl/Xk4zc5mpy06GnZCZ5bSxnVrvisXTTDxo OvVh9iG12ZT92aWk/jUJLDBNbjzE6hN7QJtEvr5rdNZXlnbat10RDlb/wDr3aDh4Ns uiuMum57meVQiXjO5fZfAWjiM1MpPTXdxlnLlD4g= Received: from [178.141.6.24] (dynamic-178-141-6-24.kirov.comstar-r.ru [178.141.6.24]) by smtp6.mail.yandex.net (Yandex) with ESMTPSA id 5C53F2A8064; Mon, 23 May 2011 20:50:20 +0400 (MSD) Message-ID: <4DDA9046.8050902@yandex.ru> Date: Mon, 23 May 2011 20:50:14 +0400 From: "Andrey V. Elsukov" User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.17) Gecko/20110429 Thunderbird/3.1.10 MIME-Version: 1.0 To: Warner Losh References: <4DDA2F0B.2040203@yandex.ru> <6DF62987-141B-4BB3-8E8D-9966EBAC828B@bsdimp.com> In-Reply-To: <6DF62987-141B-4BB3-8E8D-9966EBAC828B@bsdimp.com> X-Enigmail-Version: 1.1.2 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig4B22ABB49CE22B6687A90B45" X-Yandex-Spam: 1 Cc: Marcel Moolenaar , Poul-Henning Kamp , freebsd-geom@freebsd.org Subject: Re: [RFC] Remove requirement of alignment to track from MBR scheme X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 May 2011 16:50:23 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig4B22ABB49CE22B6687A90B45 Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: quoted-printable On 23.05.2011 20:14, Warner Losh wrote: > Since we don't have a good review tool for the project, this may seem a= > little fragmented, but here goes: >=20 > + if (pp->sectorsize > 4096) > + return (EOPNOTSUPP); >=20 > What's the motivation for this? This seems unrelated to the problem at= > hand. It may be good, but 4096-byte sector size is very new and I'm no= t > sure MS-DOS can cope... :) There has been a long tradition in the MBR= , > however, of supporting different sector sizes to allow old-old-old > school floppies that had 128 or 256 byte sectors to work, as well as > allowing the supper-compressed 1.77MB floppies to work with their > 1024-byte (or was that 2048-byte?) sectors. Not sure this really > matters for reading, and for writing this case is so far beyond the edg= e > I'm not even sure why I bring it up[*] We have similar check in the g_part_mbr_probe function, and since we do not support sectorsize > 4096 in the probe method, i do not think we should try to create MBR for these providers. > In any event, I'd be tempted to use a #define for 4096 like > MBR_MAX_SECTOR_SIZE. >=20 > - msize =3D MIN(pp->mediasize / pp->sectorsize, UINT32_MAX); > + msize =3D MIN(pp->mediasize / pp->sectorsize, 2 * UINT32_MAX); >=20 > Why this change? I think that it is in two places. Currently we have limit to msize =3D UINT32_MAX, but partition in MBR has= start offset and size (not end offset). Theoretically it can have size that is up to UINT32_MAX sectors, also start offset can be UINT32_MAX. And for example, for 4T disk we can have 2 partitions with 2TB size. --=20 WBR, Andrey V. Elsukov --------------enig4B22ABB49CE22B6687A90B45 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (FreeBSD) iQEcBAEBAgAGBQJN2pBLAAoJEAHF6gQQyKF6gVUH/iNhIq4mBZbwY2tIQrcD6wo5 z/OaKTaV/TtfEd5T/0Kj5AKSUw/w2o+uK8ANPk1lucou/fpl6k5vIuQ/X3ZAA8ub Pijq0Cuj07wJahOz+JOEeR4cOoOlp4Qk5ifVsGuXR7SzUwuVecy+Zc91iZk1Oa0e P4NhyZSutUcya60jp9kiR9xt5ESl4V3R7pD0zJV8+ajzwBJ3JZwneGPX2n8IpA0U Iz+gAWXyzXyxzuPwSzCmw6uLa4OYqB8+0vrHrYQxLp21a50zqwh/LFgQPFyTYuYn +KxqTtkOmUM8HZvaztq9Sg+ub/WivYrouwSCyBNKkRqWvSZryfX1MrEint2J09g= =iDps -----END PGP SIGNATURE----- --------------enig4B22ABB49CE22B6687A90B45-- From owner-freebsd-geom@FreeBSD.ORG Mon May 23 16:56:30 2011 Return-Path: Delivered-To: freebsd-geom@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 580EC1065673; Mon, 23 May 2011 16:56:30 +0000 (UTC) (envelope-from marcel@xcllnt.net) Received: from mail.xcllnt.net (mail.xcllnt.net [70.36.220.4]) by mx1.freebsd.org (Postfix) with ESMTP id 176D78FC13; Mon, 23 May 2011 16:56:30 +0000 (UTC) Received: from sa-nc-common-178.static.jnpr.net (natint3.juniper.net [66.129.224.36]) (authenticated bits=0) by mail.xcllnt.net (8.14.4/8.14.4) with ESMTP id p4NGZvgM016145 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 23 May 2011 09:36:03 -0700 (PDT) (envelope-from marcel@xcllnt.net) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Marcel Moolenaar In-Reply-To: <4DDA2F0B.2040203@yandex.ru> Date: Mon, 23 May 2011 09:35:52 -0700 Content-Transfer-Encoding: 7bit Message-Id: References: <4DDA2F0B.2040203@yandex.ru> To: "Andrey V. Elsukov" X-Mailer: Apple Mail (2.1084) Cc: Marcel Moolenaar , Warner Losh , Poul-Henning Kamp , freebsd-geom@FreeBSD.org Subject: Re: [RFC] Remove requirement of alignment to track from MBR scheme X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 May 2011 16:56:30 -0000 On May 23, 2011, at 2:55 AM, Andrey V. Elsukov wrote: > Hi, > > Since after r221788 many people report about lost of access to their > MBR partitions, i prepared new patch: > > http://people.freebsd.org/~ae/mbr_geometry.diff > > It removes from GEOM_PART_MBR constraints to alignment to track. > Now it is possible to create MBR partitions with exactly specified > start offset and size, and they will not be recalculated by kernel. Ok, slow down. While I don't mind that we remove the track alignment when we create MBR partitions, I don't think we should slap another "big" change on top of the previous "big" change. Can I ask we first properly revert the changes we made so far just so that the revision history clearly states that we cannot enforce track boundaries. Let's also make sure we have the proper fix for the "negative partition size" problem that started this whole thing. And *then* we wait a week, just to be sure we let the dust settle. I think we've had enough rushed and ill thought-out changes going in already and I can see that not aligning MBR partitions on a track boundary is potentially perceived as a PITA violation. Thanks, -- Marcel Moolenaar marcel@xcllnt.net From owner-freebsd-geom@FreeBSD.ORG Mon May 23 17:43:40 2011 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E9EDC1065675; Mon, 23 May 2011 17:43:40 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 834568FC1F; Mon, 23 May 2011 17:43:40 +0000 (UTC) Received: from [10.30.101.53] ([209.117.142.2]) (authenticated bits=0) by harmony.bsdimp.com (8.14.4/8.14.3) with ESMTP id p4NHe1LG004826 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES128-SHA bits=128 verify=NO); Mon, 23 May 2011 11:40:03 -0600 (MDT) (envelope-from imp@bsdimp.com) Mime-Version: 1.0 (Apple Message framework v1084) From: Warner Losh In-Reply-To: <4DDA9046.8050902@yandex.ru> Date: Mon, 23 May 2011 11:39:54 -0600 Message-Id: References: <4DDA2F0B.2040203@yandex.ru> <6DF62987-141B-4BB3-8E8D-9966EBAC828B@bsdimp.com> <4DDA9046.8050902@yandex.ru> To: "Andrey V. Elsukov" X-Mailer: Apple Mail (2.1084) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (harmony.bsdimp.com [10.0.0.6]); Mon, 23 May 2011 11:40:04 -0600 (MDT) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Marcel Moolenaar , Poul-Henning Kamp , freebsd-geom@freebsd.org Subject: Re: [RFC] Remove requirement of alignment to track from MBR scheme X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 May 2011 17:43:41 -0000 On May 23, 2011, at 10:50 AM, Andrey V. Elsukov wrote: >=20 >> In any event, I'd be tempted to use a #define for 4096 like >> MBR_MAX_SECTOR_SIZE. >>=20 >> - msize =3D MIN(pp->mediasize / pp->sectorsize, UINT32_MAX); >> + msize =3D MIN(pp->mediasize / pp->sectorsize, 2 * UINT32_MAX); >>=20 >> Why this change? I think that it is in two places. >=20 > Currently we have limit to msize =3D UINT32_MAX, but partition in MBR = has > start offset and size (not end offset). Theoretically it can have size > that is up to UINT32_MAX sectors, also start offset can be UINT32_MAX. > And for example, for 4T disk we can have 2 partitions with 2TB size. Are there any extant examples of this? The CW is that the maximum size = for an MBR device is 2TB. Warner= From owner-freebsd-geom@FreeBSD.ORG Mon May 23 17:44:05 2011 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 82C5C1065675; Mon, 23 May 2011 17:44:05 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 1E90D8FC08; Mon, 23 May 2011 17:44:05 +0000 (UTC) Received: from [10.30.101.53] ([209.117.142.2]) (authenticated bits=0) by harmony.bsdimp.com (8.14.4/8.14.3) with ESMTP id p4NHcfNR004824 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES128-SHA bits=128 verify=NO); Mon, 23 May 2011 11:38:42 -0600 (MDT) (envelope-from imp@bsdimp.com) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: Date: Mon, 23 May 2011 11:38:36 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <9ED563AB-7B35-40F4-A33E-015317858401@bsdimp.com> References: <4DDA2F0B.2040203@yandex.ru> To: Marcel Moolenaar X-Mailer: Apple Mail (2.1084) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (harmony.bsdimp.com [10.0.0.6]); Mon, 23 May 2011 11:38:43 -0600 (MDT) Cc: "Andrey V. Elsukov" , Warner Losh , Poul-Henning Kamp , Marcel Moolenaar , freebsd-geom@freebsd.org Subject: Re: [RFC] Remove requirement of alignment to track from MBR scheme X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 May 2011 17:44:05 -0000 On May 23, 2011, at 10:35 AM, Marcel Moolenaar wrote: > I think we've had enough rushed and ill thought-out changes going > in already and I can see that not aligning MBR partitions on a track > boundary is potentially perceived as a PITA violation. I can understand only generating MBRs on a track boundary. After all, = that's being conservative about what we generate. However, we have to = accept MBRs that don't end on a track boundary because that's the = de-facto standard. What we're doing now, adjusting the size to the = track boundary, is flat out wrong. Either we should accept the size or = reject it. There's nothing I've ever seen to suggest that one should = adjust it in any way when we encounter one that's not track aligned. = The behavior of Windows, Linux and MacOS suggests the proper thing to do = is just accept it. The 16GB drive I have also suggests that we just = accept it, at least in some cases. I'm all for carefully moving forward. There were parts of the patch = that seemed to be over-reaching. Personally, I'd just do something like the following since it reflects = what others do and implements the de-facto meaning of the MBR: Index: sys/geom/part/g_part_mbr.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- sys/geom/part/g_part_mbr.c (revision 222183) +++ sys/geom/part/g_part_mbr.c (working copy) @@ -473,7 +473,7 @@ =20 basetable->gpt_entries =3D NDOSPART; basetable->gpt_first =3D basetable->gpt_sectors; - basetable->gpt_last =3D msize - (msize % basetable->gpt_sectors) = - 1; + basetable->gpt_last =3D msize - 1; =20 g_free(buf); return (0); Warner From owner-freebsd-geom@FreeBSD.ORG Mon May 23 17:52:11 2011 Return-Path: Delivered-To: freebsd-geom@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 35031106566B; Mon, 23 May 2011 17:52:11 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id E6F8D8FC0C; Mon, 23 May 2011 17:52:10 +0000 (UTC) Received: from critter.freebsd.dk (critter.freebsd.dk [192.168.61.3]) by phk.freebsd.dk (Postfix) with ESMTP id 339575E08; Mon, 23 May 2011 17:33:04 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.4/8.14.4) with ESMTP id p4NHX3JQ098006; Mon, 23 May 2011 17:33:03 GMT (envelope-from phk@critter.freebsd.dk) To: Marcel Moolenaar From: "Poul-Henning Kamp" In-Reply-To: Your message of "Mon, 23 May 2011 09:35:52 MST." Content-Type: text/plain; charset=ISO-8859-1 Date: Mon, 23 May 2011 17:33:03 +0000 Message-ID: <98005.1306171983@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: Marcel Moolenaar , "Andrey V. Elsukov" , Warner Losh , freebsd-geom@FreeBSD.org Subject: Re: [RFC] Remove requirement of alignment to track from MBR scheme X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 May 2011 17:52:11 -0000 In message , Marcel Moolenaar writes: >I think we've had enough rushed and ill thought-out changes going >in already and I can see that not aligning MBR partitions on a track >boundary is potentially perceived as a PITA violation. We should suggest track alignment on creation, but not enforce it. There are a lot of valid reasons to not track-align, most commonly the desire to not shoot RAID-5 performance in the foot. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-geom@FreeBSD.ORG Mon May 23 17:59:33 2011 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 74DC8106564A; Mon, 23 May 2011 17:59:33 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from forward1.mail.yandex.net (forward1.mail.yandex.net [77.88.46.6]) by mx1.freebsd.org (Postfix) with ESMTP id 2068C8FC13; Mon, 23 May 2011 17:59:32 +0000 (UTC) Received: from smtp3.mail.yandex.net (smtp3.mail.yandex.net [77.88.46.103]) by forward1.mail.yandex.net (Yandex) with ESMTP id 463761242BCA; Mon, 23 May 2011 21:59:29 +0400 (MSD) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1306173569; bh=8SYN+FRARwtBK2sgwU9gakU6vLfG4tz7yoyu+vLQJhA=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type; b=I+oHUWwHQUEFWKTWV+SWS3ejv5TnzyH6gcpB2K2PVYpaNQQ7Kxz10R8cRynVQRfTQ HSp9ywFyPNgiT3tCgOy+vjVXPZ4zhaoiu03haj72XX1L3BEMChjRCRruH08UYpcm4s LBLKZEtuBTdjS2g74VCWvy/gkuzYWXur0uH9H9jU= Received: from [178.141.6.24] (dynamic-178-141-6-24.kirov.comstar-r.ru [178.141.6.24]) by smtp3.mail.yandex.net (Yandex) with ESMTPSA id 999C769800A8; Mon, 23 May 2011 21:59:28 +0400 (MSD) Message-ID: <4DDAA07B.9030004@yandex.ru> Date: Mon, 23 May 2011 21:59:23 +0400 From: "Andrey V. Elsukov" User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.17) Gecko/20110429 Thunderbird/3.1.10 MIME-Version: 1.0 To: Warner Losh References: <4DDA2F0B.2040203@yandex.ru> <9ED563AB-7B35-40F4-A33E-015317858401@bsdimp.com> In-Reply-To: <9ED563AB-7B35-40F4-A33E-015317858401@bsdimp.com> X-Enigmail-Version: 1.1.2 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigDBA06A23D48A1203A1B5BF19" X-Yandex-Spam: 1 Cc: freebsd-geom@freebsd.org, Warner Losh , Poul-Henning Kamp , Marcel Moolenaar , Marcel Moolenaar Subject: Re: [RFC] Remove requirement of alignment to track from MBR scheme X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 May 2011 17:59:33 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigDBA06A23D48A1203A1B5BF19 Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: quoted-printable On 23.05.2011 21:38, Warner Losh wrote: > I'm all for carefully moving forward. There were parts of the patch > that seemed to be over-reaching. >=20 > Personally, I'd just do something like the following since it > reflects what others do and implements the de-facto meaning of the > MBR: >=20 > Index: sys/geom/part/g_part_mbr.c=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=20 > --- sys/geom/part/g_part_mbr.c (revision 222183) +++ > sys/geom/part/g_part_mbr.c (working copy) @@ -473,7 +473,7 @@ >=20 > basetable->gpt_entries =3D NDOSPART; basetable->gpt_first =3D > basetable->gpt_sectors; - basetable->gpt_last =3D msize - (msize % > basetable->gpt_sectors) - 1; + basetable->gpt_last =3D msize - 1; There was report with different problem, the user created a partition that is aligned to 4KB sector size and it starts from the inside of first track, i.e. start offset < 63. And as he said, he did use sysinstall(8) for partitioning. --=20 WBR, Andrey V. Elsukov --------------enigDBA06A23D48A1203A1B5BF19 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (FreeBSD) iQEcBAEBAgAGBQJN2qB/AAoJEAHF6gQQyKF6HogH/3PaIT3CV6RofFope6Zjll+P XeAmLIkYvIVklPrXu34PCr+efhQ1gF0RjEttp1IvuF1KZPiGg06aU46On9vkUX7q Mn9DpO1eZSV0SwGdD332hRsN97OeU4zhh+QVwzPJLJ8ohA79BBFPmhAsqLig0hkm 1eQZNexsb4n5+BbWB681aZ/RCT9X8StoUeuOxsdFtnOvlEeZOGSRXESHc4Sgbl1x X8GfmDxSswQJHpumzwZZFaoJ2w4802pQzdxBBwjoR7M1I4JB/iAyAl2uRaS0hEDs 1CtluiLtItHps1z+PMqtua/he61k4eoqgtgVygoGKkRd3pPPoqiwD1+I1vPMfdo= =D8nU -----END PGP SIGNATURE----- --------------enigDBA06A23D48A1203A1B5BF19-- From owner-freebsd-geom@FreeBSD.ORG Mon May 23 20:27:21 2011 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A2512106566C for ; Mon, 23 May 2011 20:27:21 +0000 (UTC) (envelope-from james-freebsd-fs2@jrv.org) Received: from zimbra.jrv.org (adsl-70-243-84-11.dsl.austtx.swbell.net [70.243.84.11]) by mx1.freebsd.org (Postfix) with ESMTP id 777528FC08 for ; Mon, 23 May 2011 20:27:20 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zimbra.jrv.org (Postfix) with ESMTP id A604416A07B for ; Mon, 23 May 2011 15:08:36 -0500 (CDT) X-Virus-Scanned: amavisd-new at zimbra.housenet.jrv Received: from zimbra.jrv.org ([127.0.0.1]) by localhost (zimbra.housenet.jrv [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a5I+gonlo8Wg for ; Mon, 23 May 2011 15:08:36 -0500 (CDT) Received: from [10.0.2.15] (adsl-70-243-84-14.dsl.austtx.swbell.net [70.243.84.14]) by zimbra.jrv.org (Postfix) with ESMTPSA id 1181916A048 for ; Mon, 23 May 2011 15:08:36 -0500 (CDT) Message-ID: <4DDABEFE.2020400@jrv.org> Date: Mon, 23 May 2011 15:09:34 -0500 From: "James R. Van Artsdalen" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: freebsd-geom@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [RFC] Remove requirement of alignment to track from MBR scheme X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 May 2011 20:27:21 -0000 On 5/23/2011 4:55 AM, Andrey V. Elsukov wrote: > Now it is possible to create MBR partitions with exactly specified > start offset and size, and they will not be recalculated by kernel. If a partition is created this way, what will happen if the disk is then accessed by a FreeBSD kernel before this patch? If the result is that only newer kernels are supported by the patch, why not use GPT instead? Unaligned partitions is a "new" partition table feature, but I'm not sure how many decades "new" is in this case. Which other operating systems can read unaligned partitions (and which can't)? If the problem is that the kernel is making an undesirable geometry assumption then perhaps there needs to be a way to change that geometry assumption. From owner-freebsd-geom@FreeBSD.ORG Tue May 24 05:29:01 2011 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 48235106564A; Tue, 24 May 2011 05:29:01 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from forward5.mail.yandex.net (forward5.mail.yandex.net [77.88.46.21]) by mx1.freebsd.org (Postfix) with ESMTP id E6BA08FC0C; Tue, 24 May 2011 05:29:00 +0000 (UTC) Received: from smtp3.mail.yandex.net (smtp3.mail.yandex.net [77.88.46.103]) by forward5.mail.yandex.net (Yandex) with ESMTP id 2615D12025D9; Tue, 24 May 2011 09:28:59 +0400 (MSD) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1306214939; bh=26SHVTu+VnrGFkW6HvzUBIoFNhncCEnYFiG2uypOeqc=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type; b=CHX8R+DvS7hNCPuGMyo0cCXHQPp1NBZLxTsLoppnAxmHdsJ4Dvpfwz3eYGS+vX6X6 6a9OF/w+razSKUZ/xiO0LaW8NH7i089CsnjO1x7ImHlBZhQqyFEeSXlzSFjIsW6TjW 8+iQDwYFXoZ8/yV29zorm9P73gHF+mJJfc6OqtTA= Received: from [127.0.0.1] (ns.kirov.so-cdu.ru [77.72.136.145]) by smtp3.mail.yandex.net (Yandex) with ESMTPSA id BB8A16980074; Tue, 24 May 2011 09:28:58 +0400 (MSD) Message-ID: <4DDB4213.1030008@yandex.ru> Date: Tue, 24 May 2011 09:28:51 +0400 From: "Andrey V. Elsukov" User-Agent: Mozilla Thunderbird 1.5 (FreeBSD/20051231) MIME-Version: 1.0 To: Warner Losh References: <4DDA2F0B.2040203@yandex.ru> <6DF62987-141B-4BB3-8E8D-9966EBAC828B@bsdimp.com> <4DDA9046.8050902@yandex.ru> In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigD549C440B29C497219B55B68" X-Yandex-Spam: 1 Cc: Marcel Moolenaar , Poul-Henning Kamp , freebsd-geom@freebsd.org Subject: Re: [RFC] Remove requirement of alignment to track from MBR scheme X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 May 2011 05:29:01 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigD549C440B29C497219B55B68 Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: quoted-printable On 23.05.2011 21:39, Warner Losh wrote: >>> In any event, I'd be tempted to use a #define for 4096 like >>> MBR_MAX_SECTOR_SIZE. >>> >>> -msize =3D MIN(pp->mediasize / pp->sectorsize, UINT32_MAX); >>> +msize =3D MIN(pp->mediasize / pp->sectorsize, 2 * UINT32_MAX); >>> >>> Why this change? I think that it is in two places. >> >> Currently we have limit to msize =3D UINT32_MAX, but partition in MBR = has >> start offset and size (not end offset). Theoretically it can have size= >> that is up to UINT32_MAX sectors, also start offset can be UINT32_MAX.= >> And for example, for 4T disk we can have 2 partitions with 2TB size. >=20 > Are there any extant examples of this? The CW is that the maximum size= for an MBR device is 2TB. I tried with 6T md(4) device and it is possible to create 2 partitions with 2T size, but it is inconvenient to do: # gpart show md0 =3D> 1 8589934589 md0 MBR (5.5T) 1 8589934589 - free - (4T) # gpart add -t freebsd -s 2T md0 gpart: Invalid argument # gpart add -t freebsd -s `printf %d 0xFFFFFFFE` md0 md0s1 added # gpart add -t freebsd md0 md0s2 added # gpart show md0 =3D> 1 8589934589 md0 MBR (5.5T) 1 4294967294 1 freebsd (2T) 4294967295 4294967295 2 freebsd (2T) So, i updated the patch and removed this support. Also i removed some checks that scheme independent code does. --=20 WBR, Andrey V. Elsukov --------------enigD549C440B29C497219B55B68 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (MingW32) iQEcBAEBAgAGBQJN20IaAAoJEAHF6gQQyKF6dU4IAJlQSGVZdQIkQZvfgNc8ErKm 0sWNd1r+QwG/XgeWDh9gIwgbQ06VlhoIIBL1vwqJeQsuxDPHCVrm5p8+KM7rvbx5 +mXsOP+xgK/qIVF1ZDMq9BKrRb9cDi8OfDiHGUs2ersjZMnybcj3LdLjAFCb9oe5 rQuR44nNSu3hJRD+Go/OcE7NiKuDTuKc+Yy5FK2nZyR/fmKtKzdj3KYuo9X5Ik+S 7b+1ZwXUKZcYUctqt1Yuh5lZZLmOPqzroKsOk4wuWzAnzp1bfwx+YTnEhz+t1Ai8 hKhR+6XfZlXxFXohEHy9Z5FyXKlu8R0AQrpBnp/eJ6unmd3V3cBZEuU2YFCBBL4= =XtEk -----END PGP SIGNATURE----- --------------enigD549C440B29C497219B55B68-- From owner-freebsd-geom@FreeBSD.ORG Tue May 24 06:43:20 2011 Return-Path: Delivered-To: freebsd-geom@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E1C10106566B for ; Tue, 24 May 2011 06:43:20 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 0D9768FC08 for ; Tue, 24 May 2011 06:43:19 +0000 (UTC) Received: from porto.topspin.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id JAA24427; Tue, 24 May 2011 09:43:03 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost.topspin.kiev.ua ([127.0.0.1]) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1QOlKY-0006aZ-5V; Tue, 24 May 2011 09:43:02 +0300 Message-ID: <4DDB5375.6050004@FreeBSD.org> Date: Tue, 24 May 2011 09:43:01 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.17) Gecko/20110503 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: Warner Losh , Marcel Moolenaar References: <4DDA2F0B.2040203@yandex.ru> <9ED563AB-7B35-40F4-A33E-015317858401@bsdimp.com> In-Reply-To: <9ED563AB-7B35-40F4-A33E-015317858401@bsdimp.com> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "Andrey V. Elsukov" , freebsd-geom@FreeBSD.org Subject: Re: [RFC] Remove requirement of alignment to track from MBR scheme X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 May 2011 06:43:21 -0000 on 23/05/2011 20:38 Warner Losh said the following: > > On May 23, 2011, at 10:35 AM, Marcel Moolenaar wrote: >> I think we've had enough rushed and ill thought-out changes going >> in already and I can see that not aligning MBR partitions on a track >> boundary is potentially perceived as a PITA violation. _PITA_ violation? :-) As to POLA - yeah, I can see people getting astonished that finally FreeBSD got its sh*t together and did the right thing, years after all other OSes (even Winddows) had done it. > I can understand only generating MBRs on a track boundary. No. E.g. I wanted to create a 4KB aligned MBR slice, but our tools insisted on using a 63 sector alignment. In fact, the value that I provided was silently rounded to the value that gpart thought was best for me. Really, if a user says to gpart "do whatever alignment you want", then I could see using geometry-based values, but I still think that we should not do that even in that case, I think we would be better off using some nice 2^N alignment. If a user says "use this alignment or slice start", then the tool should just shut up and do exactly what the user told it. This is _not_ just my 2 cents :-) -- Andriy Gapon From owner-freebsd-geom@FreeBSD.ORG Tue May 24 06:44:16 2011 Return-Path: Delivered-To: freebsd-geom@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 27F731065674 for ; Tue, 24 May 2011 06:44:16 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 59F2B8FC15 for ; Tue, 24 May 2011 06:44:15 +0000 (UTC) Received: from porto.topspin.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id JAA24453; Tue, 24 May 2011 09:44:10 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost.topspin.kiev.ua ([127.0.0.1]) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1QOlLd-0006ae-Ui; Tue, 24 May 2011 09:44:09 +0300 Message-ID: <4DDB53B9.4050206@FreeBSD.org> Date: Tue, 24 May 2011 09:44:09 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.17) Gecko/20110503 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: "James R. Van Artsdalen" References: <4DDABEFE.2020400@jrv.org> In-Reply-To: <4DDABEFE.2020400@jrv.org> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-geom@FreeBSD.org Subject: Re: [RFC] Remove requirement of alignment to track from MBR scheme X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 May 2011 06:44:16 -0000 on 23/05/2011 23:09 James R. Van Artsdalen said the following: > If the problem is that the kernel is making an undesirable geometry > assumption then perhaps there needs to be a way to change that geometry > assumption. There is no spoon^Wgeometry. -- Andriy Gapon From owner-freebsd-geom@FreeBSD.ORG Tue May 24 09:04:59 2011 Return-Path: Delivered-To: freebsd-geom@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2A769106564A; Tue, 24 May 2011 09:04:59 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from forward4.mail.yandex.net (forward4.mail.yandex.net [77.88.46.9]) by mx1.freebsd.org (Postfix) with ESMTP id B08C78FC08; Tue, 24 May 2011 09:04:58 +0000 (UTC) Received: from smtp2.mail.yandex.net (smtp2.mail.yandex.net [77.88.46.102]) by forward4.mail.yandex.net (Yandex) with ESMTP id EE7C05020D9; Tue, 24 May 2011 13:04:56 +0400 (MSD) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1306227897; bh=wLFtAv2mpWEMTh1XXSOTUUtmENq7X0g9fuMqTriUGsM=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type; b=XNwJCbmPWWqFThXHf1ZL6VvjzywJDdlMJKFdX6Pns9JiKigzILwGbUi2uOl0v85wb SKSa8aOn0XfrJqj4+GVHO/kHbqGLDEK+CHlB8AHgeG7FvBc8m8fojDkXFWorWh7lOt HZB6swRpuloql8VBGSTBghep7slNdFgje86R2QBk= Received: from [127.0.0.1] (mail.kirov.so-cdu.ru [77.72.136.145]) by smtp2.mail.yandex.net (Yandex) with ESMTPSA id 89EDB5D100D1; Tue, 24 May 2011 13:04:56 +0400 (MSD) Message-ID: <4DDB74B2.702@yandex.ru> Date: Tue, 24 May 2011 13:04:50 +0400 From: "Andrey V. Elsukov" User-Agent: Mozilla Thunderbird 1.5 (FreeBSD/20051231) MIME-Version: 1.0 To: Andriy Gapon References: <4DDA2F0B.2040203@yandex.ru> <9ED563AB-7B35-40F4-A33E-015317858401@bsdimp.com> <4DDB5375.6050004@FreeBSD.org> In-Reply-To: <4DDB5375.6050004@FreeBSD.org> X-Enigmail-Version: 1.1.1 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigF71682544821A7544380DDF5" X-Yandex-Spam: 1 Cc: Marcel Moolenaar , Warner Losh , freebsd-geom@FreeBSD.org Subject: Re: [RFC] Remove requirement of alignment to track from MBR scheme X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 May 2011 09:04:59 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigF71682544821A7544380DDF5 Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: quoted-printable On 24.05.2011 10:43, Andriy Gapon wrote: >> On May 23, 2011, at 10:35 AM, Marcel Moolenaar wrote: >>> I think we've had enough rushed and ill thought-out changes going >>> in already and I can see that not aligning MBR partitions on a track >>> boundary is potentially perceived as a PITA violation. >=20 > _PITA_ violation? :-) > As to POLA - yeah, I can see people getting astonished that finally Fre= eBSD got > its sh*t together and did the right thing, years after all other OSes (= even > Winddows) had done it. >=20 >> I can understand only generating MBRs on a track boundary. >=20 > No. E.g. I wanted to create a 4KB aligned MBR slice, but our tools ins= isted on > using a 63 sector alignment. In fact, the value that I provided was si= lently > rounded to the value that gpart thought was best for me. > Really, if a user says to gpart "do whatever alignment you want", then = I could > see using geometry-based values, but I still think that we should not d= o that > even in that case, I think we would be better off using some nice 2^N a= lignment. > If a user says "use this alignment or slice start", then the tool shoul= d just > shut up and do exactly what the user told it. There are several operations which can/should be changed: 1. MBR detection. All users want keep their partitions accessible. But with r221788 it is now problematic. I can revert r221788, but for me it seems right and instead reverting MBR support should be changed: a) table->gpt_last should not be aligned to track boundary; b) table->gpt_first can be aligned to track for compatibility, but if there is already some partition starts from inside first track, table->gpt_first should be set to 1. 2. MBR creating. a) table->gpt_last should not be aligned to track boundary; b) table->gpt_first can be aligned to track for compatibility. 3. Creating partitions. Users should choose alignment method, not the ker= nel. and they can do it: Align to 4k: # gpart add -t freebsd -a 4k -s 5g ada0 =09 Align according to disk geometry: # gpart add -t freebsd -g -s 5g ada0 So, patch is here: http://people.freebsd.org/~ae/mbr_geometry.diff Examples: # gpart create -s mbr md0 md0 created # gpart show md0 =3D> 63 4294967232 md0 MBR (5.5T) 63 4294967232 - free - (2T) # gpart add -t freebsd -s 10g -a 4k md0 md0s1 added # gpart show md0 =3D> 63 4294967232 md0 MBR (5.5T) 63 1 - free - (512B) 64 20971520 1 freebsd (10G) 20971584 4273995711 - free - (2T) # gpart add -t freebsd -s 10g -g md0 md0s2 added # gpart show md0 =3D> 63 4294967232 md0 MBR (5.5T) 63 1 - free - (512B) 64 20971520 1 freebsd (10G) 20971584 45 - free - (22k) 20971629 20971503 2 freebsd (10G) 41943132 4253024163 - free - (2T) --=20 WBR, Andrey V. Elsukov --------------enigF71682544821A7544380DDF5 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (MingW32) iQEcBAEBAgAGBQJN23S2AAoJEAHF6gQQyKF6rq0H/RRaCS8VMYqYX6kSlE/G921J PwmElExTTopQDbmf3zAQpT6W9ievyvTqSF0DmYmnthmYhbDWy9rbSBPxGsHUoofz hiTI6z/r1X+sLLHHi2awjICUnToUvlkaa2zQ4SN4x3mgUcyJ56wZsrakwitS8K7S OAX9Ra1Tz/Tp8PzN/eB2PV8bL8ohklKCMpdV/LddubKPv23nMUagxygJr8nVl+0g eUw+cy6ygyTEKuCnbx/E3IwtYeC++f5LyvNXXQm+1PGrqlfzMMKU7f/NJpzwDoX1 zDdoeI95xR8T6ycr7sJFrTcuFEr8r/wruI9oKPXOL5tq8am9dmP9RJFCqWcZAjs= =tJ5w -----END PGP SIGNATURE----- --------------enigF71682544821A7544380DDF5-- From owner-freebsd-geom@FreeBSD.ORG Tue May 24 09:23:03 2011 Return-Path: Delivered-To: freebsd-geom@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9105D10657D4 for ; Tue, 24 May 2011 09:23:03 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id D57408FC15 for ; Tue, 24 May 2011 09:23:02 +0000 (UTC) Received: from porto.topspin.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id MAA27953; Tue, 24 May 2011 12:22:48 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost.topspin.kiev.ua ([127.0.0.1]) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1QOnpA-0006iu-9n; Tue, 24 May 2011 12:22:48 +0300 Message-ID: <4DDB78E7.2070301@FreeBSD.org> Date: Tue, 24 May 2011 12:22:47 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.17) Gecko/20110503 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: "Andrey V. Elsukov" References: <4DDA2F0B.2040203@yandex.ru> <9ED563AB-7B35-40F4-A33E-015317858401@bsdimp.com> <4DDB5375.6050004@FreeBSD.org> <4DDB74B2.702@yandex.ru> In-Reply-To: <4DDB74B2.702@yandex.ru> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 7bit Cc: Marcel Moolenaar , Warner Losh , freebsd-geom@FreeBSD.org Subject: Re: [RFC] Remove requirement of alignment to track from MBR scheme X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 May 2011 09:23:03 -0000 on 24/05/2011 12:04 Andrey V. Elsukov said the following: > There are several operations which can/should be changed: > 1. MBR detection. All users want keep their partitions accessible. > But with r221788 it is now problematic. I can revert r221788, but for > me it seems right and instead reverting MBR support should be changed: > a) table->gpt_last should not be aligned to track boundary; > b) table->gpt_first can be aligned to track for compatibility, but > if there is already some partition starts from inside first > track, table->gpt_first should be set to 1. I think that we should completely ignore anything and everything CHS in our _validations_ (should not even warn). Words/notions "track", "cylinder", "head" should just disappear from source code. On other points - I agree with you. > 2. MBR creating. > a) table->gpt_last should not be aligned to track boundary; > b) table->gpt_first can be aligned to track for compatibility. > > 3. Creating partitions. Users should choose alignment method, not the kernel. > and they can do it: > Align to 4k: > # gpart add -t freebsd -a 4k -s 5g ada0 > > Align according to disk geometry: > # gpart add -t freebsd -g -s 5g ada0 > > So, patch is here: > http://people.freebsd.org/~ae/mbr_geometry.diff > > Examples: > > # gpart create -s mbr md0 > md0 created > # gpart show md0 > => 63 4294967232 md0 MBR (5.5T) > 63 4294967232 - free - (2T) > > # gpart add -t freebsd -s 10g -a 4k md0 > md0s1 added > # gpart show md0 > => 63 4294967232 md0 MBR (5.5T) > 63 1 - free - (512B) > 64 20971520 1 freebsd (10G) > 20971584 4273995711 - free - (2T) > > # gpart add -t freebsd -s 10g -g md0 > md0s2 added > # gpart show md0 > => 63 4294967232 md0 MBR (5.5T) > 63 1 - free - (512B) > 64 20971520 1 freebsd (10G) > 20971584 45 - free - (22k) > 20971629 20971503 2 freebsd (10G) > 41943132 4253024163 - free - (2T) > -- Andriy Gapon From owner-freebsd-geom@FreeBSD.ORG Tue May 24 16:35:07 2011 Return-Path: Delivered-To: freebsd-geom@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D064F106564A for ; Tue, 24 May 2011 16:35:07 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from asmtpout026.mac.com (asmtpout026.mac.com [17.148.16.101]) by mx1.freebsd.org (Postfix) with ESMTP id B0D148FC17 for ; Tue, 24 May 2011 16:35:07 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from sa-nc-common-178.static.jnpr.net (natint3.juniper.net [66.129.224.36]) by asmtp026.mac.com (Oracle Communications Messaging Exchange Server 7u4-20.01 64bit (built Nov 21 2010)) with ESMTPSA id <0LLP00MDPKQHV910@asmtp026.mac.com>; Tue, 24 May 2011 09:35:07 -0700 (PDT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.4.6813,1.0.148,0.0.0000 definitions=2011-05-24_05:2011-05-24, 2011-05-24, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=8 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=6.0.2-1012030000 definitions=main-1105240099 From: Marcel Moolenaar In-reply-to: <4DDB5375.6050004@FreeBSD.org> Date: Tue, 24 May 2011 09:35:10 -0700 Message-id: References: <4DDA2F0B.2040203@yandex.ru> <9ED563AB-7B35-40F4-A33E-015317858401@bsdimp.com> <4DDB5375.6050004@FreeBSD.org> To: Andriy Gapon X-Mailer: Apple Mail (2.1084) Cc: "Andrey V. Elsukov" , Warner Losh , freebsd-geom@FreeBSD.org Subject: Re: [RFC] Remove requirement of alignment to track from MBR scheme X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 May 2011 16:35:07 -0000 On May 23, 2011, at 11:43 PM, Andriy Gapon wrote: > on 23/05/2011 20:38 Warner Losh said the following: >> >> On May 23, 2011, at 10:35 AM, Marcel Moolenaar wrote: >>> I think we've had enough rushed and ill thought-out changes going >>> in already and I can see that not aligning MBR partitions on a track >>> boundary is potentially perceived as a PITA violation. > > _PITA_ violation? :-) > As to POLA - yeah, I can see people getting astonished that finally FreeBSD got > its sh*t together and did the right thing, years after all other OSes (even > Winddows) had done it. :-) Well, I just initialized a USB stick on my Mac and I see that it still adheres to some notion of geometry: : ugen3.2: at usbus3 umass0: on usbus3 da0 at umass-sim0 bus 0 scbus0 target 0 lun 0 da0: Removable Direct Access SCSI-2 device da0: 1.000MB/s transfers da0: 499MB (1023484 512 byte sectors: 64H 32S/T 499C) GEOM: da0s1: EBR has non empty bootcode. GEOM: msdosfs/MAC: EBR has non empty bootcode. marcelm-server% gpart show da0 => 32 1023424 da0 MBR (499M) 32 31 - free - (15k) 63 1023372 1 fat32 (499M) 1023435 21 - free - (10k) gpart synthesized a 64 head, 32 sectors/track geometry, which is not the same as the 63 sectors/track that Mac synthesized. Yes, this demonstrates the bogosity of geometry, but it also shows that it still exists. All I'm saying: be careful. -- Marcel Moolenaar xcllnt@mac.com From owner-freebsd-geom@FreeBSD.ORG Tue May 24 17:49:30 2011 Return-Path: Delivered-To: freebsd-geom@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4838F1065670; Tue, 24 May 2011 17:49:30 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id DAA5F8FC12; Tue, 24 May 2011 17:49:29 +0000 (UTC) Received: from [10.30.101.53] ([209.117.142.2]) (authenticated bits=0) by harmony.bsdimp.com (8.14.4/8.14.3) with ESMTP id p4OHkBmS017929 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES128-SHA bits=128 verify=NO); Tue, 24 May 2011 11:46:15 -0600 (MDT) (envelope-from imp@bsdimp.com) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: Date: Tue, 24 May 2011 11:46:06 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <2FCA1E3C-E11C-46C9-A41B-E5DF4D8BA1FC@bsdimp.com> References: <4DDA2F0B.2040203@yandex.ru> <9ED563AB-7B35-40F4-A33E-015317858401@bsdimp.com> <4DDB5375.6050004@FreeBSD.org> To: Marcel Moolenaar X-Mailer: Apple Mail (2.1084) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (harmony.bsdimp.com [10.0.0.6]); Tue, 24 May 2011 11:46:16 -0600 (MDT) Cc: "Andrey V. Elsukov" , Andriy Gapon , freebsd-geom@FreeBSD.org Subject: Re: [RFC] Remove requirement of alignment to track from MBR scheme X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 May 2011 17:49:30 -0000 On May 24, 2011, at 10:35 AM, Marcel Moolenaar wrote: >=20 > On May 23, 2011, at 11:43 PM, Andriy Gapon wrote: >=20 >> on 23/05/2011 20:38 Warner Losh said the following: >>>=20 >>> On May 23, 2011, at 10:35 AM, Marcel Moolenaar wrote: >>>> I think we've had enough rushed and ill thought-out changes going >>>> in already and I can see that not aligning MBR partitions on a = track >>>> boundary is potentially perceived as a PITA violation. >>=20 >> _PITA_ violation? :-) >> As to POLA - yeah, I can see people getting astonished that finally = FreeBSD got >> its sh*t together and did the right thing, years after all other OSes = (even >> Winddows) had done it. >=20 > :-) >=20 > Well, I just initialized a USB stick on my Mac and I see that it > still adheres to some notion of geometry: >=20 > : > ugen3.2: at usbus3 > umass0: on usbus3 > da0 at umass-sim0 bus 0 scbus0 target 0 lun 0 > da0: Removable Direct Access SCSI-2 device=20= > da0: 1.000MB/s transfers > da0: 499MB (1023484 512 byte sectors: 64H 32S/T 499C) > GEOM: da0s1: EBR has non empty bootcode. > GEOM: msdosfs/MAC: EBR has non empty bootcode. > marcelm-server% gpart show da0 > =3D> 32 1023424 da0 MBR (499M) > 32 31 - free - (15k) > 63 1023372 1 fat32 (499M) > 1023435 21 - free - (10k) does fdisk report the same thing? When I was poking, the 16GB stick I = have reported something similar to this via gpart show, but showed there = was nothing at the end when reported with fdisk. > gpart synthesized a 64 head, 32 sectors/track geometry, which > is not the same as the 63 sectors/track that Mac synthesized. > Yes, this demonstrates the bogosity of geometry, but it also > shows that it still exists. It still exists, but on the other hand it isn't *that* useful... > All I'm saying: be careful. Agreed. But the care should be on the creation side, not on the = interpretation side. In general, we should believe what the MBR says = and not do the kinds of rounding we do with creation. Also, I think = that we should allow non-aligned to fake geometry creations if the user = desires (or maybe even go so far as to make that the default and have = alignment forcing be a requested behavior). Warner > --=20 > Marcel Moolenaar > xcllnt@mac.com >=20 >=20 >=20 >=20 From owner-freebsd-geom@FreeBSD.ORG Tue May 24 18:12:30 2011 Return-Path: Delivered-To: freebsd-geom@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6D1C31065670; Tue, 24 May 2011 18:12:30 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from asmtpout028.mac.com (asmtpout028.mac.com [17.148.16.103]) by mx1.freebsd.org (Postfix) with ESMTP id 507028FC0A; Tue, 24 May 2011 18:12:30 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from sa-nc-common-178.static.jnpr.net (natint3.juniper.net [66.129.224.36]) by asmtp028.mac.com (Oracle Communications Messaging Exchange Server 7u4-20.01 64bit (built Nov 21 2010)) with ESMTPSA id <0LLP0043XP85FC60@asmtp028.mac.com>; Tue, 24 May 2011 11:12:07 -0700 (PDT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.4.6813,1.0.148,0.0.0000 definitions=2011-05-24_06:2011-05-24, 2011-05-24, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=2 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=6.0.2-1012030000 definitions=main-1105240114 From: Marcel Moolenaar In-reply-to: <2FCA1E3C-E11C-46C9-A41B-E5DF4D8BA1FC@bsdimp.com> Date: Tue, 24 May 2011 11:12:10 -0700 Message-id: <9B250685-62F2-4AF7-BDCC-D176FA3C6FCD@mac.com> References: <4DDA2F0B.2040203@yandex.ru> <9ED563AB-7B35-40F4-A33E-015317858401@bsdimp.com> <4DDB5375.6050004@FreeBSD.org> <2FCA1E3C-E11C-46C9-A41B-E5DF4D8BA1FC@bsdimp.com> To: Warner Losh X-Mailer: Apple Mail (2.1084) Cc: "Andrey V. Elsukov" , Andriy Gapon , freebsd-geom@FreeBSD.org Subject: Re: [RFC] Remove requirement of alignment to track from MBR scheme X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 May 2011 18:12:30 -0000 On May 24, 2011, at 10:46 AM, Warner Losh wrote: >> All I'm saying: be careful. > > Agreed. But the care should be on the creation side, not on the interpretation side. ... as the original code was. We just need to add a sanity check to the interpretation that filters out the real bogus information (resulting in a partition with negative size). With respect to the creation: Since out synthesized geometry is not necessarily the same as other OSes, we could opt to synthesize a geometry that has a track size (= sectors/track) that is a multiple of 8 (to play nice with 4K sectors), and/or take the stripe size of the underlying GEOM into account. This fundamentally doesn't change a thing for MBR, but has the side effect of achieving some of the goals *and* automatically works for EBR as well. Thus: rather than hack MBR and forgetting about EBR and other schemes, maybe we only have to tweak the geometry synthesis to give people what they want without going over board. After 9.0 branched, we can do a lot more knowing we have plenty of soak time... -- Marcel Moolenaar xcllnt@mac.com From owner-freebsd-geom@FreeBSD.ORG Tue May 24 19:18:56 2011 Return-Path: Delivered-To: freebsd-geom@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CA196106564A; Tue, 24 May 2011 19:18:56 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from forward1.mail.yandex.net (forward1.mail.yandex.net [77.88.46.6]) by mx1.freebsd.org (Postfix) with ESMTP id 479988FC14; Tue, 24 May 2011 19:18:56 +0000 (UTC) Received: from smtp1.mail.yandex.net (smtp1.mail.yandex.net [77.88.46.101]) by forward1.mail.yandex.net (Yandex) with ESMTP id 812F31243612; Tue, 24 May 2011 23:18:54 +0400 (MSD) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1306264734; bh=8PBZ/9Sp51n/4enz6wkyG+gleRtkw1hN3F/XK3We2n0=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type; b=mvFKX7FBYbOEWOXDt+nWGyQ0vKTKtPYj1hQ1Lf5YGXcDbJRnGNPVRbIu761/LWeVE Uem44PduMX8URFO1yp/FkxkjrJyAxF6t/W+yIffGHnkNeK1ZjppK2M5cKrB7I4/S1H V7nsoMUE8wX62crEit8ebUIaMwVMVbkXvnEnGPmc= Received: from [178.141.127.176] (dynamic-178-141-127-176.kirov.comstar-r.ru [178.141.127.176]) by smtp1.mail.yandex.net (Yandex) with ESMTPSA id 19D3810000A7; Tue, 24 May 2011 23:18:54 +0400 (MSD) Message-ID: <4DDC049C.7070904@yandex.ru> Date: Tue, 24 May 2011 23:18:52 +0400 From: "Andrey V. Elsukov" User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.17) Gecko/20110429 Thunderbird/3.1.10 MIME-Version: 1.0 To: Marcel Moolenaar References: <4DDA2F0B.2040203@yandex.ru> <9ED563AB-7B35-40F4-A33E-015317858401@bsdimp.com> <4DDB5375.6050004@FreeBSD.org> <2FCA1E3C-E11C-46C9-A41B-E5DF4D8BA1FC@bsdimp.com> <9B250685-62F2-4AF7-BDCC-D176FA3C6FCD@mac.com> In-Reply-To: <9B250685-62F2-4AF7-BDCC-D176FA3C6FCD@mac.com> X-Enigmail-Version: 1.1.2 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig38DEF71BC7F6700B4C8B7EAD" X-Yandex-Spam: 1 Cc: Andriy Gapon , Warner Losh , freebsd-geom@FreeBSD.org Subject: Re: [RFC] Remove requirement of alignment to track from MBR scheme X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 May 2011 19:18:57 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig38DEF71BC7F6700B4C8B7EAD Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: quoted-printable On 24.05.2011 22:12, Marcel Moolenaar wrote: >=20 > On May 24, 2011, at 10:46 AM, Warner Losh wrote: >>> All I'm saying: be careful. >> >> Agreed. But the care should be on the creation side, not on the inter= pretation side. >=20 > ... as the original code was. We just need to add a sanity > check to the interpretation that filters out the real bogus > information (resulting in a partition with negative size). A partition with negative size is not the one problem. Some time ago i found an easy reproducible bug, when BSD scheme creates providers with size bigger than parent provider size. Also there was nothing against creation of overlapped partitions. > With respect to the creation: >=20 > Since out synthesized geometry is not necessarily the same > as other OSes, we could opt to synthesize a geometry that > has a track size (=3D sectors/track) that is a multiple of 8 > (to play nice with 4K sectors), and/or take the stripe > size of the underlying GEOM into account. This fundamentally > doesn't change a thing for MBR, but has the side effect of > achieving some of the goals *and* automatically works for > EBR as well. Today's devices do not report about their 4k sectors. > Thus: rather than hack MBR and forgetting about EBR and other I do not forget about EBR, PC98 and VTOC8. But we need begin from somethi= ng. > schemes, maybe we only have to tweak the geometry synthesis > to give people what they want without going over board. After > 9.0 branched, we can do a lot more knowing we have plenty > of soak time... Ok, i can revert all related changes and just do nothing :) It seems it is better solution :) --=20 WBR, Andrey V. Elsukov --------------enig38DEF71BC7F6700B4C8B7EAD Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (FreeBSD) iQEcBAEBAgAGBQJN3AScAAoJEAHF6gQQyKF6/kAH+QEWQhxGphQstogOG9UuwJb8 nlhH7njEyGNpxGFKP3a+uP09IF0Ja6EYOoHV8rz8VZFN1/q5jln/xveZNjtb+7Hl xd4EiWfMc/F/3XlfZvMKa56mXm/0rIfju2tBCH42ViTs1Dizds8cBxRkxy26Unb1 7g2boPZcRc1B8/t0t2VTfwi7I9ZMR9VxXR77GjOa6gKnk33BD3H/FXj8Bux9QQ2r 903NliODwsen0mYsfXcTh81G2zSjclRtKmREfmg4IvZwWU/GCvoRZ473CsDT3B5V lRAJN6UuYZJtw1cAwadxQRQIlrCh+eHbH+JBFTiBMe+8Cobl22Bb0MmSSN+jaig= =PZ5t -----END PGP SIGNATURE----- --------------enig38DEF71BC7F6700B4C8B7EAD-- From owner-freebsd-geom@FreeBSD.ORG Wed May 25 15:12:33 2011 Return-Path: Delivered-To: freebsd-geom@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CC917106564A for ; Wed, 25 May 2011 15:12:33 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 233FD8FC14 for ; Wed, 25 May 2011 15:12:32 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id SAA29987; Wed, 25 May 2011 18:12:22 +0300 (EEST) (envelope-from avg@FreeBSD.org) Message-ID: <4DDD1C56.70706@FreeBSD.org> Date: Wed, 25 May 2011 18:12:22 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.17) Gecko/20110504 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: Marcel Moolenaar References: <4DDA2F0B.2040203@yandex.ru> <9ED563AB-7B35-40F4-A33E-015317858401@bsdimp.com> <4DDB5375.6050004@FreeBSD.org> <2FCA1E3C-E11C-46C9-A41B-E5DF4D8BA1FC@bsdimp.com> <9B250685-62F2-4AF7-BDCC-D176FA3C6FCD@mac.com> In-Reply-To: <9B250685-62F2-4AF7-BDCC-D176FA3C6FCD@mac.com> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: "Andrey V. Elsukov" , Warner Losh , freebsd-geom@FreeBSD.org Subject: Re: [RFC] Remove requirement of alignment to track from MBR scheme X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2011 15:12:33 -0000 on 24/05/2011 21:12 Marcel Moolenaar said the following: > With respect to the creation: > > Since out synthesized geometry is not necessarily the same > as other OSes, we could opt to synthesize a geometry that > has a track size (= sectors/track) that is a multiple of 8 > (to play nice with 4K sectors), and/or take the stripe > size of the underlying GEOM into account. This fundamentally > doesn't change a thing for MBR, but has the side effect of > achieving some of the goals *and* automatically works for > EBR as well. > > Thus: rather than hack MBR and forgetting about EBR and other > schemes, maybe we only have to tweak the geometry synthesis > to give people what they want without going over board. I don't think that currently we do synthesize any geometry in kernel. I think that we just whatever BIOS/firmware/etc provides to us in some way. > After > 9.0 branched, we can do a lot more knowing we have plenty > of soak time... I agree in general, but there is one thing I want now/ASAP - ability to use gpart to create (valid) partitions the way I like it disregarding whatever fake geometry there might be. I hate when tools go EDAVE on me. -- Andriy Gapon From owner-freebsd-geom@FreeBSD.ORG Wed May 25 15:14:13 2011 Return-Path: Delivered-To: freebsd-geom@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1079B1065670; Wed, 25 May 2011 15:14:13 +0000 (UTC) (envelope-from bruce@cran.org.uk) Received: from muon.cran.org.uk (muon.cran.org.uk [IPv6:2a01:348:0:15:5d59:5c40:0:1]) by mx1.freebsd.org (Postfix) with ESMTP id 8F6788FC19; Wed, 25 May 2011 15:14:12 +0000 (UTC) Received: from muon.cran.org.uk (localhost [127.0.0.1]) by muon.cran.org.uk (Postfix) with ESMTP id 5F6B6E62F9; Wed, 25 May 2011 16:14:11 +0100 (BST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cran.org.uk; h=date:from :to:cc:subject:message-id:in-reply-to:references:mime-version :content-type:content-transfer-encoding; s=mail; bh=F++J71TCV7XZ nRwgSqvGQ7CiXt4=; b=uVdp4hz9SC/WJnDRx4Y0egVGUBTp2osTzZEe4ptKSOuA Su50nvsM7+iusJsjJagJT/n+L/PVPSWBUgQHe3bwhGV4Xb07e3WNfnirftlKuyIA C3uTGjMilMVmrLQptUilxwvt0uokzoAQ1gT0JzHJFXYr2xIFjn9vWkBdT8ToAJs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=cran.org.uk; h=date:from:to :cc:subject:message-id:in-reply-to:references:mime-version :content-type:content-transfer-encoding; q=dns; s=mail; b=oGOv/l mCGzLZ8u4+TK9utnpLuj45oI1w+yiuZYLR2M+7keklxHJRGTXyNCEnVjLNkZlOTz Q1Lqzo/OR1gfqt/Ul/twZZQ729XZBiYTsEeRH0kLHaw6ayAywumlYlvY2hoZgJPV SaqbevPL3wsAT0iir6lNMiA/5aWEefF6f/qgw= Received: from unknown (188-222-18-231.zone13.bethere.co.uk [188.222.18.231]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by muon.cran.org.uk (Postfix) with ESMTPSA id 03E5EE62F8; Wed, 25 May 2011 16:14:10 +0100 (BST) Date: Wed, 25 May 2011 16:14:09 +0100 From: Bruce Cran To: Andriy Gapon Message-ID: <20110525161409.00001c2a@unknown> In-Reply-To: <4DDD1C56.70706@FreeBSD.org> References: <4DDA2F0B.2040203@yandex.ru> <9ED563AB-7B35-40F4-A33E-015317858401@bsdimp.com> <4DDB5375.6050004@FreeBSD.org> <2FCA1E3C-E11C-46C9-A41B-E5DF4D8BA1FC@bsdimp.com> <9B250685-62F2-4AF7-BDCC-D176FA3C6FCD@mac.com> <4DDD1C56.70706@FreeBSD.org> X-Mailer: Claws Mail 3.7.8cvs47 (GTK+ 2.16.6; i586-pc-mingw32msvc) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: Marcel Moolenaar , freebsd-geom@FreeBSD.org, Warner Losh , "Andrey V. Elsukov" Subject: Re: [RFC] Remove requirement of alignment to track from MBR scheme X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2011 15:14:13 -0000 On Wed, 25 May 2011 18:12:22 +0300 Andriy Gapon wrote: > I don't think that currently we do synthesize any geometry in kernel. > I think that we just whatever BIOS/firmware/etc provides to us in > some way. I'm fairly sure we generate our own geometry for CAM drivers. -- Bruce From owner-freebsd-geom@FreeBSD.ORG Wed May 25 15:22:54 2011 Return-Path: Delivered-To: freebsd-geom@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7215A1065675 for ; Wed, 25 May 2011 15:22:54 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id A047C8FC22 for ; Wed, 25 May 2011 15:22:53 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id SAA00236; Wed, 25 May 2011 18:22:42 +0300 (EEST) (envelope-from avg@FreeBSD.org) Message-ID: <4DDD1EC2.7090405@FreeBSD.org> Date: Wed, 25 May 2011 18:22:42 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.17) Gecko/20110504 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: "Andrey V. Elsukov" References: <4DDA2F0B.2040203@yandex.ru> <9ED563AB-7B35-40F4-A33E-015317858401@bsdimp.com> <4DDB5375.6050004@FreeBSD.org> <2FCA1E3C-E11C-46C9-A41B-E5DF4D8BA1FC@bsdimp.com> <9B250685-62F2-4AF7-BDCC-D176FA3C6FCD@mac.com> <4DDC049C.7070904@yandex.ru> In-Reply-To: <4DDC049C.7070904@yandex.ru> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: Marcel Moolenaar , Warner Losh , freebsd-geom@FreeBSD.org Subject: Re: [RFC] Remove requirement of alignment to track from MBR scheme X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2011 15:22:54 -0000 on 24/05/2011 22:18 Andrey V. Elsukov said the following: > On 24.05.2011 22:12, Marcel Moolenaar wrote: >> >> On May 24, 2011, at 10:46 AM, Warner Losh wrote: >>>> All I'm saying: be careful. >>> >>> Agreed. But the care should be on the creation side, not on the interpretation side. >> >> ... as the original code was. We just need to add a sanity >> check to the interpretation that filters out the real bogus >> information (resulting in a partition with negative size). > > A partition with negative size is not the one problem. > Some time ago i found an easy reproducible bug, when BSD scheme > creates providers with size bigger than parent provider size. > Also there was nothing against creation of overlapped partitions. All the good points, IMO. >> With respect to the creation: >> >> Since out synthesized geometry is not necessarily the same >> as other OSes, we could opt to synthesize a geometry that >> has a track size (= sectors/track) that is a multiple of 8 >> (to play nice with 4K sectors), and/or take the stripe >> size of the underlying GEOM into account. This fundamentally >> doesn't change a thing for MBR, but has the side effect of >> achieving some of the goals *and* automatically works for >> EBR as well. > > Today's devices do not report about their 4k sectors. > >> Thus: rather than hack MBR and forgetting about EBR and other > > I do not forget about EBR, PC98 and VTOC8. But we need begin from something. > >> schemes, maybe we only have to tweak the geometry synthesis >> to give people what they want without going over board. After >> 9.0 branched, we can do a lot more knowing we have plenty >> of soak time... > > Ok, i can revert all related changes and just do nothing :) > It seems it is better solution :) I hope that you won't take the easy road and won't give up. It's easy to say "don't change things", but sometimes reality presses hard for a change and there should be someone brave to make it. I think that we are starting to reach some consensus here. Let me try to summarize and check if this is what we indeed can agree upon. For media tasting/validation: 1. Keep all the non-CHS LBA-based checks - too large partitions, overlapping partitions, etc. Perhaps add even more. And, of course, with proper diagnostics. 2. Ditch all the checks based on or involving CHS parameters. For media creation, short term: 1. By default be compatible with present behavior. 2. Provide a way for a user to disable all CHS-based validations/adjustments of input parameters. 3. Keep all non-CHS validations and sanity checks, of course. Long term (post-9 ?): 1. Change defaults to play nicer with modern disks Longer term: 1. Possibly remove any CHS reference from all the code, kernel and userland; invent better heuristic values for things like partitioning, UFS newfs, etc. -- Andriy Gapon From owner-freebsd-geom@FreeBSD.ORG Wed May 25 15:24:49 2011 Return-Path: Delivered-To: freebsd-geom@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4CA311065675; Wed, 25 May 2011 15:24:49 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from asmtpout024.mac.com (asmtpout024.mac.com [17.148.16.99]) by mx1.freebsd.org (Postfix) with ESMTP id 2EC348FC12; Wed, 25 May 2011 15:24:48 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from sa-nc-common-178.static.jnpr.net (natint3.juniper.net [66.129.224.36]) by asmtp024.mac.com (Oracle Communications Messaging Exchange Server 7u4-18.01 64bit (built Jul 15 2010)) with ESMTPSA id <0LLR000ATC557C90@asmtp024.mac.com>; Wed, 25 May 2011 08:24:42 -0700 (PDT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.4.6813,1.0.148,0.0.0000 definitions=2011-05-25_07:2011-05-25, 2011-05-25, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=2 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=6.0.2-1012030000 definitions=main-1105250081 From: Marcel Moolenaar In-reply-to: <4DDD1C56.70706@FreeBSD.org> Date: Wed, 25 May 2011 08:24:40 -0700 Message-id: References: <4DDA2F0B.2040203@yandex.ru> <9ED563AB-7B35-40F4-A33E-015317858401@bsdimp.com> <4DDB5375.6050004@FreeBSD.org> <2FCA1E3C-E11C-46C9-A41B-E5DF4D8BA1FC@bsdimp.com> <9B250685-62F2-4AF7-BDCC-D176FA3C6FCD@mac.com> <4DDD1C56.70706@FreeBSD.org> To: Andriy Gapon X-Mailer: Apple Mail (2.1084) Cc: "Andrey V. Elsukov" , Warner Losh , freebsd-geom@FreeBSD.org Subject: Re: [RFC] Remove requirement of alignment to track from MBR scheme X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2011 15:24:49 -0000 On May 25, 2011, at 8:12 AM, Andriy Gapon wrote: > on 24/05/2011 21:12 Marcel Moolenaar said the following: >> With respect to the creation: >> >> Since out synthesized geometry is not necessarily the same >> as other OSes, we could opt to synthesize a geometry that >> has a track size (= sectors/track) that is a multiple of 8 >> (to play nice with 4K sectors), and/or take the stripe >> size of the underlying GEOM into account. This fundamentally >> doesn't change a thing for MBR, but has the side effect of >> achieving some of the goals *and* automatically works for >> EBR as well. >> >> Thus: rather than hack MBR and forgetting about EBR and other >> schemes, maybe we only have to tweak the geometry synthesis >> to give people what they want without going over board. > > I don't think that currently we do synthesize any geometry in kernel. > I think that we just whatever BIOS/firmware/etc provides to us in some way. Yes, we do. gpart makes sure that there's always a geometry and it adjusts the geometry based on information obtained from schemes. The geometry given by geom_disk (= ad or da) is typically the starting point. md does not have geometry information, causing certain tools to work less well. -- Marcel Moolenaar xcllnt@mac.com From owner-freebsd-geom@FreeBSD.ORG Wed May 25 15:29:27 2011 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B0AD21065670 for ; Wed, 25 May 2011 15:29:27 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id 6B6158FC19 for ; Wed, 25 May 2011 15:29:27 +0000 (UTC) Received: from critter.freebsd.dk (critter.freebsd.dk [192.168.61.3]) by phk.freebsd.dk (Postfix) with ESMTP id 002D45E3B; Wed, 25 May 2011 15:29:25 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.4/8.14.4) with ESMTP id p4PFTOHX027156; Wed, 25 May 2011 15:29:24 GMT (envelope-from phk@critter.freebsd.dk) To: Marcel Moolenaar From: "Poul-Henning Kamp" In-Reply-To: Your message of "Wed, 25 May 2011 08:24:40 MST." Content-Type: text/plain; charset=ISO-8859-1 Date: Wed, 25 May 2011 15:29:24 +0000 Message-ID: <27155.1306337364@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: "Andrey V. Elsukov" , Warner Losh , Andriy Gapon , freebsd-geom@freebsd.org Subject: Re: [RFC] Remove requirement of alignment to track from MBR scheme X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2011 15:29:27 -0000 In message , Marcel Moolenaar wri tes: >md does not have geometry >information, causing certain tools to work less well. SYNOPSIS mdconfig -a -t type [-n] [-o [no]option] ... [-f file] [-s size] [-S sectorsize] [-u unit] [-x sectors/track] [-y heads/cylinder] ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-geom@FreeBSD.ORG Wed May 25 15:37:48 2011 Return-Path: Delivered-To: freebsd-geom@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B3D22106566C for ; Wed, 25 May 2011 15:37:48 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 07B598FC0C for ; Wed, 25 May 2011 15:37:47 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id SAA00486; Wed, 25 May 2011 18:37:33 +0300 (EEST) (envelope-from avg@FreeBSD.org) Message-ID: <4DDD223D.9050407@FreeBSD.org> Date: Wed, 25 May 2011 18:37:33 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.17) Gecko/20110504 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: Marcel Moolenaar References: <4DDA2F0B.2040203@yandex.ru> <9ED563AB-7B35-40F4-A33E-015317858401@bsdimp.com> <4DDB5375.6050004@FreeBSD.org> <2FCA1E3C-E11C-46C9-A41B-E5DF4D8BA1FC@bsdimp.com> <9B250685-62F2-4AF7-BDCC-D176FA3C6FCD@mac.com> <4DDD1C56.70706@FreeBSD.org> In-Reply-To: X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: "Andrey V. Elsukov" , Warner Losh , freebsd-geom@FreeBSD.org Subject: Re: [RFC] Remove requirement of alignment to track from MBR scheme X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2011 15:37:48 -0000 on 25/05/2011 18:24 Marcel Moolenaar said the following: > > On May 25, 2011, at 8:12 AM, Andriy Gapon wrote: > >> on 24/05/2011 21:12 Marcel Moolenaar said the following: >>> With respect to the creation: >>> >>> Since out synthesized geometry is not necessarily the same >>> as other OSes, we could opt to synthesize a geometry that >>> has a track size (= sectors/track) that is a multiple of 8 >>> (to play nice with 4K sectors), and/or take the stripe >>> size of the underlying GEOM into account. This fundamentally >>> doesn't change a thing for MBR, but has the side effect of >>> achieving some of the goals *and* automatically works for >>> EBR as well. >>> >>> Thus: rather than hack MBR and forgetting about EBR and other >>> schemes, maybe we only have to tweak the geometry synthesis >>> to give people what they want without going over board. >> >> I don't think that currently we do synthesize any geometry in kernel. >> I think that we just whatever BIOS/firmware/etc provides to us in some way. > > Yes, we do. gpart makes sure that there's always a geometry > and it adjusts the geometry based on information obtained > from schemes. The geometry given by geom_disk (= ad or da) > is typically the starting point. md does not have geometry > information, causing certain tools to work less well. OK. I just haven't payed attention to that, sorry. -- Andriy Gapon From owner-freebsd-geom@FreeBSD.ORG Wed May 25 17:36:28 2011 Return-Path: Delivered-To: freebsd-geom@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7EFDF1065670; Wed, 25 May 2011 17:36:28 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 2B86B8FC08; Wed, 25 May 2011 17:36:28 +0000 (UTC) Received: from [10.30.101.53] ([209.117.142.2]) (authenticated bits=0) by harmony.bsdimp.com (8.14.4/8.14.3) with ESMTP id p4PHVlb3031573 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES128-SHA bits=128 verify=NO); Wed, 25 May 2011 11:31:49 -0600 (MDT) (envelope-from imp@bsdimp.com) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <4DDD1EC2.7090405@FreeBSD.org> Date: Wed, 25 May 2011 11:31:41 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <0EFCF6E2-9150-4756-8DE1-5EE70EC22C8D@bsdimp.com> References: <4DDA2F0B.2040203@yandex.ru> <9ED563AB-7B35-40F4-A33E-015317858401@bsdimp.com> <4DDB5375.6050004@FreeBSD.org> <2FCA1E3C-E11C-46C9-A41B-E5DF4D8BA1FC@bsdimp.com> <9B250685-62F2-4AF7-BDCC-D176FA3C6FCD@mac.com> <4DDC049C.7070904@yandex.ru> <4DDD1EC2.7090405@FreeBSD.org> To: Andriy Gapon X-Mailer: Apple Mail (2.1084) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (harmony.bsdimp.com [10.0.0.6]); Wed, 25 May 2011 11:31:50 -0600 (MDT) Cc: "Andrey V. Elsukov" , Marcel Moolenaar , freebsd-geom@FreeBSD.org Subject: Re: [RFC] Remove requirement of alignment to track from MBR scheme X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2011 17:36:28 -0000 On May 25, 2011, at 9:22 AM, Andriy Gapon wrote: > on 24/05/2011 22:18 Andrey V. Elsukov said the following: >> On 24.05.2011 22:12, Marcel Moolenaar wrote: >>>=20 >>> On May 24, 2011, at 10:46 AM, Warner Losh wrote: >>>>> All I'm saying: be careful. >>>>=20 >>>> Agreed. But the care should be on the creation side, not on the = interpretation side. >>>=20 >>> ... as the original code was. We just need to add a sanity >>> check to the interpretation that filters out the real bogus >>> information (resulting in a partition with negative size). >>=20 >> A partition with negative size is not the one problem. >> Some time ago i found an easy reproducible bug, when BSD scheme >> creates providers with size bigger than parent provider size. >> Also there was nothing against creation of overlapped partitions. >=20 > All the good points, IMO. >=20 >>> With respect to the creation: >>>=20 >>> Since out synthesized geometry is not necessarily the same >>> as other OSes, we could opt to synthesize a geometry that >>> has a track size (=3D sectors/track) that is a multiple of 8 >>> (to play nice with 4K sectors), and/or take the stripe >>> size of the underlying GEOM into account. This fundamentally >>> doesn't change a thing for MBR, but has the side effect of >>> achieving some of the goals *and* automatically works for >>> EBR as well. >>=20 >> Today's devices do not report about their 4k sectors. >>=20 >>> Thus: rather than hack MBR and forgetting about EBR and other >>=20 >> I do not forget about EBR, PC98 and VTOC8. But we need begin from = something. >>=20 >>> schemes, maybe we only have to tweak the geometry synthesis >>> to give people what they want without going over board. After >>> 9.0 branched, we can do a lot more knowing we have plenty >>> of soak time... >>=20 >> Ok, i can revert all related changes and just do nothing :) >> It seems it is better solution :) >=20 > I hope that you won't take the easy road and won't give up. > It's easy to say "don't change things", but sometimes reality presses = hard for a > change and there should be someone brave to make it. >=20 > I think that we are starting to reach some consensus here. > Let me try to summarize and check if this is what we indeed can agree = upon. >=20 > For media tasting/validation: > 1. Keep all the non-CHS LBA-based checks - too large partitions, = overlapping > partitions, etc. Perhaps add even more. And, of course, with proper = diagnostics. > 2. Ditch all the checks based on or involving CHS parameters. 3. Stop rounding to the nearest track when READING MBR. It is totally = bogus, never necessary and no documentation of the MBR has been produced = suggesting that you need to do this. If you don't think it is valid, = don't use it, but don't silently adjust it by a random amount leading to = hard to track down bugs. > For media creation, short term: > 1. By default be compatible with present behavior. > 2. Provide a way for a user to disable all CHS-based = validations/adjustments of > input parameters. Do not adjust based on CHS at all. The adjustments are almost always = bogus. In fact, I can't think of a time when the MBR ending track = should be adjusted when reading it from disk. Can you provide = justification for doing this that's backed up by some source that says = "the MBR values are adjusted like ..." rather than "MBR values are = aligned" I've yet to find one that says this adjustment is anything = but totally bogus on the read it from disk path. > 3. Keep all non-CHS validations and sanity checks, of course. >=20 > Long term (post-9 ?): > 1. Change defaults to play nicer with modern disks >=20 > Longer term: > 1. Possibly remove any CHS reference from all the code, kernel and = userland; > invent better heuristic values for things like partitioning, UFS = newfs, etc. You can't do that. CHS are still needed for sunlabel and pc98 support. Warner= From owner-freebsd-geom@FreeBSD.ORG Wed May 25 17:43:33 2011 Return-Path: Delivered-To: freebsd-geom@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 883A41065670; Wed, 25 May 2011 17:43:33 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 24C758FC14; Wed, 25 May 2011 17:43:33 +0000 (UTC) Received: from [10.30.101.53] ([209.117.142.2]) (authenticated bits=0) by harmony.bsdimp.com (8.14.4/8.14.3) with ESMTP id p4PHb8xJ031643 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES128-SHA bits=128 verify=NO); Wed, 25 May 2011 11:37:11 -0600 (MDT) (envelope-from imp@bsdimp.com) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <4DDD1C56.70706@FreeBSD.org> Date: Wed, 25 May 2011 11:37:03 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <73D4228C-58DF-4A73-A562-34AA4BBF08C4@bsdimp.com> References: <4DDA2F0B.2040203@yandex.ru> <9ED563AB-7B35-40F4-A33E-015317858401@bsdimp.com> <4DDB5375.6050004@FreeBSD.org> <2FCA1E3C-E11C-46C9-A41B-E5DF4D8BA1FC@bsdimp.com> <9B250685-62F2-4AF7-BDCC-D176FA3C6FCD@mac.com> <4DDD1C56.70706@FreeBSD.org> To: Andriy Gapon X-Mailer: Apple Mail (2.1084) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (harmony.bsdimp.com [10.0.0.6]); Wed, 25 May 2011 11:37:12 -0600 (MDT) Cc: Marcel Moolenaar , freebsd-geom@FreeBSD.org, "Andrey V. Elsukov" Subject: Re: [RFC] Remove requirement of alignment to track from MBR scheme X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2011 17:43:33 -0000 On May 25, 2011, at 9:12 AM, Andriy Gapon wrote: > on 24/05/2011 21:12 Marcel Moolenaar said the following: >> With respect to the creation: >>=20 >> Since out synthesized geometry is not necessarily the same >> as other OSes, we could opt to synthesize a geometry that >> has a track size (=3D sectors/track) that is a multiple of 8 >> (to play nice with 4K sectors), and/or take the stripe >> size of the underlying GEOM into account. This fundamentally >> doesn't change a thing for MBR, but has the side effect of >> achieving some of the goals *and* automatically works for >> EBR as well. >>=20 >> Thus: rather than hack MBR and forgetting about EBR and other >> schemes, maybe we only have to tweak the geometry synthesis >> to give people what they want without going over board.=20 >=20 > I don't think that currently we do synthesize any geometry in kernel. We do. There's at least three cases I can think of. For CAM da = devices, we always synthesize something bogus. For ata devices on pc98 = machines, we create the right fake geometry when certain conditions = require us to create a fake geometry. CAM on pc98 machines also does = this. The disk drives themselves are creating fake geometry and passing it up. > I think that we just whatever BIOS/firmware/etc provides to us in some = way. For MBR and devices > 8GB, this should be ignored, since the fields = saturate (except ones created with our fdisk/sysinstall programs: then = they just size & 0x3ff the values for cylinders rather than the proper = 1023 saturation). >> After >> 9.0 branched, we can do a lot more knowing we have plenty >> of soak time... >=20 > I agree in general, but there is one thing I want now/ASAP - ability = to use gpart > to create (valid) partitions the way I like it disregarding whatever = fake geometry > there might be. I hate when tools go EDAVE on me. At this stage of the game, the boundary checks should be relaxed and = opt-in. We likely should just create MBR slices starting at 64 always, = unless someone has specifically requested that we align things, or asks = for a different starting place. Warner= From owner-freebsd-geom@FreeBSD.ORG Wed May 25 18:03:08 2011 Return-Path: Delivered-To: freebsd-geom@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 68BCB1065673 for ; Wed, 25 May 2011 18:03:08 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id C21068FC0A for ; Wed, 25 May 2011 18:03:07 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id VAA02999; Wed, 25 May 2011 21:02:54 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1QPIQ2-000AeK-If; Wed, 25 May 2011 21:02:54 +0300 Message-ID: <4DDD444D.6020205@FreeBSD.org> Date: Wed, 25 May 2011 21:02:53 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.17) Gecko/20110503 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: Warner Losh References: <4DDA2F0B.2040203@yandex.ru> <9ED563AB-7B35-40F4-A33E-015317858401@bsdimp.com> <4DDB5375.6050004@FreeBSD.org> <2FCA1E3C-E11C-46C9-A41B-E5DF4D8BA1FC@bsdimp.com> <9B250685-62F2-4AF7-BDCC-D176FA3C6FCD@mac.com> <4DDC049C.7070904@yandex.ru> <4DDD1EC2.7090405@FreeBSD.org> <0EFCF6E2-9150-4756-8DE1-5EE70EC22C8D@bsdimp.com> In-Reply-To: <0EFCF6E2-9150-4756-8DE1-5EE70EC22C8D@bsdimp.com> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "Andrey V. Elsukov" , Marcel Moolenaar , freebsd-geom@FreeBSD.org Subject: Re: [RFC] Remove requirement of alignment to track from MBR scheme X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2011 18:03:08 -0000 on 25/05/2011 20:31 Warner Losh said the following: > > On May 25, 2011, at 9:22 AM, Andriy Gapon wrote: > >> on 24/05/2011 22:18 Andrey V. Elsukov said the following: >>> On 24.05.2011 22:12, Marcel Moolenaar wrote: >>>> >>>> On May 24, 2011, at 10:46 AM, Warner Losh wrote: >>>>>> All I'm saying: be careful. >>>>> >>>>> Agreed. But the care should be on the creation side, not on the >>>>> interpretation side. >>>> >>>> ... as the original code was. We just need to add a sanity check to the >>>> interpretation that filters out the real bogus information (resulting >>>> in a partition with negative size). >>> >>> A partition with negative size is not the one problem. Some time ago i >>> found an easy reproducible bug, when BSD scheme creates providers with >>> size bigger than parent provider size. Also there was nothing against >>> creation of overlapped partitions. >> >> All the good points, IMO. >> >>>> With respect to the creation: >>>> >>>> Since out synthesized geometry is not necessarily the same as other >>>> OSes, we could opt to synthesize a geometry that has a track size (= >>>> sectors/track) that is a multiple of 8 (to play nice with 4K sectors), >>>> and/or take the stripe size of the underlying GEOM into account. This >>>> fundamentally doesn't change a thing for MBR, but has the side effect >>>> of achieving some of the goals *and* automatically works for EBR as >>>> well. >>> >>> Today's devices do not report about their 4k sectors. >>> >>>> Thus: rather than hack MBR and forgetting about EBR and other >>> >>> I do not forget about EBR, PC98 and VTOC8. But we need begin from >>> something. >>> >>>> schemes, maybe we only have to tweak the geometry synthesis to give >>>> people what they want without going over board. After 9.0 branched, we >>>> can do a lot more knowing we have plenty of soak time... >>> >>> Ok, i can revert all related changes and just do nothing :) It seems it >>> is better solution :) >> >> I hope that you won't take the easy road and won't give up. It's easy to >> say "don't change things", but sometimes reality presses hard for a change >> and there should be someone brave to make it. >> >> I think that we are starting to reach some consensus here. Let me try to >> summarize and check if this is what we indeed can agree upon. >> >> For media tasting/validation: 1. Keep all the non-CHS LBA-based checks - >> too large partitions, overlapping partitions, etc. Perhaps add even more. >> And, of course, with proper diagnostics. 2. Ditch all the checks based on >> or involving CHS parameters. > > 3. Stop rounding to the nearest track when READING MBR. It is totally bogus, > never necessary and no documentation of the MBR has been produced suggesting > that you need to do this. If you don't think it is valid, don't use it, but > don't silently adjust it by a random amount leading to hard to track down > bugs. Your 3 should be a sub-case of my 2 as it involves CHS parameters. >> For media creation, short term: 1. By default be compatible with present >> behavior. 2. Provide a way for a user to disable all CHS-based >> validations/adjustments of input parameters. > > Do not adjust based on CHS at all. The adjustments are almost always bogus. > In fact, I can't think of a time when the MBR ending track should be adjusted > when reading it from disk. Can you provide justification for doing this > that's backed up by some source that says "the MBR values are adjusted like > ..." rather than "MBR values are aligned" I've yet to find one that says > this adjustment is anything but totally bogus on the read it from disk path. I would agree with your suggestion, but I am trying to find a consensus with Marcel and his POLA concerns. >> 3. Keep all non-CHS validations and sanity checks, of course. >> >> Long term (post-9 ?): 1. Change defaults to play nicer with modern disks >> >> Longer term: 1. Possibly remove any CHS reference from all the code, kernel >> and userland; invent better heuristic values for things like partitioning, >> UFS newfs, etc. > > You can't do that. CHS are still needed for sunlabel and pc98 support. OK. Excluding the special cases. -- Andriy Gapon