xfs
[Top] [All Lists]

Re: [PATCH 0/5] xfstests: various fixes

To: xfs@xxxxxxxxxxx
Subject: Re: [PATCH 0/5] xfstests: various fixes
From: Dave Chinner <david@xxxxxxxxxxxxx>
Date: Wed, 1 May 2013 19:31:39 +1000
Delivered-to: xfs@xxxxxxxxxxx
In-reply-to: <1367397123-2530-1-git-send-email-david@xxxxxxxxxxxxx>
References: <1367397123-2530-1-git-send-email-david@xxxxxxxxxxxxx>
User-agent: Mutt/1.5.21 (2010-09-15)
On Wed, May 01, 2013 at 06:31:58PM +1000, Dave Chinner wrote:
> Hi folks,
> 
> These are various fixes for xfstests.
> 
> The first patch is an infrastructure regression fix, resulting from
> the patchset that split up the tests into subdirectories. It also
> moves all the check.* output files to the result directory rather
> than leaving them in the root directory of xfstests.
> 
> The second is a bunch of changes to generic/310 that should have
> been done in the review cycle. It now works reliably for me.
> 
> The last 3 patches fix bugs in tests that result in files being left
> in the root directory of xfstests.

FWIW, with the V2 xfsprogs kernel sync tarball I've posted and these
fixes to xfstests, I'm down to only 3 failures in xfstests for 4k
block size filesystem tests:

Failures: generic/233 shared/298 xfs/296

generic/233 appears to be a small quota accounting mismatch,
probably related to speculative preallocation. Not a major issue.

shared/298 is failing due to the ENOSPC problem Eric posted patches
to fix. Test bug.

xfs/296 is failing due to an unresolved xfsdump issue w.r.t
restoring security attributes. Unresolved.

So, I'm much happier now about the state of xfsprogs and xfstests
than I was this morning.  I'll be happier still when I fix the fsx
failures on 512 byte block size filesystems, because that will bring
my 512 byte block size filesystem tests to close to the same level.
That's for tomorrow, though.

Cheers,

Dave.
-- 
Dave Chinner
david@xxxxxxxxxxxxx

<Prev in Thread] Current Thread [Next in Thread>