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