On Mon, Apr 30, 2012 at 01:10:33AM -0400, Greg KH wrote: > > And why would you be doing this at a fs-specific level? If you want to > know what type of filesystem is mounted on each block device, yes, that > would matter, but you don't. You want to know what is "busy", right? Well, I'd much rather do something at the VFS layer. But my experience is that getting consensus across all of the various FS maintainers is sometimes, well, hard. And the meantime, I'd like it to be easier to debug various problems. The complete problem I'd like to solve is to be able to answer, in a debugging situation, why a particular block device is "busy". If I can't get that, in the worst case, I'd like to be able to answer the question, is this block device being used by ext4? And if that's something I can solve by myself, where there's resistance to solving the whole problem, at least I can make my patch of the world a little easier to debug. > And "busy" means different things, including the fact that the whole > block device underneath can disappear at any moment no matter how much > it isn't nice that this happens. Sure, at which point it's not my problem. :-) > So a combination of 'lsof' and other things might just be the best that > we can do, like GNOME and KDE are doing today. As you point out the > mount namespace issue, it gets really tricky to try to figure it all > out, so maybe we really don't want to? The mount namespace issue is one of the ones that has always worried me, because it's very hard to debug. And as it gets more and more use, it would be nice if there was an answer better than, "just iterate over /proc/$pid/mounts". Think of the issue from the point of view of a someone at a RHEL or SLES help desk, trying to debug a problem where they don't have access to the remote system, and want to tell the user to issue a command which gathers as much information as possible. Do we really think the best thing to do is to gather up information on a per-pid basis? As to your last point, we're kernel developers. Since when has something been hard been a reason not to do the right thing? :-) - Ted -- 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
