Hello!
One of our customers has found out that commit 10c70d95c0f2 ("block: remove
the bd_openers checks in blk_drop_partitions") broke distro installation on
their machines. The problem with their setup is following: They have two
disks in RAID1 setup with 1.0 metadata (so RAID metadata is at the end). The
resulting RAID device is partitioned. Now when RAID device is assembled,
mdadm takes care to remove partitions of the underlying devices. So before
commit 10c70d95c0f2 /proc/partitions output looks like:
...
8 16 1048576 sdb
8 0 1048576 sda
9 0 1048512 md0
259 0 1047471 md0p1
After commit 10c70d95c0f2 the situation is the same until someone calls
BLKRRPART. Then partitions on sda and sdb are recreated because of missing
bd_openers check:
...
8 16 1048576 sdb
8 17 1048576 sdb1
8 0 1048576 sda
8 1 1048576 sda1
9 0 1048512 md0
259 0 838656 md0p1
This breaks installation because the partitioning code in the installer
does not count with this situation, tries to do something (call wipefs)
with the sda1 partition and gets an error.
As I've studied history behind partition rescanning I understand it is
difficult to please everybody :). But creating partitions under assembled
RAID device looks wrong to me. So I was wondering - couldn't
disk_scan_partitions() just refuse to operate on the device if there's
another exclusive opener (it will be a bit painful to do the check but it
is doable)? That will fix this problem with RAID and should
not be prone to races with udev or similar problems causing troubles in the
past. What do people think?
Honza
--
Jan Kara <jack@xxxxxxxx>
SUSE Labs, CR
