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 FWIW, just ignore me, I was being an idiot. a) the patch *prevents* the corruption; does not cause it; without the EBUSY, drop_partitions will get to invalidate_inodes() etc, and no wonder data is lost. And b) the above EBUSY is because I forgot to fail the disk first. :/ Nothing to see here, move along, sorry! -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
