>> The problem with pushing this policy to the user is that software >> applications have no means to determine that a device is currently >> in-use. For instance, the net result of pulling a device on a mounted >> filesystem is an eventual kernel panic. > >The kernel only panics if you told it to with the mount option >errors=panic (or if you have errors=panic set in the superblock flags). > >For file systems on removable devices ...
This is all valid argument for removable devices, but I don't think that's really what we're talking about here. I think we're talking about a device that can't physically disappear, but can, unfortunately, logically disappear via remove-single-device. For a fixed device, it is perfectly reasonable to design a system that assumes the device sticks around. Any older system would definitely be designed that way. Such a system, whether it technically panics or not, will probably utterly fail if the disk disappears. It was accessing that disk for a reason. Because removable devices exist, we do have to allow remove-single-device of an in-use device in general, but it would be good (and probably easy) to provide for the other case as well. The code obviously knows that the device is in use, because /dev/sda doesn't get reused. If there were a version of remove-single-device that said, "only if unused," that would solve the problem. If there are synchronization issues that make that hard, then making it possible for the user to query that in-use state would still go a long way toward solving the problem. -- Bryan Henderson IBM Almaden Research Center San Jose CA Filesystems - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
