Re: 2.4.23 + tmpfs: where's my mem?!

From: Måns Rullgård
Date: Thu Dec 11 2003 - 09:25:48 EST


Hugh Dickins <hugh@xxxxxxxxxxx> writes:

> On Thu, 11 Dec 2003, Willy Tarreau wrote:
>
>> On Thu, Dec 11, 2003 at 10:54:28AM -0200, dual_bereta_r0x wrote:
>> > root@hquest:/tmp# cat /etc/slackware-version
>> > Slackware 9.1.0
>> > root@hquest:/tmp# uname -a
>> > Linux hquest 2.4.23 #6 Sat Nov 29 22:47:03 PST 2003 i686 unknown unknown
>> > GNU/Linux
>> > root@hquest:/tmp# df /tmp
>> > Filesystem 1K-blocks Used Available Use% Mounted on
>> > tmpfs 124024 112388 11636 91% /tmp
>> > root@hquest:/tmp# du -s .
>> > 32 .
>> > root@hquest:/tmp# _
>>
>> maybe you have a process which creates a temporary file in /tmp, and deletes
>> the entry while keeping the fd open. vmware 1.2 did that, and probably more
>> recent ones still do. It's a very clever way to automatically remove temp
>> files when the process terminates.
>
> That's right, and would explain why du may show 32 even if ls -alR
> shows nothing at all (what does ls -alR /tmp show?).
>
> But the strange thing is that df's Used does not match du: they should
> be identical, though arrived at from different directions. I've not
> seen that, and have no idea what's going on: it's as if a subtree of
> /tmp has become detached (a non-empty directory removed).

FWIW, I've seen this behavior with vmware 4. The space came back when
I closed vmware.

--
Måns Rullgård
mru@xxxxxx

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/