Date: Mon, 6 Mar 95 10:26:44 MST From: terry@cs.weber.edu (Terry Lambert) To: phk@ref.tfs.com (Poul-Henning Kamp) Cc: davidg@Root.COM, jhay@mikom.csir.co.za, current@FreeBSD.org Subject: Re: "Text file busy" with program not running anymore? Message-ID: <9503061726.AA18398@cs.weber.edu> In-Reply-To: <199503051820.KAA18600@ref.tfs.com> from "Poul-Henning Kamp" at Mar 5, 95 10:20:56 am
next in thread | previous in thread | raw e-mail | index | archive | help
> > >I am running FreeBSD-current with a kernel of this morning, if this > > >is relevant. I have compiled a program, copied it with cp to another > > >directory and executed it from there. Then I changed the source, > > >compiled it again and when I tried to copy it, I got the > > >"cp: /users/jhay/bin/u2d: Text file busy" message. But the program > > >is not running anymore. I have waited a few minutes, thinking that > > >there is some cache that have to timeout, but it did not help. > > > > > >Now it isn't the end of the world for me, I can just delete the > > >file before I copy the new one or use install. > > > > > >I would just like to know if this is expected behaviour or not? > > > > It is expected. Whenever a file is executed, the VTEXT flag is > > set on the vnode to indicate that someone is executing it. The > > flag remains set until there are no references to it and it is no > > longer cached. In your case, it lingered in the cache. It never > > 'times out' - the cached vnodes are replaced with other cached > > vnodes - so it will only get out of the cache if there is > > activity on the system to flush it out. > > It's conceivable that there could be a count instead of a flag > > ...but this complicates things quite a bit and I don't see the > > point in it. Just rm the file first. > > Wouldn't the right thing be to flush it if it is opened for write ? The main problem is that the cache is crap. It's the cache reference that is screwing you. This is because the cache reference counts as a reference. The point of having a v_count is to count the number of holds vs. opens on the vnode. In general, the cache should be by vnode rather than by inode, and there should be a seperate "last chance cache" for inodes. The "allocate inodes with no buffers attached" is probably an OK optimization, but it's not nearly the win that it used to be prior to the VM and buffer cache merge. I would truly be suprised that *BSD would not get the same thrashing that SVR4 get now -- the working set soloution to avoid the type of cache-trashing that ld in SVR4 does when it mmap's the object files to be linked is only a partial fix. The real fix involves an arbitrated LRU list insertion order based on giving two quality levels so that an LRU'ed buffer resulting from working set overflow gets inserted at the list head for immediate reuse instead of the list tail. A second insertion point based on hit/miss and page dirty in the center of the list must also be maintained: ,--------------------.------------------. | | | `------------------<-' | | | `----------------------------------<----' The result is, effectively, a directed acyclic graph based on LRU. I think another missing piece is the buffer reclaim on LRU'ed but not flushed buffers. What really needs to happen here is that a second-chance cache based on inode rather than directory name space needs to be maintained. This is needed anyway, since the directory entry cache limits the number of characters in an insertable name. The distinction between open vs. cache insertion (testable with a cache lookup, if nothing else) then allows you to unset VTEXT on last open reference instead of last absolute reference. Terry Lambert terry@cs.weber.edu --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9503061726.AA18398>