[PATCH 04/10] xfs: implement freezing by emptying the AIL

[Ben Myers]

On Wed, Apr 18, 2012 at 08:13:55AM -0500, Mark Tinguely wrote:
> On 04/17/12 03:26, Dave Chinner wrote:
> >On Tue, Apr 17, 2012 at 02:20:23PM +1000, Dave Chinner wrote:
> >
> >commit 281627df3eb55e1b729b9bb06fff5ff112929646
> >Author: Christoph Hellwig<hch at infradead.org>
> >Date:   Tue Mar 13 08:41:05 2012 +0000
> >
> >     xfs: log file size updates at I/O completion time
> >
> >That confirms my analysis above - the problem is being exposed by new
> >code in the writeback path that does transaction allocation where it
> >didn't used to.
> >
> >Clearly the problem is not really the new code in Christoph's
> >patches - it's an existing freeze problem that has previously
> >resulted in data writes occuring after a freeze has completed (of
> >which we have had rare complaints about). That sounds pretty dire,
> >except for one thing: Jan Kara's patch set that fixes all these
> >freeze problems:
> >
> >https://lkml.org/lkml/2012/4/16/356
> >
> >And now that I've run some testing with Jan's patch series, along
> >with Christoph's and mine (75-odd patches ;), a couple of my test
> >VMs have been running test 068 in a tight loop for about half an
> >hour without a hang, so I'd consider this problem fixed by Jan's
> >freeze fixes given I could reliably hang it in 2-3 minutes before
> >adding Jan's patch set to my stack.
> >
> >So the fix for this problem is getting Jan's patch set into the
> >kernel at the same time we get the inode size logging changes into
> >the kernel. What do people think about that for a plan?
> >
> >Cheers,
> >
> >Dave.
> 
> Good job.
> 
> Jan's freeze patch set is at v5 and seems to be settling down. What
> is the status of Jan's freeze code getting into the kernel?

The trouble I was having yesterday seems to be related to the i386 box on which
I was running.  Apparently something has regressed badly since 3.3 on that
i386.  Seems to be working fine on another x86_64 machine.

-Ben