On 3/1/16 2:45 PM, Eric Sandeen wrote: > On 8/5/15 2:13 PM, Eric Sandeen wrote: >> The BLKRRPART ioctl already fails today if any partition under >> the device is mounted. However, if we mkfs a whole disk and mount >> it, BLKRRPART happily proceeds down the invalidation path, which >> seems like a bad idea. >> >> Check whether the whole device is mounted by checking bd_super, >> and return -EBUSY if so. >> >> Signed-off-by: Eric Sandeen <sandeen@xxxxxxxxxx> >> --- >> >> I don't know for sure if this is the right approach, but figure >> I'll ask in the form of a patch. ;) > > I'm now thinking that this is not the right approach. :( I got a > bug report stating that during some md raid1 testing with replacing > failed disks, filesystems were losing data. I haven't reproduced > that part yet, but... > > It's hitting the "bd_super" case added in the patch below, and returning > -EBUSY to md when mdadm tries to to remove a disk: > > # mdadm /dev/md0 -r /dev/loop0 > mdadm: hot remove failed for /dev/loop0: Device or resource busy > > [ 1309.894718] md: cannot remove active disk loop0 from md0 ... > [ 1309.906270] drop_partitions: bd_part_count 0 bd_super ffff880111364000 > [ 1309.919295] drop_partitions: s_id md0 uuid 6bb155fe-3ea1-4a84-b66a-d44d44829c36 > [ 1309.933878] CPU: 2 PID: 531 Comm: systemd-udevd Not tainted 3.10.0+ #4 Urk, forgot I was testing an old kernel, sorry. I think upstream is ok. I'll shut up and investigate more. -Eric -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
