Multiple issues with commit_to_os (Linux)

[Hans de Goede]

Hi All,

Short intro: I'm an anaconda (The Fedora installer) developer, and
anaconda uses parted for its partitioning.

While testing partitionable mdraid I noticed that the kernels
view of the partition table never changes even though I was successfully
making commit_to_os() calls.

This has let to me diving into libparted's commit_to_os() code for Linux
and there are multiple issues hiding in there:

1) Parted reads /sys/block/foo/range to determine how many partitions
   the device type supports and then makes BLKPG ioctl's to update the
   kernels view of the partition table for partitions which fall into
   this range. However for example /sys/block/sda/range contains 16,
   there are 2 issue with libparted using this number:
   1) scsi major's only support 15 partitions, 1 of the range of 16
      is reserved for the whole device, yet libparted will try
      to notify the kernel about 16 partitions if present
   2) If the major's partition minor's run out, the kernel will switch
      to the mdp major for the other partitions, iow range no longer limits
      the number of partitions.

2) libparted assumes the user knows what he is doing, and will ignore
   -ebusy errors for partitions, assuming that the user is smart enough
   to only change unused partitions. Parted does this without checking
   if the partitions which return ebusy actually are unchanged causing
   REAL errors to get unreported (BAD, really really BAD)

3) because of 1) libparted will only sync 1 partition on /dev/md# devices
   (would be 0 if not for the of by 1 bug as all md#p# partitions use the
    mdp major), and it fails to even do that without reporting an error.

###

1) we can fix by simply not checking /sys/block/foo/range, but instead
   just syncing max partitions.

2) is more troublesome, we could just make -EBUSY n error,
   but that may annoy / bug some users. OTOH in certain cases libparted already
   falls back to BLKRRPART which will return EBUSY so users should already be
   prepared to handle EBUSY

3) Could be fixed by making libparted recognize mdraid as a device type
   and except mdraid from using BLKPG, like it already is doing with
   DASD, but it might be better to just get rid of using BLKPG al together.
   See below.

An even bigger problem IMHO is the use of the BLKPG ioctl instead of BLKRRPART
at all. What this does is tell the kernel parted's view of the partition table
and make it use that, instead of telling the kernel to reread the partition 
table.
According to the parted sources this is done for the case where the kernel does
not know the disklabel type. However as soon as the system is rebooted, the 
system
will be using the kernel's view. So IMHO it would be much better to always use 
the
kernels view and just always call BLKRRPART in commit_to_os(), this would solve 
all
of the above issues, *and* make the way the system views the partition table 
consistent
between just after running parted and after a reboot.

I've attached a patch which removes the use of the BLKPG ioctl, notice that 
this also
removes a lot of special case code and workarounds, which existence to me 
clearly
indicates that using the BLKPG ioctl is a bad idea.

Regards,

Hans

parted-1.9.0-no-BLKPG.patch
Description: Text document