On 01/09/2016 03:17 PM, Dan Williams wrote:
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.
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@xxxxxxx +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)
_______________________________________________
xfs mailing list
xfs@xxxxxxxxxxx
http://oss.sgi.com/mailman/listinfo/xfs
