xfsqa 144 is failing now
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.
---
Quoted 4 lines
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
Quoted 8 lines
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.
Quoted 22 lines · 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.
---Quoted 4 lines
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 1184248449Quoted 8 lines
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
Quoted 6 lines
does anyone have an idea what might be causing this?
The only recent changes to
xfs_dm.care the hole punching fixes which seem rather unrelated.
Curious, what do you use that utilizes DMAPI?
Quoted 1 line · Justin Piszcz
Curious, what do you use that utilizes DMAPI?
xfsqa :) There's a lot of dmapi tests in there, including the one that fails.
Quoted 22 lines · 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.
---Quoted 4 lines
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 1184248449Quoted 8 lines
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
Quoted 1 line
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.
Quoted 2 lines
The only recent changes to
xfs_dm.care 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.
Signature · 3 lines
Dave Chinner Principal Engineer SGI Australian Software Group
Quoted 5 lines · David Chinner
Quoted 4 lines · 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:
.....
Quoted 8 lines
Quoted 2 lines
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.
Quoted 7 lines
Quoted 2 lines
The only recent changes to
xfs_dm.care 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.
Signature · 3 lines
Dave Chinner Principal Engineer SGI Australian Software Group
Quoted 4 lines · David Chinner
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.