Hi,
On 03/18/2010 10:29 PM, Phillip Susi wrote:
On 3/18/2010 5:05 PM, Hans de Goede wrote:
On 03/18/2010 09:49 PM, Phillip Susi wrote:
I think the only option is to require that the removal of an extended
partition that would cause such a renumbering should fail. The user
will not be confused because they will get the same message they do now
when BLKRRPART fails, telling them that the kernel is still using the
old table and they need to reboot for the changes to take effect. The
only difference from using BLKRRPART would be that the partitions NOT in
use with numbers higher than the one that was in use will have already
been removed from the kernel.
True, that would work. Note that you will need to get Jim Meyering
to buy on on this approach as well for it to get accepted upstream.
What if we iterate over the partitions starting from the last, opening
each device with O_EXCL, to test if it is in use. If it succeeds, we
know that we can then remove the partition. If we find an extended
partition ( number> 4 ) that we can't lock, then we note our current
position.
Then we restart iterating backwards down the list of extended
partitions, this time comparing the new partition table with the
kernel's current view of that partition. If it differs, we know that we
need to delete that partition from the kernel table. As long as this
partition is> the partition we stopped on above, we are fine, but if
not, we fail.
Now we know that it is safe to repartition, so we can iterate over the
partitions, comparing them with the current kernel view, and when they
differ, delete the kernel partition and add it back using the new settings.
This way we only delete partitions that actually change, and we do
nothing if doing so would result in renumbering extended partitions that
can not be deleted.
This sounds a bit complicated, but I think the intend of not making
any changes at all when we expect some changes to fail is very good,
so if you want to do give implementing this a try, go for it.
Regards,
Hans
_______________________________________________
parted-devel mailing list
[email protected]
http://lists.alioth.debian.org/mailman/listinfo/parted-devel
