From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from sandeen.net ([63.231.237.45]:33936 "EHLO sandeen.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753593AbcCBWNM (ORCPT ); Wed, 2 Mar 2016 17:13:12 -0500 Subject: Re: [PATCH] block: return EBUSY from drop_partitions on mounted whole disk device To: Eric Sandeen , "linux-fsdevel@vger.kernel.org" References: <55C26043.20002@redhat.com> <56D5FF69.6070004@redhat.com> Cc: Jens Axboe , Jes.Sorensen@redhat.com From: Eric Sandeen Message-ID: <56D76575.6050901@sandeen.net> Date: Wed, 2 Mar 2016 16:13:09 -0600 MIME-Version: 1.0 In-Reply-To: <56D5FF69.6070004@redhat.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Sender: linux-fsdevel-owner@vger.kernel.org List-ID: 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 >> --- >> >> 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