Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1759389Ab1D1Lgg (ORCPT ); Thu, 28 Apr 2011 07:36:36 -0400 Received: from mail-ww0-f44.google.com ([74.125.82.44]:33407 "EHLO mail-ww0-f44.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755149Ab1D1Lgf (ORCPT ); Thu, 28 Apr 2011 07:36:35 -0400 DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:from:reply-to:to:cc:in-reply-to:references:content-type :organization:date:message-id:mime-version:x-mailer :content-transfer-encoding; b=lZoWu1b90s8euT3HTyMqxmURq1O2/kb/Pds+c1L3uO//p5pg/VAy0f8nIKw0+ZTr3j qXoquL2n4JhvWy3TqHq6gdQSgQqhQtF61M0PuqxhH0SFP+Coe9Zt4S4FiDn4raVOzEyL l3uCHah5LNxBUGXZFP+uBII9UR/4Q9obh7RUM= Subject: Re: [BUG] fatal hang untarring 90GB file, possibly writeback related. From: Colin Ian King Reply-To: colin.king@canonical.com To: James Bottomley Cc: Chris Mason , linux-fsdevel , linux-mm , linux-kernel , linux-ext4 In-Reply-To: <1303934716.2583.22.camel@mulgrave.site> References: <1303920553.2583.7.camel@mulgrave.site> <1303921583-sup-4021@think> <1303923000.2583.8.camel@mulgrave.site> <1303923177-sup-2603@think> <1303924902.2583.13.camel@mulgrave.site> <1303925374-sup-7968@think> <1303926637.2583.17.camel@mulgrave.site> <1303934716.2583.22.camel@mulgrave.site> Content-Type: text/plain; charset="UTF-8" Organization: Canonical Date: Thu, 28 Apr 2011 12:36:30 +0100 Message-ID: <1303990590.2081.9.camel@lenovo> Mime-Version: 1.0 X-Mailer: Evolution 2.30.3 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1372 Lines: 33 One more data point to add, I've been looking at an identical issue when copying large amounts of data. I bisected this - and the lockups occur with commit 3e7d344970673c5334cf7b5bb27c8c0942b06126 - before that I don't see the issue. With this commit, my file copy test locks up after ~8-10 iterations, before this commit I can copy > 100 times and don't see the lockup. On Wed, 2011-04-27 at 15:05 -0500, James Bottomley wrote: > On Wed, 2011-04-27 at 12:50 -0500, James Bottomley wrote: > > To test the theory, Chris asked me to try with data=ordered. > > Unfortunately, the deadlock still shows up. This is what I get. > > As another data point: I'm trying the same kernel with CONFIG_PREEMPT > enabled. This time the deadlock doesn't happen. Instead, kswapd0 gets > pegged at 99% CPU for much of the untar, but it does eventually > complete. > > James > > > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/