From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pa0-f53.google.com ([209.85.220.53]:34796 "EHLO mail-pa0-f53.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751454AbcCBWPs (ORCPT ); Wed, 2 Mar 2016 17:15:48 -0500 Received: by mail-pa0-f53.google.com with SMTP id fy10so1698527pac.1 for ; Wed, 02 Mar 2016 14:15:47 -0800 (PST) Subject: Re: [PATCH] block: return EBUSY from drop_partitions on mounted whole disk device To: Eric Sandeen , Eric Sandeen , "linux-fsdevel@vger.kernel.org" References: <55C26043.20002@redhat.com> <56D5FF69.6070004@redhat.com> <56D76575.6050901@sandeen.net> Cc: Jes.Sorensen@redhat.com From: Jens Axboe Message-ID: <56D76610.4050207@kernel.dk> Date: Wed, 2 Mar 2016 15:15:44 -0700 MIME-Version: 1.0 In-Reply-To: <56D76575.6050901@sandeen.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On 03/02/2016 03:13 PM, Eric Sandeen wrote: > > > 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! Still beats a regression :-) -- Jens Axboe