Re: Some way of telling which block devices are in use (and how)

[Ted Ts'o <tytso@mit.edu>]

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