site_archiver@lists.apple.com Delivered-To: darwin-kernel@lists.apple.com The what things are stores is that there is a list of processes. For each of these processes, there is a per process open file table. So don't do that - pretty simple. - (3) You only push useful data, instead of pushing everything -- Terry _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.a... On Oct 27, 2006, at 12:42 PM, Rick Mann wrote: On Oct 27, 2006, at 12:21 , Michael Smith wrote: There is a reason that lsof does this. The information you're looking for is not maintained by the system; it would be expensive to do so, and the work would almost always be wasted. I'm not sure I agree with this assertion. I don't think it would be asking too much. The Mac OS (Carbon) file system was able to do it, and I hardly think that support could be blamed for any significant slowdown. (Mind you, this is speculation). Carbon did this in pre-Mac OS X days by running in the same address space; if you don't do protection domain crossing for each piece of information, it's a heck of a lot easier to do what you are trying to do. If you have to cross protection domains (e.g. because you have an OS that prevents one application from brining unrelated applications down (best case) or the whole system down (worst case), then it's very expensive. For each per process open file table entry, there's a pointer to a fileglob. Multiple open file instances in the same process and in other processes in the system (either child, parent, or processes which have used UNIX domain sockets to pass an open descriptor around) can point to the same fileglob. For a fileglob, there's a pointer to an fd_data; what this represents depends on the type of entry that it represents (e.g. vnode, pipe, socket, etc.). Multiple file globs can point to the same thing (in this case, you are caring about vnodes). The vnode points to the v_data, which represents the in core data necessary to access a vnode object - usually, a filesystem object ; there is *usually* a 1:1 correspondence between vnode and per-FS instance object; in the case of HFS, this would be a cnode structure, or for UFS, an inode structure. So basically, you have two places in the chain you want to back-track where the OS doesn't store a list of "who all points to me?". You're correct that this *could* be maintained by the OS, but you're *wrong* when you say "I hardly think that support could be blamed for any significant slowdown". The problem is that in order to maintain these lists, you would need to allocate list element structures in both cases (this is doable - it's just a memory penalty); however, when you went to insert and remove elements from these lists, you'd have to enforce a serialization barrier on list insertion, deletion, lookup, uniquification, etc., etc.. Pre-protected-mode Mac OS X would handle this by duplication of data and/or hlock()/hunlock() - serializing either data validity or serializing access. This isn't really expensive on a non-preemptive multitasking system where you don't have protection domain crossing or address space switching, and for which you only have a single CPU that you're stalling out until the operation completes. But when you start talking about modern machines and modern OS's that are inherently more safe vs. viruses, etc., then you are starting to add up to some real performance penalties. So far though, I can't think of anything that involves tracking the process to which a thread belongs in what I've outlined above. You aren't making an assumption about v_owner, are you? Looking at the sources, v_owner is either null or it's current_thread(), but I guess that can change as a file is accessed, so that won't be reliable at all. Modulo bugs in the code, it is completely reliable. It's just not what you thought it was. I mean, it's not reliable as an indicator of which process is keeping a volume busy, my end goal. If this is your goal, you need to reconsider the information you think you need in order to accomplish it. In this case, you have a volume that's being held open by (presumably) a small number of vnode references, and you want to know where they are coming from. You can do this the slow way, which is to walk everything, or you can do this the fast way. The primary reason lspf is slow in this case is that it displays all the information, and in obtaining this information, it bushes all the data, as individual data items, across the user/kernel protection domain boundary. So you are basically spending all your time in TLB shootdown, flushing, address space crossing, and copying data that not interesting for the problem you are trying to solve. What you likely want to do is make yourself a KEXT that needs to be recompiled vs. each instance of the kernel, so that if anything changes, the promiscuous knowledge you are using to walk the data structures (i.e. "the data structure has such-and-such a layout", "the pointer to such and such a list starts here", "this list is a STAILQ vs. a TAILQ or an SLIST", etc., etc. -- all the implementation we won't promise won't change between software updates) is valid for the kernel you load the thing into. Then you ask your KEXT to send you only the information you want: you iterate the vnode list off the mount point using the locking-of-the- day that happens to be implemented in a particular version of the OS, and get together a list of vp's keeping the volume open. The next part, you are going to want to take in two passes; the first is mandatory, the second, optional: First pass, you iterate the proclist, and iterate the open file table for each proc, and look in the fg_data pointer for the vp's you are interested in. You copy this out all at once. Second pass (if the first pass turns nothing up, or you are being pedantic, even though you know you can't close the volume with the vnodes held by the first pass), you go through the vnode object mappings for all the processes, and look to see if one of the vm objects associated with the process is associated with the vnode pager, and if so, if the backing object for the pager happens to be one of the vnodes you are interested in. The benefits to doing it this way should be obvious from the above, but I'll spell them out: (1) The information from lsof is a snapshot; going at it this way, you can get real data; byt the time you display it, it'll also be a snapshot, but it will be a *consistent* snapshot (2) The information doesn't have to have multiple boundary transitions to get one piece of data (I think lsof is up in the neighborhood of 7 boundary crossing per vnode backed file to display anything, not including the display code) (4) You are order N*M/2, rather than order N * M * K, where K is large, because you iterate only for the vnodes you care about, instead of all of them. (5) You avoid all that copying of data, TLB mapping, shodown, buffer flushing, etc.. The down side is that you have to recompile your KEXT each time an sU happens, but if you are traking a bug in FS code you wrote yourself, this should be no big deal. All I want to so is add some very useful functionality that existed in the pre-Mac OS X Mac: the ability to tell who's got a volume open when you try to unmount it via the Finder. I can't actually fix the Finder, but I can come close with a contextual menu plugin. The only mechanism to determine this is lsof, which is slow and unreliable (it does not detect files opened by the Kernel). I was hoping to find another way. Actually, no. If you wanted to do this, you could simply write an fsevents listener, and remember who did what open, keeping a count on the open and closes, removing records in your list when the open cout for a given process goes to 0. If you wanted to do this via a KEXT, and query it for the information, that's really easy, too, by using a KAUTH listener for open and close events. I'd be willing to experiment with adding support to the Kernel & BSD to keeping track of these things as files are opened and closed (as I said above, I don't agree with your assertion that this needs to have any significant impact on performance). If you want to do this for your own use, that's fine, but the performance penalties on a heavily loaded system could be immense (see above). This email sent to site_archiver@lists.apple.com