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. _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
