linux-kernel - Re: backing up ext4 fs, system unresponsive, thrashing like crazy even though swap is unused

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <alpine.LFD.2.02.1212071720590.1646@soupermouf>
Date:	Fri, 7 Dec 2012 17:26:27 +0200 (EET)
From:	Dimitrios Apostolou <jimis@....net>
To:	Jan Kara <jack@...e.cz>
cc:	linux-kernel@...r.kernel.org,
	Roland Eggner <edvx1@...temanalysen.net>,
	Catalin Marinas <catalin.marinas@....com>,
	Theodore Ts'o <tytso@....edu>
Subject: Re: backing up ext4 fs, system unresponsive, thrashing like crazy
 even though swap is unused

Hi Jan, thanks for your help, with this commit I can't reproduce the 
problem. The problematic workload is no more inflating the 
ext4_inode_cache, in fact I've been able to run even heavier workloads 
with the ext4_inode_cache never surpassing 2-4MB.

Thanks everyone for helping,
Dimitris


On Thu, 6 Dec 2012, Jan Kara wrote:
> On Thu 06-12-12 17:15:37, Dimitrios Apostolou wrote:
>> On Thu, 6 Dec 2012, Jan Kara wrote:
>>> On Sun 25-11-12 21:30:00, Dimitrios Apostolou wrote:
>>>> On Sun, 2012-11-25 at 15:55 +0200, Dimitrios Apostolou wrote:
>>>>> on an old PIII-500MHz laptop, 128MB RAM, kernel 3.6.6, I started a
>>>>> backup process (tar|xz -4, nice'd and ionice'd -c3) from ext4 on local
>>>>> ATA disk to ext3 on external USB disk (USB-2.0 port on PCMCIA card).
>>>>> Even though earlier system load was minimal, free memory was plenty, the
>>>>> system now is unresponsive and is thrashing the disk, but the swapfile
>>>>> is rarely touched.
>>>>
>>>> I'm now having the same experience even though I replaced xz (which
>>>> needed ~50MB RAM) with gzip. Even though I feel the realtime root shell
>>>> is a bit more responsive than before, the OOM killer is out killing
>>>> small processes like syslog-ng and systemd-logind... The
>>>> ext4_inode_cache slab is taking almost all my memory (117MB). Please
>>>> advise!
>>> Hmm, it seems commit 4eff96dd5283a102e0c1cac95247090be74a38ed might be
>>> interesting for you. It landed in -stable kernels recently as well if I
>>> remember right...
>>
>> Thanks, I appreciate your help as I'm stuck in a dead end now, and
>> I've been trying to write some debug hook that prints all
>> ext4_inodes and the reason they are pinned (is there an easy way to
>> find this out?).
>>
>> So maybe there is a typo in the SHA1 sum you provided? Gitweb can't
>> find it in Linus' tree.
>  Strange. You are right gitweb doesn't show the SHA1 but I can see it in
> my git repo I pulled from Linus. Anyway, I've attached the fix for your
> convenience.
>
> 								Honza
>
> -- 
> Jan Kara <jack@...e.cz>
> SUSE Labs, CR
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/