On 04/23/2009 05:41 PM, David Lehman wrote:
On Thu, 2009-04-23 at 17:01 +0200, Hans de Goede wrote:
When a PV partition is part of an inconsistent VG, and the user chooses
to ignore it we currently remove it from the devicetree, but since
partition_gui.py populate() uses parted on the disk to find out about
the partitions, it will still see it and then backtrace when it cannot
find it in the devicetree.
I've forgotten why we can't just ignore partitions we find that aren't
in the device tree. Other than FREESPACE partitions, I can't think of a
reason why we'd want to do anything with such a partition, unless it
involves our naming shenanigans with new partitions.
Well, if we just plain ignore it, then it won't show in the stripe, nor
in the list, and the user might get mightely confused that he has a 100 gig
disk with 75 gigs of partitions on it and he cannot create anymore due to
lack of space.
This patch fixes this by instead making the partition immutable. Note
that I've put the reason for it being immutable in the new immutableDevices
array, so that if we have similar cases in the future we can use
immutableDevices for that too. We might even want to move some of our
existing cases there.
We could also just add a check in Storage/deviceImmutable to see if it's
listed/marked as part of a broken VG.
That feels wrong, I thing we should simplify Storage/deviceImmutable, not
complicate it.
The real problem here is I cannot use protectedPartitions, because
the reason shown to the user for a partition being in protectedPartitions
is hardcoded.
To me the real solution would be to remove protectedPartitions (why is it
an array anyways, it never has more then one member), and add the hd media
holding partition to an immutableDevices array (as my patch creates), which
holds both an identifier (for example the device name) and the reason why
the device is immutable, this to me feels as a much more generic solution
then all the special casing inside Storage/deviceImmutable
Regards,
Hans
_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
