From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx2.suse.de ([195.135.220.15]:44668 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750710AbcAKHPg (ORCPT ); Mon, 11 Jan 2016 02:15:36 -0500 Subject: Re: [resend PATCH 1/3] block, fs: reliably communicate bdev end-of-life To: Dan Williams , Al Viro References: <20160104181220.24118.96661.stgit@dwillia2-desk3.amr.corp.intel.com> <20160104182005.24118.50361.stgit@dwillia2-desk3.amr.corp.intel.com> <20160109075414.GA5008@ZenIV.linux.org.uk> Cc: XFS Developers , linux-block@vger.kernel.org, linux-nvdimm , Dave Chinner , Jens Axboe , Jan Kara , linux-fsdevel , Matthew Wilcox , Ross Zwisler From: Hannes Reinecke Message-ID: <56935694.1000408@suse.de> Date: Mon, 11 Jan 2016 08:15:32 +0100 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On 01/09/2016 03:17 PM, Dan Williams wrote: > On Fri, Jan 8, 2016 at 11:54 PM, Al Viro wrote: >> On Mon, Jan 04, 2016 at 10:20:05AM -0800, Dan Williams wrote: > [..] >> Would you mind explaining what the hell is _the_ backing device >> of a filesystem? What does that translate into in case of e.g. btrfs >> spanning several disks? Or ext4 with journal on a different device, for >> that matter? >> >> If anything, I would argue that filesystem is out of place here - >> general situation is "IO on X may require IO on device Y and X needs to do >> something when Y goes away". Consider e.g. /dev/loop backed by a device >> that went away. Or by a file on fs that has run down the curtain and joined >> the bleedin choir invisible. With another fs partially hosted by that >> loopback device. Or by RAID0 containing said device. >> >> You are given Y and attempt to locate the affected X. _Then_ >> you assume that X is a filesystem and has "something to be done" independent >> from the role Y played for it, so you can pick that action from superblock >> method. >> >> IMO you are placing the burden in the wrong place. _Recepient_ >> knows what it depends upon and what should be done for each source of >> trouble. So make it recepient's responsibility to request notifications. >> At which point the superblock method goes away, along with the requirement >> to handle all sources of trouble the same way, etc. >> >> What's more, things like RAID5 (also interested in knowing when >> a component has been ripped out) might or might not decide to propagate >> the event further - after all, that's exactly the point of redundancy. >> >> I'd look into something along the lines of notifier chain per >> gendisk, with potential victims registering a callback when they decide >> that from now on such and such device might screw them over... > > Makes sense. I'll drop this series for now and come back after > re-working it use notifiers. Yes please. I need a similar thing for communicating device changes (resizing, topology changes), so I'd be very much interested in them. And while you're at it, maybe we can fold the block device event handling into that, too. Cheers, Hannes -- Dr. Hannes Reinecke zSeries & Storage hare@suse.de +49 911 74053 688 SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton HRB 21284 (AG Nürnberg)