Hi all,
this looks like a serious problem to be fixed before 2.6.18 final and
backported to 2.6.17.*. Or a case of me misunderstanding something, in
which case, please, let me know.
I've reported before in thread "[2.6.17.4] slabinfo.buffer_head increases"
a memory leak in ext3. Today I verified it is still present in 2.6.18-rc6.
A short description: as long as write accesses are made on an ext3
filesystem /proc/slabinfo buffer_head increases unboundedly. This
behaviour is not observed with another journalling filesystems (e.g.,
reiserfs), or if ext3 is mounted as ext2.
As it seems serious enough to me I'm sending it to ext3 maintainers.
Thanks
Guennadi
---------------------------------
Guennadi Liakhovetski, Ph.D.
DSA Daten- und Systemtechnik GmbH
Pascalstr. 28
D-52076 Aachen
Germany
On Thursday 07 September 2006 07:10, Guennadi Liakhovetski wrote:
>Hi all,
>
>this looks like a serious problem to be fixed before 2.6.18 final and
>backported to 2.6.17.*. Or a case of me misunderstanding something, in
>which case, please, let me know.
>
>I've reported before in thread "[2.6.17.4] slabinfo.buffer_head
> increases" a memory leak in ext3. Today I verified it is still present
> in 2.6.18-rc6.
>
>A short description: as long as write accesses are made on an ext3
>filesystem /proc/slabinfo buffer_head increases unboundedly. This
>behaviour is not observed with another journalling filesystems (e.g.,
>reiserfs), or if ext3 is mounted as ext2.
>
What would you call the 'get excited' level? Here, with about 12 hours of
uptime (I had an unlogged machine shutdown while I was offsite yesterday),
I'm showing
buffer_head 67158 67158 48 78 1 : tunables 120 60
0 : slabdata 861 861 0
There are other entries that are larger here. However I do note that its
growing on a per cycle basis as fetchmail is doing its thing every 90
seconds. Now its
buffer_head 67672 67704 48 78 1 : tunables 120 60
0 : slabdata 868 868 0
So perhaps thats why it did the shutdown? With absolutely zip in the logs?
Although, my firewall box was also reset/rebooted about the same time as
this ones powerdown according to an uptime report on it just now, so my
ups must not be doing its thing correctly.
>As it seems serious enough to me I'm sending it to ext3 maintainers.
>
>Thanks
>Guennadi
>---------------------------------
>Guennadi Liakhovetski, Ph.D.
>DSA Daten- und Systemtechnik GmbH
>Pascalstr. 28
>D-52076 Aachen
>Germany
>-
>To unsubscribe from this list: send the line "unsubscribe linux-kernel"
> in the body of a message to [email protected]
>More majordomo info at http://vger.kernel.org/majordomo-info.html
>Please read the FAQ at http://www.tux.org/lkml/
--
Cheers, Gene
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Yahoo.com and AOL/TW attorneys please note, additions to the above
message by Gene Heskett are:
Copyright 2006 by Maurice Eugene Heskett, all rights reserved.
On Thu, 7 Sep 2006, Guennadi Liakhovetski wrote:
> I've reported before in thread "[2.6.17.4] slabinfo.buffer_head increases" a
> memory leak in ext3. Today I verified it is still present in 2.6.18-rc6.
No, sorry, I cannot seem to reproduce it under -rc6. It seems to stabilize
eventually. But it doesn't under -rc2. I looked through all commits to
ext3 code between -rc2 and -rc6 and I don't see any obvious reasons why a
memory leak may have been fixed. Unless somebody can sched some light on
this, I'll try to upgrade the problematic system to -rc6 tomorrow.
Just to be quite sure - this cannot (or is very unlikely to) be a libc
bug, right?
Thanks
Guennadi
---------------------------------
Guennadi Liakhovetski, Ph.D.
DSA Daten- und Systemtechnik GmbH
Pascalstr. 28
D-52076 Aachen
Germany
On Thursday 07 September 2006 11:21, Guennadi Liakhovetski wrote:
>On Thu, 7 Sep 2006, Guennadi Liakhovetski wrote:
>> I've reported before in thread "[2.6.17.4] slabinfo.buffer_head
>> increases" a memory leak in ext3. Today I verified it is still present
>> in 2.6.18-rc6.
>
>No, sorry, I cannot seem to reproduce it under -rc6. It seems to
> stabilize eventually. But it doesn't under -rc2. I looked through all
> commits to ext3 code between -rc2 and -rc6 and I don't see any obvious
> reasons why a memory leak may have been fixed. Unless somebody can sched
> some light on this, I'll try to upgrade the problematic system to -rc6
> tomorrow.
>
I just had to restart x because I was playing with keyboard layouts, trying
to get the alt keys to properly type the 3rd level chars and screwing it
all up, and when I had done the restart, that line in slabinfo was
somewhat reset:
[root@coyote root]# grep buffer_head /proc/slabinfo
buffer_head 46789 78858 48 78 1 : tunables 120 60
0 : slabdata 1011 1011 0
And frankly I don't know enough about it to state it as a fact. Time will
tell though.
>Just to be quite sure - this cannot (or is very unlikely to) be a libc
>bug, right?
>
>Thanks
>Guennadi
>---------------------------------
>Guennadi Liakhovetski, Ph.D.
>DSA Daten- und Systemtechnik GmbH
>Pascalstr. 28
>D-52076 Aachen
>Germany
>-
>To unsubscribe from this list: send the line "unsubscribe linux-kernel"
> in the body of a message to [email protected]
>More majordomo info at http://vger.kernel.org/majordomo-info.html
>Please read the FAQ at http://www.tux.org/lkml/
--
Cheers, Gene
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Yahoo.com and AOL/TW attorneys please note, additions to the above
message by Gene Heskett are:
Copyright 2006 by Maurice Eugene Heskett, all rights reserved.
On Thu, 7 Sep 2006 17:21:35 +0200 (CEST)
Guennadi Liakhovetski <[email protected]> wrote:
> On Thu, 7 Sep 2006, Guennadi Liakhovetski wrote:
>
> > I've reported before in thread "[2.6.17.4] slabinfo.buffer_head increases" a
> > memory leak in ext3. Today I verified it is still present in 2.6.18-rc6.
>
> No, sorry, I cannot seem to reproduce it under -rc6. It seems to stabilize
> eventually. But it doesn't under -rc2. I looked through all commits to
> ext3 code between -rc2 and -rc6 and I don't see any obvious reasons why a
> memory leak may have been fixed. Unless somebody can sched some light on
> this, I'll try to upgrade the problematic system to -rc6 tomorrow.
>
> Just to be quite sure - this cannot (or is very unlikely to) be a libc
> bug, right?
>
It is expected that in this situation the number of buffer_head objects will
be approximately equal to the number of pagecache pages. So once the pagecache
has grown to consume all available memory and the kernel starts to perform pagecache
reclaim, the buffer_head count should stabilise.
On Thu, 7 Sep 2006, Andrew Morton wrote:
> It is expected that in this situation the number of buffer_head objects will
> be approximately equal to the number of pagecache pages. So once the pagecache
> has grown to consume all available memory and the kernel starts to perform pagecache
> reclaim, the buffer_head count should stabilise.
Ok, thanks that's exactly what I had to know - makes sense now.
Sorry for a false alarm.
Thanks
Guennadi
---------------------------------
Guennadi Liakhovetski, Ph.D.
DSA Daten- und Systemtechnik GmbH
Pascalstr. 28
D-52076 Aachen
Germany