Date: Sun, 20 May 2012 12:50:06 -0700 From: Tim Kientzle <tim@kientzle.com> To: Rozhuk.IM@gmail.com Cc: 'User Wojtek' <wojtek@wojtek.tensor.gdynia.pl>, 'Matthias Apitz' <guru@unixarea.de>, freebsd-hackers@freebsd.org Subject: Geom_mbr vs. SSD disks (was: proper newts options for SSD disks) Message-ID: <CFA47342-DE88-436E-9DE3-16E8FF266444@kientzle.com> In-Reply-To: <4fb7e819.6968700a.7a7f.ffff9153@mx.google.com> References: <alpine.BSF.2.00.1205182209010.9350@wojtek.tensor.gdynia.pl> <4fb7dfd6.736a980a.186d.ffff902f@mx.google.com> <20120519180901.GA1264@tiny> <4fb7e819.6968700a.7a7f.ffff9153@mx.google.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On May 19, 2012, at 11:36 AM, rozhuk.im@gmail.com wrote:
> Do not use MBR (or manually do all to align).
> 63 - not 4k aligned.
Right now, the "-a" alignment option for "gpart add" is broken when
used with MBR partitions. It looks like the gpart command uses
it to correctly align the start/end, but then the actual MBR geom code
does another alignment pass that rounds the start/size to
a multiple of gpt_sectors, which defaults to 63.
This seems problematic.
It's tempting to change sys/geom/part/g_part_mbr.c so that
it skips this additional alignment when the geometry has
defaulted. Something like this:
Index: sys/geom/part/g_part_mbr.c
===================================================================
--- part/g_part_mbr.c (revision 235597)
+++ part/g_part_mbr.c (working copy)
@@ -211,6 +211,7 @@
start = gpp->gpp_start;
size = gpp->gpp_size;
+ if (sectors != 63 || basetable->gpt_heads != 255) {
if (size < sectors)
return (EINVAL);
if (start % sectors) {
@@ -221,6 +222,7 @@
size = size - (size % sectors);
if (size < sectors)
return (EINVAL);
+ }
if (baseentry->gpe_deleted)
bzero(&entry->ent, sizeof(entry->ent));
I'm not really certain I understand all of the implications
of this change, though.
Tim
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CFA47342-DE88-436E-9DE3-16E8FF266444>