On Fri, Jan 8, 2016 at 11:54 PM, Al Viro <viro@xxxxxxxxxxxxxxxxxx> 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.
|