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
===================================================================
--- sys/geom/part/g_part_mbr.c (revision 222183)
+++ sys/geom/part/g_part_mbr.c (working copy)
@@ -473,7 +473,7 @@
basetable->gpt_entries = NDOSPART;
basetable->gpt_first = basetable->gpt_sectors;
- basetable->gpt_last = msize - (msize % basetable->gpt_sectors) - 1;
+ basetable->gpt_last = msize - 1;
g_free(buf);
return (0);
Warner
_______________________________________________
[email protected] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-geom
To unsubscribe, send any mail to "[email protected]"
