[lkml]   [2008]   [Oct]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: possible (ext4 related?) memory leak in kernel 2.6.26
On Sun, Oct 05, 2008 at 08:27:52AM -0400, Theodore Tso wrote:
> > In both cases it freezes solid the machine for more than a minute or so, and
> > it overflows the dmesg with messages.
> Can you check and see if you got more of the messages recorded in
> /var/log/messages? Once you do, can you take the block numbers, and
> pull them out into a single command file to feed to debugfs.

Unfortunately, there are no more messages in the syslog than in the dmesg.

> Take the column of block numbers, and tack on "icheck " at the
> beginning, like so:
> icheck 35491 35493 35494 35496 35497 35498 35499 35501 ...
> You can put a thousand or so block numbers on each line; then it's
> probably better to start a new line with "icheck " at the beginning.
> Then take that script and run it through debugfs:
> debugfs /dev/XXX < > icheck.out
> That will result in a file icheck.out that looks like this:
> debugfs: icheck 33347
> Block Inode number
> 33347 8193
> 33348 8193
> 33350 8196
> 33351 8197
> ...
> Now you'll need to take the inode numbers returned in icheck.out, and
> create another file called that will take the inode numbers
> and turn them into pathnames. (I find that using emacs's
> kill-rectangle command very handy for doing this sort of thing, but
> other people will like to use awk, and I'm sure there's some way to do
> this using vi but I don't know what it is. :-) It's also a good idea
> to take the inode numbers and run them through "sort -u" to get rid of
> duplicates before putting them on a single line and adding ncheck to
> them. So what you want is to create a file that looks like this:
> ncheck 8193 8196 8197 ....
> ... and then feed that to debugfs again:
> debugfs /dev/XXX < > ncheck.out
> That will produce a file that looks like this:
> debugfs: ncheck 8193
> Inode Pathname
> 8193 /ext4
> ...
> The next thing I'd ask you to do is to look at the pathnames and
> eyeball them; are they all directories? Files? Files that you have
> modified earlier? If you're not sure, you can look at a particular
> inode either by giving its pathname:
> debugfs: stat /ext4
> or by its inode number, in angle brackets:
> debugfs: stat <8193>
> What I'm trying to do here is to get a pattern of what might be going
> on. I'm assuming that your filesystem is too big (and probably
> contains private information) for you to send it to me. (Although if
> you're willing to send me a compressed raw e2image --- see the "RAW
> IMAGE FILES" section of the e2image man page ---- and the portions of
> the buffer information dummped in /var/log/messages, I can try to do
> some of the analysis for you.)

For the two fs the only inode which shows up is the inode 8 (this seems to
be the journal. According to 'stat <8>' in debugfs it looks like the journal is 134Megs long. I don't remember exactly how I created the fs, but i'm sure I did not specified the journal size. Does it seem reasonable for a 6,6G fs?

However seeing only the journal inode could be because I only had the last
300 blocks left in the dmesg. A small number of them did not belong to any

Should I reboot with a very big ring buffer?

 \ /
  Last update: 2008-10-05 18:21    [W:0.043 / U:2.136 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site