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

[Greg KH <gregkh@linuxfoundation.org>]

On Mon, Apr 30, 2012 at 05:11:19AM -0400, Ted Ts'o wrote:
> 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.

I agree, I think it would be better to do this at the VFS layer, but at
that point, we don't really "know" what filesystem is mounted here, do
we?  As the dm/lvm/md/ecryptfs/union/etc. stacking starts to add up,
where should we even start to point at as well?

> 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".

Well, what specifically can cause a block device to be marked "busy"
today?  Is this "just" a reference count being held on the superblock?
Or something else?

> 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?

I think you know that today with /sys/fs/ext4/ right?  (Which, btw, I
hadn't noticed before, very nice, but why not have a symlink back to the
/sys/devices/ tree to the "real" disk device that ext4 is mounted on?  A
"device" symlink would be nice to create, don't you think?

> 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.

If part of this is just to provide a common "core" set of code that any
fs can use to create the /sys/fs/FSNAME/ block links, that would be
great to have and make it easier to add to each of the filesystems.
That in itself would be worthy.

> > 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.  :-)

My dmesg seems to differ at times, given the number of nasty warnings
that get spit out when this happens :)

> > 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?

I think /proc/$pid/mounts needs to be where the namespace is expressed,
and have /sys/* be "namespace neutral" if at all possible.  That being
said, sysfs does have namespace controls and I know the networking layer
takes advantage of this, so it is possible to do this in sysfs as well.

thanks,

greg k-h