All of lore.kernel.org
 help / color / mirror / Atom feed
* xfstests 065 failures
@ 2010-12-01 20:29 Alex Elder
  2010-12-02  2:21 ` Dave Chinner
  0 siblings, 1 reply; 2+ messages in thread
From: Alex Elder @ 2010-12-01 20:29 UTC (permalink / raw)
  To: dchinner; +Cc: XFS Mailing List

Dave, you were asking on IRC about test 065 failures.
I asked Bill Kendall about it and he bisected to find
that the commit below seems to be where the problems
started.  I believe the problem is that one of the
times is not updated properly when renaming the file
"addedfile4".  Here are the commands that might affect
that file in test 065:

	mv addeddir4/addedfile5 addeddir4/addedfile4
	mv addeddir4 addeddir6

I glanced at the commit and saw nothing obviously
wrong, but at the moment I can't really dig into
it any deeper so I thought I'd report what Bill
found so others could look.

					-Alex

>From dcd79a1423f64ee0184629874805c3ac40f3a2c5 Mon Sep 17 00:00:00 2001
From: Dave Chinner <dchinner@redhat.com>
Date: Tue, 28 Sep 2010 12:27:25 +1000
Subject: [PATCH] xfs: don't use vfs writeback for pure metadata
modifications

Under heavy multi-way parallel create workloads, the VFS struggles
to write back all the inodes that have been changed in age order.
The bdi flusher thread becomes CPU bound, spending 85% of it's time
in the VFS code, mostly traversing the superblock dirty inode list
to separate dirty inodes old enough to flush.

We already keep an index of all metadata changes in age order - in
the AIL - and continued log pressure will do age ordered writeback
without any extra overhead at all. If there is no pressure on the
log, the xfssyncd will periodically write back metadata in ascending
disk address offset order so will be very efficient.

Hence we can stop marking VFS inodes dirty during transaction commit
or when changing timestamps during transactions. This will keep the
inodes in the superblock dirty list to those containing data or
unlogged metadata changes.

However, the timstamp changes are slightly more complex than this -
there are a couple of places that do unlogged updates of the
timestamps, and the VFS need to be informed of these. Hence add a
new function xfs_trans_ichgtime() for transactional changes,
and leave xfs_ichgtime() for the non-transactional changes.

Signed-off-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Alex Elder <aelder@sgi.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>


_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: xfstests 065 failures
  2010-12-01 20:29 xfstests 065 failures Alex Elder
@ 2010-12-02  2:21 ` Dave Chinner
  0 siblings, 0 replies; 2+ messages in thread
From: Dave Chinner @ 2010-12-02  2:21 UTC (permalink / raw)
  To: Alex Elder; +Cc: XFS Mailing List, dchinner

On Wed, Dec 01, 2010 at 02:29:39PM -0600, Alex Elder wrote:
> Dave, you were asking on IRC about test 065 failures.
> I asked Bill Kendall about it and he bisected to find
> that the commit below seems to be where the problems
> started.  I believe the problem is that one of the
> times is not updated properly when renaming the file
> "addedfile4".  Here are the commands that might affect
> that file in test 065:
> 
> 	mv addeddir4/addedfile5 addeddir4/addedfile4
> 	mv addeddir4 addeddir6
> 
> I glanced at the commit and saw nothing obviously
> wrong, but at the moment I can't really dig into
> it any deeper so I thought I'd report what Bill
> found so others could look.

Yeah, I know that this patch was the cause, and IIRC it only affects
a hard linked directory. What I found is that the iterative dump
actually contains all the correct changes (the restore part of the
test does not fail) - it's just that the dump image table of
contents does not contain the all the changes. I haven't tracked
down why the dump TOC does not contain a modification that is
actually in the dump yet....

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2010-12-02  2:19 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2010-12-01 20:29 xfstests 065 failures Alex Elder
2010-12-02  2:21 ` Dave Chinner

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.