Subject: Re: port-i386/500: file system space is lost
To: None <firstname.lastname@example.org>
From: der Mouse <mouse@Collatz.McRCIM.McGill.EDU>
Date: 09/30/1994 13:08:40
> Subject: Re: port-i386/500: file system space is lost
As one would expect from pk's message, this is not i386-specific, or at
least, it happens on the SPARC port too. (It seemed so weird I went
and tried it.)
>> When the program below is run 1M of file system space is
>> lost, despite the created file being unlink()ed.
> The VM object created by mmap(2) lingers in the vm object cache and
> holds on to the vnode associated with it. You'll get your file
> system space back as soon as it gets pushed out of the cache again,
> ie. after you've mmap(2)ed enough other things.
In my experimentation, I found another way to force it out of the
cache: unmount the filesystem the vnode lives on.
Why is it sticking around even after there's no longer any way for it
to be referred to? The underlying vnode has no links and no file
descriptors pointing to it, and no process has the memory mapped...or
is it a case of the left hand not knowing what the right is doing? The
vnode sticks around because it has a reference from the vm object, and
the vm object thinks it's accessible from the vnode? In that case, how
does umount() manage to flush it?
On the other hand, I really don't know this cache code, so I could be
babbling nonsense. Please feel free to ignore me if so. :-)