[parted-devel] [BUG] _disk_sync_part_table() is broken

Joel Granados jgranado at redhat.com
Tue Nov 11 14:37:13 UTC 2008


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" <petr.uzel at suse.cz> 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: puzel at suse.cz
> 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
> parted-devel at lists.alioth.debian.org
> http://lists.alioth.debian.org/mailman/listinfo/parted-devel

-- 
Joel Andres Granados
Red Hat / Brno Czech Republic



More information about the parted-devel mailing list