From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 5B9FAC7EE23 for ; Wed, 10 May 2023 01:38:26 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235013AbjEJBiY (ORCPT ); Tue, 9 May 2023 21:38:24 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:55568 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229549AbjEJBiW (ORCPT ); Tue, 9 May 2023 21:38:22 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 568CE2D5E; Tue, 9 May 2023 18:38:21 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id D7E7F62DA7; Wed, 10 May 2023 01:38:20 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id DCD98C433EF; Wed, 10 May 2023 01:38:19 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1683682700; bh=8UGdS9GL0vGvJYHAS2fLEU9Z1+ii3pmqIijLsCfi86M=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=RFZVHM0j4liS/3aNZ826JrNLwC5otm2Q3bKJDr2dByo7MgFfLx8uQx6dpmF7IlLh+ e/PhZ07UfRvl5v91w4GBwg/Sa8napD58+7USm34O40MTjmAv9SM7ksrym/amhpDlIm KaqvHGbSSQdDLLyTatrz/0jw82WwfmS6yIy9bFliri6+tE6Eq5v/sJk/OlDWeICrAK IbkOikf9AsftiTKYmSKdL27sm/d8kDwxI7t6PyslE7OwDvdY+cT1jsGosnNSS+hPgd sl4MlNwIIKZ/VeDTsEtQA0vnlgTIM6nrTuFCU1tbhBGLTnHK1b19ptHAMLFh4W3hOg MDBZgVRpsfKwg== Date: Tue, 9 May 2023 18:38:19 -0700 From: "Darrick J. Wong" To: Dave Chinner Cc: Christoph Hellwig , Jens Axboe , Al Viro , Christian Brauner , linux-block@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-xfs@vger.kernel.org Subject: Re: [PATCH 5/9] block: introduce holder ops Message-ID: <20230510013819.GC858799@frogsfrogsfrogs> References: <20230505175132.2236632-1-hch@lst.de> <20230505175132.2236632-6-hch@lst.de> <20230505185119.GI15394@frogsfrogsfrogs> <20230509133501.GD841@lst.de> <20230509221958.GV3223426@dread.disaster.area> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20230509221958.GV3223426@dread.disaster.area> Precedence: bulk List-ID: X-Mailing-List: linux-fsdevel@vger.kernel.org On Wed, May 10, 2023 at 08:19:58AM +1000, Dave Chinner wrote: > On Tue, May 09, 2023 at 03:35:01PM +0200, Christoph Hellwig wrote: > > On Fri, May 05, 2023 at 11:51:19AM -0700, Darrick J. Wong wrote: > > > Fun question: What happens when the swap disk falls off the bus? > > > > Your system is toast. > > > > > > - if (IS_ERR(blkdev_get_by_dev(bdev->bd_dev, mode | FMODE_EXCL, &bdev))) > > > > + if (IS_ERR(blkdev_get_by_dev(bdev->bd_dev, mode | FMODE_EXCL, &bdev, > > > > + NULL))) > > > > return -EBUSY; > > > > ret = set_blocksize(bdev, n); > > > > blkdev_put(bdev, mode | FMODE_EXCL); > > > > > > Somewhat related question: Should we allow userspace to initiate a fs > > > shutdown through the block device? Let's say you're preparing to yank > > > /dev/sda and want to kill anything attached to it or its partitions? > > > Without having to walk through however many mount namespaces there are > > > to find the mountpoints? > > > > That's kinda what we're doing here. Or do you mean even more advanced > > notice by having another callout before stopping I/O so that we could > > write out all log buffers? It's probably doable, but I'm not convinced > > that this use case is worth maintaining and testing the kernel code for > > it. > > The userspace shutdown code already does this by default - it > actually calls freeze_bdev() to cause the filesystem to be made > consistent on the block device before it executes the shutdown. > So, in effect, we already have the "shutdown before turning off > block device" paths in the filesystems and extremely well tested. > > Indeed, if the device is being removed, why not call freeze_bdev() > before doing anything else? It guarantees that applications will be > quiesced and the filesystem will stabilise and not try to change > anything until the shutdown occurs when the device is pulled... I think I want everything -- I want freeze_bdev on a device /before/ we pull it out so that we can try to flush dirty everything to the disk; I want that to work for the log/rt devices; and I want a final shutdown notification when the kernel drops the bdev so that we can offline the fs and shortcut/start returning EIO. --D > Cheers, > > Dave. > -- > Dave Chinner > david@fromorbit.com