Re: [resend PATCH 1/3] block, fs: reliably communicate bdev end-of-life

[Hannes Reinecke <hare@suse.de>]

On 01/09/2016 03:17 PM, Dan Williams wrote:
> On Fri, Jan 8, 2016 at 11:54 PM, Al Viro <viro@zeniv.linux.org.uk> 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)