LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Ferenc Wagner <wferi@niif.hu>
To: David Chinner <dgc@sgi.com>
Cc: linux-kernel@vger.kernel.org, wferi@niif.hu
Subject: Re: inode leak in 2.6.24?
Date: Tue, 19 Feb 2008 01:50:14 +0100	[thread overview]
Message-ID: <871w79hird.fsf@szonett.ki.iif.hu> (raw)
In-Reply-To: <20080218215344.GM155407@sgi.com> (David Chinner's message of "Tue, 19 Feb 2008 08:53:44 +1100")

David Chinner <dgc@sgi.com> writes:

> On Sat, Feb 16, 2008 at 12:18:58AM +0100, Ferenc Wagner wrote:
> 
>> 5 days ago I pulled the git tree (HEAD was
>> 25f666300625d894ebe04bac2b4b3aadb907c861), added two minor patches
>> (the vmsplice fix and the GFS1 exports), compiled and booted the
>> kernel.  Things are working OK, but I noticed that inode usage has
>> been steadily rising since then (see attached graph, unless lost in
>> transit).  The real filesystems used by the machine are XFS.  I wonder
>> if it may be some kind of bug and if yes, whether it has been fixed
>> already.  Feel free to ask for any missing information.
>
> Output of /proc/slabinfo, please. If you could get a sample when the
> machine has just booted, one at the typical post-boot steady state
> as well as one after it has increased well past normal, it would
> help identify what type of inode is increasing differently.

Ugh.  Your message came just a little bit too late, I rebooted the
machine a couple of hours ago for applying an IPv6 patch, without
saving /proc/slabinfo.  The currently running kernel is 2.6.24.2 +
GFS1 exports + IPv6 fix, and I snapshotted /proc/slabinfo approx. 3
hours after reboot.  At least we will see whether this version also
produces the problem, it isn't too different after all (for some
"too").

Btw. there was no steady-state with the previous kernel, the increase
started right after reboot, which means that by tomorrow I'll be able
to tell whether it's increasing again or this kernel doesn't exhibit
such effect.

> Also, can you tell us what metrics you are graphing (i.e. where
> in /proc or /sys you are getting them from)?

I wonder why I assumed everybody knows Munin's graphs by heart...
In short: "inode table size" is the first value from
/proc/sys/fs/inode-nr; "open inodes" is the same minus the second
value.  In other words:

awk '{print "used.value " $1-$2 "\nmax.value " $1}' < /proc/sys/fs/inode-nr

I'll come back shortly with the new findings.  If nothing turns up,
it's possible to boot up the previous kernel (or -- if needed --
current git) with this IPv6 fix added and check that again.
-- 
Thanks,
Feri.

  reply	other threads:[~2008-02-19  0:50 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-02-15 23:18 Ferenc Wagner
2008-02-18 21:53 ` David Chinner
2008-02-19  0:50   ` Ferenc Wagner [this message]
2008-02-19 16:57   ` Ferenc Wagner
2008-02-20  1:04     ` David Chinner
2008-02-20 14:36       ` Ferenc Wagner
2008-02-20 21:15         ` David Chinner
2008-03-01 15:25           ` Ferenc Wagner

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=871w79hird.fsf@szonett.ki.iif.hu \
    --to=wferi@niif.hu \
    --cc=dgc@sgi.com \
    --cc=linux-kernel@vger.kernel.org \
    --subject='Re: inode leak in 2.6.24?' \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).