From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mike Snitzer Subject: Re: [PATCH 11/12] fs: don't reassign dirty inodes to default_backing_dev_info Date: Sat, 21 Mar 2015 11:11:09 -0400 Message-ID: References: <1421228561-16857-1-git-send-email-hch@lst.de> <1421228561-16857-12-git-send-email-hch@lst.de> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Cc: Jens Axboe , David Howells , Tejun Heo , linux-fsdevel , linux-mm-Bw31MaZKKs3YtjvyW6yDsg@public.gmane.org, linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org, linux-nfs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, ceph-devel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, device-mapper development To: Christoph Hellwig Return-path: In-Reply-To: <1421228561-16857-12-git-send-email-hch-jcswGhMUV9g@public.gmane.org> Sender: linux-nfs-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org List-Id: linux-fsdevel.vger.kernel.org On Wed, Jan 14, 2015 at 4:42 AM, Christoph Hellwig wrote: > If we have dirty inodes we need to call the filesystem for it, even if the > device has been removed and the filesystem will error out early. The > current code does that by reassining all dirty inodes to the default > backing_dev_info when a bdi is unlinked, but that's pretty pointless given > that the bdi must always outlive the super block. > > Instead of stopping writeback at unregister time and moving inodes to the > default bdi just keep the current bdi alive until it is destroyed. The > containing objects of the bdi ensure this doesn't happen until all > writeback has finished by erroring out. > > Signed-off-by: Christoph Hellwig > Reviewed-by: Tejun Heo > --- > mm/backing-dev.c | 91 +++++++++++++++----------------------------------------- > 1 file changed, 24 insertions(+), 67 deletions(-) Hey Christoph, Just a heads up: your commit c4db59d31e39ea067c32163ac961e9c80198fd37 is suspected as the first bad commit in a bisect performed to track down the cause of DM crashes reported in this BZ: https://bugzilla.redhat.com/show_bug.cgi?id=1202449 I've yet to look closely at _why_ this commit but figured I'd share since this appears to be a 4.0-rcX regression. Mike -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html