Re: xfsqa 144 is failing now

[David Chinner <dgc@sgi.com>]

On Thu, Jul 12, 2007 at 04:04:31PM +0100, Christoph Hellwig wrote:
> I'm trying to fix up dmapi for the patch that uses filldir internally,
> and 144 is the xfsqa test for this functionality.  It worked fine a
> few weeks ago when I started that work but fails with plain TOT linux-xfs
> now with errors like:
> 
> 
> < report: get #0 had no errors.
> < report: get #1 had no errors.
> ---
> > ERROR: get #0, expected mode 35034, but found 33188
> > ERROR: get #0, expected uid -756063452, but found 0
> > ERROR: get #0, expected gid 323693819, but found 0
> > ERROR: get #0, expected mtime -424339458, but found 1184248449
> > ERROR: get #0, expected ctime -862739105, but found 1184248449
> > ERROR: get #0, expected dtime -862739105, but found 1184248449
> > ERROR: get #0, expected size 1125898004553757, but found 29696
> > report: 1 tests correct for get #0.
> > ERROR: get #1, expected mode 34544, but found 33188
> > ERROR: get #1, expected uid -1407127963, but found 0
> > ERROR: get #1, expected gid 1043573623, but found 0
> > ERROR: get #1, expected mtime -1589334486, but found
> 
> does anyone have an idea what might be causing this?

Not yet - AFAIK we're only seeing it on i386 ATM, and we only noticed it in
the past couple of days. Nobody has had a chance to look at it yet. I don't
think dmapi has been tested regularly on i386 so I'm not sure when the problem
first appeared yet.

> The only recent changes to xfs_dm.c are the hole punching fixes which
> seem rather unrelated.

*nod*

Given the expected output, I wouldn't be surprised if we've got
some kind of 32/64 bit problem here....

Cheers,

Dave.
-- 
Dave Chinner
Principal Engineer
SGI Australian Software Group