Re: possible (ext4 related?) memory leak in kernel 2.6.26

[Quentin Godfroy <godfroy@clipper.ens.fr>]

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.in > 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 ncheck.in 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 ncheck.in that looks like this:
> 
> ncheck 8193 8196 8197 ....
> 
> ... and then feed that to debugfs again:
> 
> debugfs /dev/XXX  < ncheck.in  > 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
inode.

Should I reboot with a very big ring buffer?