On Thu, 21 Jun 2012, Dave Chinner wrote: > > > As it is, I think that invalidate_partition() is doing something > > > somewhat insane for a block device that has been removed - you can't > > > write to it so fsync_bdev() is useless. > > > > That depends. If by "removed" you mean physically disconnected from > > the computer, then yes. But if "removed" means merely unregistered > > from the device core then writes can still succeed. > > invalidate_partition() doesn't know which has happened. > > Which means the lower layers probably need to pass that distinction > up to the invalidation function. I don't think that information is passed anywhere in the kernel. And in any case, it's not really important. When a device is unregistered, the upper layers shouldn't care about the reason why. > > > And another question - why doesn't having an active filesystem on a > > > block device (i.e. an active reference to the gendisk) prevent the > > > block device from being removed from underneath it? > > > > References prevent data structures from being deallocated, not from > > being unregistered (or as James Bottomley likes to call it, "removed > > from visibility"). > > Except the unregister path appears to assume that a valid block > device available when it is unregistered. It may very well be available during the unregistration procedure. There's nothing wrong with assuming it is -- if it isn't, I/O attempts will simply fail. > That seems to me like > there is a bad assumption being made in this error handling path... No; a bad assumption would be if the code assumed the device was available _after_ the unregistration call had completed. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
