[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20121005175139.GC831@schottelius.org>
Date: Fri, 5 Oct 2012 19:51:39 +0200
From: Nico Schottelius <nico-kernel20120920@...ottelius.org>
To: Valdis.Kletnieks@...edu
Cc: Nico Schottelius <nico-kernel20120920@...ottelius.org>,
David Rientjes <rientjes@...gle.com>,
Arend van Spriel <arend@...adcom.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"linux-wireless@...r.kernel.org" <linux-wireless@...r.kernel.org>,
Dave Kleikamp <shaggy@...nel.org>,
jfs-discussion@...ts.sourceforge.net
Subject: Re: Out of memory on 3.5 kernels
Hey Valdis,
Valdis.Kletnieks@...edu [Fri, Oct 05, 2012 at 11:48:04AM -0400]:
> On Wed, 03 Oct 2012 23:23:11 +0200, Nico Schottelius said:
>
> > does anyone of you have a clue so far what may be causing the huge
> > slab usage?
> >
> > I've just found an interesting detail: umounting and cryptsetup
> > luksClosing frees up the used memory (not sure which one was freeing
> > up)
>
> For what it's worth, I'm seeing a similar problem in linux-next on my laptop -
> trying to run a backup to an external hard drive that has a LUKS partition on
> it will OOM. (For some reason having the external LUKS partition is much more
> problematic than the LVM-on-LUKS on the internal drive)
Indeed, I also have the internal drive encrypted with LUKS, also jfs
on it, but the problem only occurs on the external drive.
Is there the possibility that the JFS on the external drive got into a
state that may caus JFS to behave unexpected? If this is true, it would
explain why it happens only with the external drive and also accross
kernel versions.
But "good" to hear I am not the only one affected anymore.
Cheers,
Nico
--
PGP key: 7ED9 F7D3 6B10 81D7 0EC5 5C09 D7DC C8E4 3187 7DF0
Content of type "application/pgp-signature" skipped
Powered by blists - more mailing lists