Date: Mon, 23 May 2011 11:38:36 -0600 From: Warner Losh <imp@bsdimp.com> To: Marcel Moolenaar <marcel@xcllnt.net> Cc: "Andrey V. Elsukov" <bu7cher@yandex.ru>, Warner Losh <imp@freebsd.org>, Poul-Henning Kamp <phk@freebsd.org>, Marcel Moolenaar <marcel@freebsd.org>, freebsd-geom@freebsd.org Subject: Re: [RFC] Remove requirement of alignment to track from MBR scheme Message-ID: <9ED563AB-7B35-40F4-A33E-015317858401@bsdimp.com> In-Reply-To: <D75B2856-D9D8-4BA3-BC54-8258610CEA06@xcllnt.net> References: <4DDA2F0B.2040203@yandex.ru> <D75B2856-D9D8-4BA3-BC54-8258610CEA06@xcllnt.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9ED563AB-7B35-40F4-A33E-015317858401>