All of lore.kernel.org
 help / color / mirror / Atom feed
From: Eric Sandeen <sandeen@sandeen.net>
To: Justin Piszcz <jpiszcz@lucidpixels.com>
Cc: linux-kernel@vger.kernel.org, xfs@oss.sgi.com
Subject: Re: Kernel 2.6.30: Memory/XFS leak, OOM killer kills many processes
Date: Thu, 11 Jun 2009 12:31:48 -0500	[thread overview]
Message-ID: <4A313F84.20900@sandeen.net> (raw)
In-Reply-To: <alpine.DEB.2.00.0906111255280.6809@p34.internal.lan>

Justin Piszcz wrote:
> 
> On Thu, 11 Jun 2009, Justin Piszcz wrote:
> 
>> Hello,
>>
>> I have a daily cron that backs up my root filesystem using xfsdump, it has 
>> remain unchanged for at least 7-10 kernel versions.  When I migrated to 
>> 2.6.30, when the xfsdump ran at its scheduled time, nearly all of my 
>> processes were killed due to an OOM situation, I can reproduce the situation.
>>
>> Kernel: 2.6.30
>> Dist: Debian Testing
>> xfsdump: 2.2.48-1
> 
> Kernel 2.6.29.4 does not exhibit this problem:
> 
> xfsdump: estimated dump size: 8694781376 bytes
> xfsdump: creating dump session media file 0 (media 0, file 0)
> xfsdump: dumping ino map
> xfsdump: dumping directories
> xfsdump: dumping non-directory files
> xfsdump: ending media file
> xfsdump: media file size 8294709848 bytes
> xfsdump: dump size (non-dir files) : 8208863560 bytes
> xfsdump: dump complete: 102 seconds elapsed
> xfsdump: Dump Status: SUCCESS
> 
> XFS(?) bug in 2.6.30.

Any chance for a bisect run? :)

Or, just as a thought, watch slabtop while you run the dump?

-Eric

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

WARNING: multiple messages have this Message-ID (diff)
From: Eric Sandeen <sandeen@sandeen.net>
To: Justin Piszcz <jpiszcz@lucidpixels.com>
Cc: linux-kernel@vger.kernel.org, xfs@oss.sgi.com
Subject: Re: Kernel 2.6.30: Memory/XFS leak, OOM killer kills many processes
Date: Thu, 11 Jun 2009 12:31:48 -0500	[thread overview]
Message-ID: <4A313F84.20900@sandeen.net> (raw)
In-Reply-To: <alpine.DEB.2.00.0906111255280.6809@p34.internal.lan>

Justin Piszcz wrote:
> 
> On Thu, 11 Jun 2009, Justin Piszcz wrote:
> 
>> Hello,
>>
>> I have a daily cron that backs up my root filesystem using xfsdump, it has 
>> remain unchanged for at least 7-10 kernel versions.  When I migrated to 
>> 2.6.30, when the xfsdump ran at its scheduled time, nearly all of my 
>> processes were killed due to an OOM situation, I can reproduce the situation.
>>
>> Kernel: 2.6.30
>> Dist: Debian Testing
>> xfsdump: 2.2.48-1
> 
> Kernel 2.6.29.4 does not exhibit this problem:
> 
> xfsdump: estimated dump size: 8694781376 bytes
> xfsdump: creating dump session media file 0 (media 0, file 0)
> xfsdump: dumping ino map
> xfsdump: dumping directories
> xfsdump: dumping non-directory files
> xfsdump: ending media file
> xfsdump: media file size 8294709848 bytes
> xfsdump: dump size (non-dir files) : 8208863560 bytes
> xfsdump: dump complete: 102 seconds elapsed
> xfsdump: Dump Status: SUCCESS
> 
> XFS(?) bug in 2.6.30.

Any chance for a bisect run? :)

Or, just as a thought, watch slabtop while you run the dump?

-Eric

  reply	other threads:[~2009-06-11 17:31 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-06-11 16:15 Kernel 2.6.30: Memory/XFS leak, OOM killer kills many processes Justin Piszcz
2009-06-11 16:15 ` Justin Piszcz
2009-06-11 17:00 ` Justin Piszcz
2009-06-11 17:00   ` Justin Piszcz
2009-06-11 17:31   ` Eric Sandeen [this message]
2009-06-11 17:31     ` Eric Sandeen
2009-06-11 19:02     ` Felix Blyakher
2009-06-11 19:02       ` Felix Blyakher
2009-06-11 22:02       ` Mike Dresser
2009-06-11 22:02         ` Mike Dresser
2009-06-11 21:35     ` Felix Blyakher
2009-06-11 21:35       ` Felix Blyakher
2009-06-12  8:37       ` Justin Piszcz
2009-06-12  8:37         ` Justin Piszcz
2009-06-12  9:57         ` Michael Weissenbacher
2009-06-12  9:57           ` Michael Weissenbacher
2009-06-12 15:54         ` Felix Blyakher
2009-06-12 15:54           ` Felix Blyakher
2009-06-11 18:49 ` markus reichelt

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=4A313F84.20900@sandeen.net \
    --to=sandeen@sandeen.net \
    --cc=jpiszcz@lucidpixels.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=xfs@oss.sgi.com \
    /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
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.