From: Eric Sandeen Subject: Re: [patch] fix up lock order reversal in writeback Date: Thu, 18 Nov 2010 12:24:57 -0600 Message-ID: <4CE56F79.9040807@redhat.com> References: <20101116110058.GA4298@amd> <20101116130146.GG4757@quack.suse.cz> <4CE35A6D.2040906@redhat.com> <20101117043845.GA3586@amd> <4CE362B0.6040607@redhat.com> <20101117061057.GA3989@amd> <20101118030613.GQ3290@thunk.org> <20101117192900.da859ac7.akpm@linux-foundation.org> <20101118060000.GA3509@amd> <20101117222834.2bb36ee1.akpm@linux-foundation.org> <4CE53E56.4090501@redhat.com> <20101118091053.c275e1f2.akpm@linux-foundation.org> <4CE56AA5.4030705@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Nick Piggin , "Ted Ts'o" , Jan Kara , linux-fsdevel@vger.kernel.org, linux-ext4@vger.kernel.org, linux-btrfs@vger.kernel.org To: Andrew Morton Return-path: Received: from mx1.redhat.com ([209.132.183.28]:52828 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1758570Ab0KRSZo (ORCPT ); Thu, 18 Nov 2010 13:25:44 -0500 In-Reply-To: <4CE56AA5.4030705@redhat.com> Sender: linux-ext4-owner@vger.kernel.org List-ID: On 11/18/10 12:04 PM, Eric Sandeen wrote: > On 11/18/10 11:10 AM, Andrew Morton wrote: >> On Thu, 18 Nov 2010 08:55:18 -0600 Eric Sandeen wrote: >> >>>> Can we just delete writeback_inodes_sb_nr_if_idle() and >>>> writeback_inodes_sb_if_idle()? The changelog for 17bd55d037a02 is >>>> pretty handwavy - do we know that deleting these things would make a >>>> jot of difference? >>> >>> Really? I thought it was pretty decent ;) >>> >>> Anyway, xfstests 204, "Test out ENOSPC flushing on small filesystems." >>> shows the problem clearly, IIRC. I should have included that in the >>> changelog, I suppose, sorry. >> >> Your email didn't really impart any information :( >> >> I suppose I could accidentally delete those nasty little functions in a >> drivers/parport patch then wait and see if anyone notices. >> > > Um, ok, then, to answer the question directly : > > No, please don't delete those functions, it will break ENOSPC handling > in ext4 as shown by xfstests regression test #204 ... Further - What is going on here is that with delayed allocation, ext4 takes reservations against free blocks based on the data blocks it must write out, and the worst-case metadata that the writeout may take. Getting writeback failing with ENOSPC would be bad. But then we wind up with a bunch of unflushed writes sitting on huge metadata reservations, and start hitting ENOSPC due to that worst-case reservation. After a sync we have tons of free space again, because the worst-case space reservations turned into usually best-case reality. That's what the function is used for; once we start filling up the fs, we proactively flush data to free up the worst-case metadata reservations. Dropping it will put us back in the bad situation. If there are other ideas to fix it, I'm all ears, but this worked. -Eric