Re: Well, there goes Windows!

On Aug 21, 2011, at 5:00 PM, Nathan Whitehorn wrote:
>=20
> No, it's stupider than that. When you destroy a gpart without =
committing, the GEOM itself lingers as a (none)-type partitioning. This =
of course makes sense, since that ghost geom is what is maintaining all =
the state, but sometimes causes problems. For instance, it breaks some =
of  my lazy code that identifies non-partitioned disks by seeing if =
there is a GEOM there. But, while slightly more complicated to detect, =
this would not be too difficult to fix.

What if gpart always creates the null scheme if no partitioning exists =
on the
media? Then the difference between none but uncomitted and just plain =
none is
gone and we can always make sure the distinction is represented in the =
XML.
This would also improve the current behavior of "gpart show" in that you =
don't
get to see any disks that don't have partitions right now.

> The larger problem is that this behavior means that destroying gparts =
sometimes doesn't work at all. For instance, if you have nested =
partitioning like MBR+BSD (or EBR) it is not possible to destroy the =
underlying MBR geom without committing the destruction of the BSD geom. =
This is because the MBR geom cannot be destroyed, even without =
committing, while it continues to have children, which it does due to =
the ghost geom for the BSD slice.

Yup. It would be good if we can fix that=85

> The regular partitioning editor only commits early in this particular =
case, and asks about each subpartition tree separately with a big scary =
dialog box. In the spirit of the autopartitioner, it makes one large =
scary dialog, and always runs in early commit mode instead of =
potentially showing many scary dialogs about partitions the user doesn't =
necessarily even know about. This behavior could be changed, but I think =
is the most friendly for the case in question: namely, "I want to blow =
away everything and let the installer handle all partitioning details by =
itself".

What about inserting a special class for doing commit/undo. The GEOM
simply keeps all modifications in memory and 1) forgets everything on
an undo operation or 2) writes all dirty sectors on a commit. This
could be used even instead of the gpart-private support, which also
removes the quirk for the null scheme.

--=20
Marcel Moolenaar
marcel@xcllnt.net

_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"