From mboxrd@z Thu Jan 1 00:00:00 1970 From: Greg KH Subject: Re: Some way of telling which block devices are in use (and how) Date: Mon, 30 Apr 2012 12:21:30 -0400 Message-ID: <20120430162130.GA17238@kroah.com> References: <20120429201830.GA10188@kroah.com> <20120429212305.GB7342@thunk.org> <20120429220512.GC7342@thunk.org> <20120430051033.GA562@kroah.com> <20120430091119.GE7342@thunk.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: linux-fsdevel@vger.kernel.org, Al Viro To: Ted Ts'o Return-path: Received: from mail-pb0-f46.google.com ([209.85.160.46]:51179 "EHLO mail-pb0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755972Ab2D3QVg (ORCPT ); Mon, 30 Apr 2012 12:21:36 -0400 Received: by pbbrp8 with SMTP id rp8so3429481pbb.19 for ; Mon, 30 Apr 2012 09:21:35 -0700 (PDT) Content-Disposition: inline In-Reply-To: <20120430091119.GE7342@thunk.org> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: 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