2.4.23 + tmpfs: where's my mem?!

2.4.23 + tmpfs: where's my mem?!

[dual_bereta_r0x]

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

Slackware-current install, stock kernel.

More info on demand, c/c me please. TIA.

-- 
dual_bereta_r0x -- Alexandre Hautequest
ArenaNetwork Lan House & Cyber -- www.arenanetwork.com.br

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

[Willy Tarreau]

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.

Cheers,
Willy

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

[Hugh Dickins]

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

What usage led up to this?  What does /proc/meminfo show?
How many records out does "dd if=/dev/zero of=/tmp/zero bs=1k"
manage before /tmp fills up (11620 would fit df's Available,
the remaining 16k being metadata).

Hugh

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

[Måns Rullgård]

Hugh Dickins <hugh@veritas.com> 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@kth.se

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

[Mario 'BitKoenig' Holbe]

Måns Rullgård <mru@kth.se> wrote:
> Hugh Dickins <hugh@veritas.com> writes:
>> 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

No, they are not identical and should not be.

Unlike df, which reads the used counter from the filesystem
meta information, du iterates over files within directories.

If you have a file without a name (created, still open, all
links removed), it does not exist in any directory but it
does exist in the filesystem. So df should show the space
used for it, while du should not.

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

This is, what Willy Tarreau described.


regards,
   Mario
-- 
Ho ho ho! I am Santa Claus of Borg. Nice assimilation all together!

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

[William Stearns]

Good morning, Alexandre,

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.

	Agreed - very likely.  User-Mode Linux does the same for its UML 
memory images.
	To see what process is doing this, try looking at:

ls -Al /proc/[0-9]*/fd/* | grep ' /tmp/'

	Which will show you all open files in /tmp, deleted or not.

lr-x------    1 wstearns wstearns       64 Dec 11 10:23 /proc/10370/fd/6 -> /tmp/sfs8eEBBc (deleted)

	The pid following /proc/ (10370 in this case) is the process 
holding this file open.
	Cheers,
	- Bill

---------------------------------------------------------------------------
	"Any sufficiently advanced technology is indistinguishable from
magic." 
	-- Arthur C. Clark (?)
--------------------------------------------------------------------------
William Stearns (wstearns@pobox.com).  Mason, Buildkernel, freedups, p0f,
rsync-backup, ssh-keyinstall, dns-check, more at:   http://www.stearns.org
Linux articles at:                         http://www.opensourcedigest.com
--------------------------------------------------------------------------

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

[Hugh Dickins]

On Thu, 11 Dec 2003, Mario 'BitKoenig' Holbe wrote:
> > Hugh Dickins <hugh@veritas.com> writes:
> >> 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
> 
> No, they are not identical and should not be.
> 
> Unlike df, which reads the used counter from the filesystem
> meta information, du iterates over files within directories.
> 
> If you have a file without a name (created, still open, all
> links removed), it does not exist in any directory but it
> does exist in the filesystem. So df should show the space
> used for it, while du should not.

Yes, of course, you and Willy are right, and the only mystery is
how I could make a mystery of it while already knowing what you've
explained well here.  Thanks!

Hugh

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

[Maciej Zenczykowski]

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

Vmware creates tmp files, deletes them, but keeps them open - the space is 
used until all the file descriptors are closed.  See if lsof doesn't show 
some /tmp files which are open and large.

Cheers,
MaZe.