[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Confirmed Bug] Parted does not notify kernel when modifying partition t

From: Christopher White
Subject: [Confirmed Bug] Parted does not notify kernel when modifying partition tables in partitionable md arrays
Date: Fri, 13 May 2011 21:56:39 +0200
User-agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv: Gecko/20110414 Thunderbird/3.1.10


After some serious back-and-forth on the md mailing list, it finally turned out to be a bug in (g)parted, which has been reproduced by two people on separate machines using the latest versions of (g)parted. Here's how to reproduce the bug:

Step 1:
Create a PARTITIONABLE md array with mdadm (change parameters to whatever test parameters you use, but keep the --auto=partX flag to make it a partitionable md array): mdadm --create --level=raid5 --auto=part2 /dev/md1 --metadata=1.2 --raid-devices=4 /dev/sda2 /dev/sdb2 /dev/sdc2 /dev/sdd2

Step 2:
Verify that the device was created (ls /dev/md* will show /dev/md1 and nothing else since there are no partitions yet)

Step 3:
Run (g)parted on the MD array(this bug exists in both parted and gparted, I prefer gparted but phil verified it in parted as well):
parted /dev/md1

Step 4:
Create a partition table (type doesn't matter, I use GPT)

Step 5:
Create two partitions.

Step 6:
Apply the changes to write them to disk.

Step 7:
Check the device list (ls /dev/md*) and you will NOT see two partitions, you will still just see /dev/md1.

Step 8:
Manually force a device re-scan in the kernel (blockdev --rereadpt /dev/md1).

Step 9:
Check the device list (ls /dev/md*) and you WILL see two partitions (/dev/md1, /dev/md1p1 and /dev/md1p2).

This is a serious bug, because if you try to use (g)parted to not only make the partitions but also tell it to FORMAT the partitions in a particular way, it will actually FAIL when it tries to execute mkfs.XXX on each partition, since it cannot find /dev/md1p* due to the kernel not having re-scanned the partition table after the partitions were created.

Other tools such as fdisk work properly and will properly tell the kernel to re-scan the partition table after writing the partition table modifications.

(g)parted properly notifies the kernel about partition table changes when modifying PHYSICAL disks. The bug only applies to working with md-arrays.

Phil Turman managed to detect a probable cause for the bug, and I will quote him:

"I suspect (g)parted is in fact requesting a rescan, but is being ignored.
I just tried this on one of my servers, and parted (v2.3) choked on an assertion. Hmm."

I hope this is enough information to get an idea of where the bug is, because I do not have the luxury of performing more testing, but all steps to fully reproduce the bug are above.

Useless side info but I'll mention it before anyone asks: Linux Mint 11 RC, Kernel 2.6.38-8-generic.

Christopher White

reply via email to

[Prev in Thread] Current Thread [Next in Thread]