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@xxxxxxxxxxxxx> > >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 _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
