Hans de Goede wrote: > 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.
Whether extended partitions can exist is partition-table-specific, of course. I assume you realize this and that any changes will work just as well with, say, GPT partition tables. >> 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. I agree. Go for it. Please test thoroughly and at least outline your tests with enough detail that I can easily convert them to regression test scripts. Better still, write the tests (model after an existing one that uses t-lib.sh, (the ones that use the older "test-lib.sh" are gradually being rewritten). Your tests will probably require root access; don't hesitate to model new ones after the existing ones that do that. _______________________________________________ parted-devel mailing list [email protected] http://lists.alioth.debian.org/mailman/listinfo/parted-devel
