Hi,
On 03/18/2010 07:04 PM, Phillip Susi wrote:
On 3/18/2010 12:17 PM, Hans de Goede wrote:
I don't remember the exact details, but iirc the blkpg code worked by
first removing all partitions, and re-adding them ignoring all
errors in the process to allow "skipping" busy partitions.
It appears so.
Only making it remove / re-add changed partitions would have required
serious reworking of the code in question. So I opted for just throwing
it out all together.
Also BLKPG does not work on all types of partitionable devices (it does
not work for example on dasd disks).
Anyways, as said doing BLKPG correctly requires some significant
reworking of the old code, patches welcome.
I'm taking a look at it now. My first thought was to check for the
removal failure, and as long as you are about to add the partition back
exactly the same way, ignore it, otherwise, propagate the error up.
Does that sound good?
Yes something like that should work, although I myself was thinking more
along the lines of adding a dirty field to the diskspecific partition
data struct, and using that, and not trying to remove unchanged partitions
at all.
Thinking more about this, consider this scenario (another example of
why I went the easy route and just cut out BLKPG support):
Disk has an extended partition, lets say sda4
The extended partition has 3 logicals in it:
sda5, sda6, sda7
sda5 and sda6 get removed, and replaced by a single new
logical.
Note that sda7 now has become sda6 in for example parted print
output.
Questions:
1) If a partition number changes, should it be marked as dirty
(So removed and re-added using BLKPG), IMHO: Yes
2) What if sda7 is busy ? Options:
a) leave it as sda7, inconsequent with parted print output,
end result confused user, also see below wrt fstab
b) Fail the commit
User: but I'm allowed to change partitions as long as I
don't touch the ones which are in use,
end result confused user
Also note how in this scenario with 1.8, even if the user was
smart enough to not touch any in use partitions, things
would still not be the same as after a reboot (sda7 after commit
becomes sda6 after reboot). sda7 mentioned in fstab by device node
name -> fail
So given the above I would like to retract my "patches welcome"
statement and replace it by:
"Using BLKPG just is not a very good idea IMHO"
I know people were used to the old behavior, but the old
behavior relied on a lot of brokenness.
Regards,
Hans
_______________________________________________
parted-devel mailing list
[email protected]
http://lists.alioth.debian.org/mailman/listinfo/parted-devel
