xfsqa 144 is failing now

xfsqa 144 is failing now

[Christoph Hellwig]

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?

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

Re: xfsqa 144 is failing now

[Justin Piszcz]

On Thu, 12 Jul 2007, 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?
>
> The only recent changes to xfs_dm.c are the hole punching fixes which
> seem rather unrelated.
>
>

Curious, what do you use that utilizes DMAPI?

Re: xfsqa 144 is failing now

[Christoph Hellwig]

On Thu, Jul 12, 2007 at 12:43:56PM -0400, Justin Piszcz wrote:
> Curious, what do you use that utilizes DMAPI?

xfsqa :)  There's a lot of dmapi tests in there, including the one
that fails.

Re: xfsqa 144 is failing now

[David Chinner]

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

Re: xfsqa 144 is failing now

[David Chinner]

On Fri, Jul 13, 2007 at 08:23:05AM +1000, David Chinner wrote:
> 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:
.....
> > 
> > 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....

Just to confirm - test 144 is passing reliably on ia64 with a TOT
kernel and xfstests, so it's likely to be something specific to i386.

Cheers,

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

Re: xfsqa 144 is failing now

[Christoph Hellwig]

On Fri, Jul 13, 2007 at 08:23:05AM +1000, David Chinner wrote:
> 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.

Btw, the xfstests/dmapi/src/suite1/cmd/get_dirattrs works perfectly even
on i386.  So there must be something that's broken in the actual testcase.