On 08/21/11 20:28, Marcel Moolenaar wrote:
On Aug 21, 2011, at 5:00 PM, Nathan Whitehorn wrote:
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.
That would work, but really the difference is quite small. I just went
through and fixed the remaining instances of this brokenness in my code.
There were 2, and it took 5 minutes, so I wouldn't worry about it.
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…
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.
Where would this class go? If it went below gpart (between gpart and
userland), then it seems like we would lose the ability of gpart to
validate its parameters. Who would be responsible for inserting this
GEOM into the stack?
-Nathan
_______________________________________________
[email protected] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[email protected]"
