I saw this same behavior when doing the same test. Did a `git revert f6bd20573e3ecfb63f62d88c52a0870fb8851b59` and after getting some git-revert conflicts out of the way I retested and found that the issue was no more.
We should probably do a revert of that specific commit :) Regards. ----- "Petr Uzel" <[EMAIL PROTECTED]> wrote: > Hi list! > > There's a bug in current development version of parted which causes > that the > partition table, as seen by the kernel, is not updated correctly after > deleting > a partition. This bug was introduced in commit > f6bd20573e3ecfb63f62d88c52a0870fb8851b59 (fix computation of largest > partition > number). Yes, I know - this patch was proposed by me - sorry for that > :) > > Steps to reproduce: > ------------------- > > Start with the empty partition table, create primary partition and > then delete this > partition. The on-disk partition table representation is correct, but > the kernel is > not correctly informed about the change. This might be fixed by > running > 'blockdev --rereadpt /dev/hdd' command. > > # ./parted/parted /dev/hdd > GNU Parted 1.8.8.1.90-cc1f > Using /dev/hdd > Welcome to GNU Parted! Type 'help' to view a list of commands. > (parted) print > Model: WDC WD153BA (ide) > Disk /dev/hdd: 15.4GB > Sector size (logical/physical): 512B/512B > Partition Table: msdos > > Number Start End Size Type File system Flags > > (parted) mkpart primary ext2 0 2G > (parted) rm 1 > (parted) print > Model: WDC WD153BA (ide) > Disk /dev/hdd: 15.4GB > Sector size (logical/physical): 512B/512B > Partition Table: msdos > > Number Start End Size Type File system Flags > <SNIP> > > # cat /proc/partitions > <SNIP> > 22 64 15021720 hdd > 22 65 1951866 hdd1 > # blockdev --rereadpt /dev/hdd > # cat /proc/partitions > <SNIP> > 22 64 15021720 hdd > > Analysis: > --------- > > When the partition is deleted, parted first updates its in-memory > representation of partition table [1], then it writes the partition > table a > then it commits the changes to OS. On newer kernels, the disk commit > is done by > _disk_sync_part_table() called from linux_disk_commit(). > > This function needs to inform the kernel that partition #1 was > deleted. To find > out what partitions it should iterate over, it uses MIN(16, > ped_disk_get_last_partition_num(disk)). > But the problem is that ped_disk_get_last_partition_num() uses > in-memory > representation of partition table, in which the partition table has > no > partitions (see [1]), and thus it returns -1. > > The result is that parted does not inform the kernel that partition #1 > was deleted. > > Previous state: > --------------- > > Before the broken commit was checked in, parted used PED_MAX(16, > last_partition_num()) > to determine which partitions might be changed. But this also is not > correct, because : > 1. for <= 16 partitions on the disk, the last_partition_num() call is > useless > 2. if there's >16 partitions, the last_partition_num() might return > inconsistent > result (in case the last partition was just deleted) > > I know that there may be situations where there are more than 16 > partitions on > the disk, but does parted want to support this? If not, the > PED_MAX(16, last_partition_num()) > might be changed to be just 16 and everything should work fine. > > Another solution might be introducing something like > 'last_sensible_partition_num()', which would return the largest > partition > number that would make sense, depending on disk label type, OS, ... > > Note: _dm_reread_partition_table() probably suffers the same - I have > not tested > it personally, though. > > What do you guys think? > > And once again - sorry for introducing that bug to parted. > > > -- > Best regards / s pozdravem > > Petr Uzel, Packages maintainer > --------------------------------------------------------------------- > SUSE LINUX, s.r.o. e-mail: [EMAIL PROTECTED] > Lihovarská 1060/12 tel: +420 284 028 964 > 190 00 Prague 9 fax: +420 284 028 951 > Czech Republic http://www.suse.cz > > _______________________________________________ > parted-devel mailing list > [email protected] > http://lists.alioth.debian.org/mailman/listinfo/parted-devel -- Joel Andres Granados Red Hat / Brno Czech Republic _______________________________________________ parted-devel mailing list [email protected] http://lists.alioth.debian.org/mailman/listinfo/parted-devel
