xfs
[Top] [All Lists]

Re: [PATCH] xfstests btrfs/284: shorten duration, fix output

To: Rich Johnston <rjohnston@xxxxxxx>
Subject: Re: [PATCH] xfstests btrfs/284: shorten duration, fix output
From: Josef Bacik <jbacik@xxxxxxxxxxxx>
Date: Tue, 14 May 2013 16:42:01 -0400
Cc: Eric Sandeen <sandeen@xxxxxxxxxx>, xfs-oss <xfs@xxxxxxxxxxx>, Liu Bo <liubo2009@xxxxxxxxxxxxxx>, linux-btrfs <linux-btrfs@xxxxxxxxxxxxxxx>
Delivered-to: xfs@xxxxxxxxxxx
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/simple; d=fusionio.com; s=default; t=1368564124; bh=vHIzuJBRUSCit/7aKPJY3ZY8EbMp3FOvbBd40IdrvIA=; h=Date:From:To:CC:Subject:References:In-Reply-To; b=XhZzUbYyYBp2aP8Ru3XtMtSr6Yvf52FPP3N+Ac7HvpysEb7stdycZ47RtheWD2ahn tGKgAoGoKz+kI3VOyv9A6SetK/p/wWaGh/R6Pxb17mxErdFIbiDLvJDhMAu4VTeOWU KPLRsvYNQyHkygDcpXCsMm1fFKybcuEdAPfSM4NQ=
In-reply-to: <51925612.5050002@xxxxxxx>
References: <517ACB41.2030002@xxxxxxxxxx> <51925612.5050002@xxxxxxx>
User-agent: Mutt/1.5.21 (2011-07-01)
On Tue, May 14, 2013 at 09:19:46AM -0600, Rich Johnston wrote:
> On 04/26/2013 01:45 PM, Eric Sandeen wrote:
> > test 284 had... some issues.
> >
> > First, it took so long nobody ran it; so shorten the extent
> > count by a factor of about 100.
> >
> > Having fixed that, we see failures in 2 cases; when start or
> > len is -1, but the golden output file didn't have error
> > output, as if they should pass.
> >
> > I'm going to argue that these *should* both fail; start = -1
> > has no real meaning.  length = -1 might mean "the rest
> > of the file" but if that's what you really want, just
> > don't specify -l.
> >
> > So add failure output for those cases.
> >
> > Send all command output to $seq.full, in case that changes
> > in the future; just capture the return value.
> >
> > Then remove the return value echo on failure (50?) because
> > who knows when that might change to some other magic value.
> >
> > Ok, then when defrag actually works, old defrag returned
> > "20" (because?) but a recent commit changed it to 0.
> > So accommodate that too.
> >
> > And remove a stray "HAVE_DEFRAG=1" while we're at it.
> > That variable is never used.
> >
> 
> So should I be seeing failures with
> btrfs-progs-0.20-0.2.git91d9eec.el6.x86_64 installed?
> 
> ./check btrfs/284
> FSTYP         -- btrfs
> PLATFORM      -- Linux/x86_64 cxfsxe4 3.9.0+
> MKFS_OPTIONS  -- /dev/sdk2
> MOUNT_OPTIONS -- /dev/sdk2 /mnt/scratch
> 
> btrfs/284      - output mismatch (see 
> /usr/src/rcj/xfstests/results/btrfs/284.out.bad)
>      --- tests/btrfs/284.out  2013-05-14 09:31:35.000000000 -0500
>      +++ /usr/src/rcj/xfstests/results/btrfs/284.out.bad      2013-05-14 
> 10:10:45.000000000 -0500
>      @@ -6,7 +6,6 @@
>       btrfs filesystem defragment failed!
>       a single file | start > file size && 0 < len < file size | off
>       a single file | start = 0 && len < 0 | off (should fail)
>      -btrfs filesystem defragment failed!
>       a single file | start = 0 && len > file size | off
>       a single file | start = 0 && 0 < len < file size | off
>       a directory | default | off
>       ...
>       (Run 'diff -u tests/btrfs/284.out 
> /usr/src/rcj/xfstests/results/btrfs/284.out.bad' to see the entire diff)
> Ran: btrfs/284
> Failures: btrfs/284
> Failed 1 of 1 tests
> 

Yeah defrag used to spit out a return value on success, that has been fixed
recently.  This patch looks good, I just ran it on my box and it ran fine, you
can add

Reviewed-by: Josef Bacik <jbacik@xxxxxxxxxxxx>

Thanks,

Josef

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