Received:  by oss.sgi.com id <S553957AbQKHGo5>;
	Tue, 7 Nov 2000 22:44:57 -0800
Received: from deliverator.sgi.com ([204.94.214.10]:40059 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S553929AbQKHGom>;
	Tue, 7 Nov 2000 22:44:42 -0800
Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via SMTP id WAA07745
	for <linux-xfs@oss.sgi.com>; Tue, 7 Nov 2000 22:36:50 -0800 (PST)
	mail_from (tes@boing.melbourne.sgi.com)
Received: from boing.melbourne.sgi.com (boing.melbourne.sgi.com [134.14.55.141]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id RAA07980; Wed, 8 Nov 2000 17:43:23 +1100
Received: (from tes@localhost) by boing.melbourne.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) id RAA75122; Wed, 8 Nov 2000 17:43:20 +1100 (EDT)
From:   tes@boing.melbourne.sgi.com (Timothy Shimmin)
Message-Id: <200011080643.RAA75122@boing.melbourne.sgi.com>
Subject: Re: stress test failures
To:     marcelo.magallon@bigfoot.com (Marcelo E. Magallon)
Date:   Wed, 8 Nov 2000 17:43:19 +1100 (EDT)
Cc:     linux-xfs@oss.sgi.com
In-Reply-To: <20001107173432.A16761@techno.informatik.uni-stuttgart.de> from "Marcelo E. Magallon" at Nov 07, 2000 05:34:32 PM
X-Mailer: ELM [version 2.5 PL2]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

Hi Marcelo,

Your xfsdump/xfsrestore failures of: 026, 028, 046, 047
are all consistent with not being able to read the
dump inventory.

028/047 which test out xfsinvutil do an "xfsdump -I"
before and after calling xfsinvutil to verify that the pruning
happens, and it (xfsdump -I) produces nothing for you !
In 026 (and presumably 046), it does not output the msg
"using online session inventory", which seems to indicate that
it wasn't able to successfully read the inventory.

Unfortunately, at the moment, I don't have your setup to
reproduce this failure.
Would you be able to set the environment variable, DEBUGDUMP,
rerun the failing tests (./check -g xfsdump) and 
send me the ???.out.bad files. 
The DEBUGDUMP should cause xfsdump/xfsrestore to be run with -v5.

Thanks,
Tim.

> 
> 
> >> "Marcelo E. Magallon" <marcelo.magallon@bigfoot.com> writes:
> 
>  >  I've been running the stress tests on a daily basis for a while now and
>  >  most failures have dissapered lately. [...]
> 
>  The reported failure involving mmap is no longer reproducible.
> 
>  From last night's run I have:
> 
>  Not run: 022 023 024 025 035 036 037 038 039 040 043 044
>  Failures: 020 026 028 046 047
>  Failed 5 of 35 tests
>  
>  026 is differences in the output (026.out should be updated)
> 
> 026 - output mismatch (see 026.out.bad)
> 30,31c30
> < xfsrestore: using online session inventory
> < xfsrestore: searching media for directory dump
> ---
> > xfsrestore: searching media for dump
> 32a32,43
> > xfsrestore: found dump matching specified label:
> > xfsrestore: hostname: HOSTNAME
> > xfsrestore: mount point: SCRATCH_MNT
> > xfsrestore: volume: SCRATCH_DEV
> > xfsrestore: session time: TIME
> > xfsrestore: level: 0
> > xfsrestore: session label: "stress_026"
> > xfsrestore: media label: "stress_tape_media"
> > xfsrestore: file system id: ID
> > xfsrestore: session id: ID
> > xfsrestore: media id: ID
> > xfsrestore: searching media for directory dump
> 
>  028 is two large chunks of output not present.
> 
>  046 is a difference in the output, just as 046 (046.out needs to be
>  updated)
> 
>  047 is similar to 028. (047.out.bad.gz attached)
> 
>  Thanks,
> 
> --
> Marcelo