From mboxrd@z Thu Jan  1 00:00:00 1970
From: Andrew Morton <akpm@osdl.org>
Subject: Re: [PATCH] Prevent large file writeback starvation
Date: Mon, 6 Feb 2006 12:11:33 -0800
Message-ID: <20060206121133.4ef589af.akpm@osdl.org>
References: <20060206040027.GI43335175@melbourne.sgi.com>
	<20060205202733.48a02dbe.akpm@osdl.org>
	<43E75ED4.809@rtr.ca>
	<43E75FB6.2040203@rtr.ca>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Cc: dgc@sgi.com, linux-kernel@vger.kernel.org,
	linux-fsdevel@vger.kernel.org
Return-path: <linux-kernel-owner+glk-linux-kernel-3=40m.gmane.org-S932369AbWBFUMD@vger.kernel.org>
To: Mark Lord <lkml@rtr.ca>
In-Reply-To: <43E75FB6.2040203@rtr.ca>
Sender: linux-kernel-owner@vger.kernel.org
List-Id: linux-fsdevel.vger.kernel.org

Mark Lord <lkml@rtr.ca> wrote:
>
> A simple test I do for this:
> 
>  $ mkdir t
>  $ cp /usr/src/*.bz2  t    (about 400-500MB worth of kernel tar files)
> 
>  In another window, I do this:
> 
>  $ while (sleep 1); do echo -n "`date`: "; grep Dirty /proc/meminfo; done
> 
>  And then watch the count get large, but take virtually forever
>  to count back down to a "safe" value.
> 
>  Typing "sync" causes all the Dirty pages to immediately be flushed to disk,
>  as expected.

I've never seen that happen and I don't recall seeing any other reports of
it, so your machine must be doing something peculiar.  I think it can
happen if, say, an inode gets itself onto the wrong inode list, or
incorrectly gets its dirty flag cleared.

Are you using any unusual mount options, or unusual combinations of
filesystems, or anything like that?