[lkml]   [2001]   [Mar]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Memory leak in the ramfs file system
On Mon, 12 Jun 2000, Jaswinder Singh wrote:
> > What does /proc/slabinfo say? The most likely leak is a dentry leak or
> > an inode leak, and both of those should be fairly easy to see in the
> > slab info (dentry_cache and inode_cache respectively).
> >
> I am attaching details before and during my application .
> Mainly changes are in dentry_cache and inode_cache , but i am attaching
> whole /proc/slabinfo for your reference.

Would it be possible for you to attached a 'before' picture of slabinfo,
as well as 'after'?

> > Obviously, it could be a data page leak too, but such a leak should be
> > easy to see by creating a few big files and deleting them..
> >
> > Linus
> I am also facing one more problem with ramfs.
> du and df shows 0 , so i am also attaching its output.

I don't recall how du works exactly... if it uses stat(2), it should not
be broken AFAIK.

As for 'df', that will definitely show zero, because ramfs does not do
filesystem accounting in its present form. You might consider trying a
modified version of ramfs, as found in Alan Cox's 'ac' patchkit. This
patchkit includes a modified ramfs which supports limiting filesystem
size, but more importantly (for you), it should make 'df' work again.


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:20    [W:0.113 / U:0.384 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site