xfstest failures

xfstest failures

[Christoph Hellwig]

[-- Attachment #1: Type: text/plain, Size: 1136 bytes --]

Unfortunately it seems our number of test failures is still through the
roof, mostly due to the lack of updates in xfstests for other changes.

To start with the quick group in xfs I see:

generic/263

	This seems to be an old issue we've largely been ignoring
	forever IIRC.  Maybe we finally need an xfail group?

xfs/033

	xfs_Repair now aborts due to a verifier failure in
	xfs_trans_read_buf.  I think this is a real bug introduced
	in xfs_repair when new changes were brought in.  Output diff
	attached.

xfs/187

	Echoes "Need to update test 187 so that initial subtests do not
	use features2".  Why do we make this a fail rather than notrun?

xfs/199

	Has an unexpected XFS_SB_VERSION2_PROJID32BIT in sb_features.
	Given that we switched to projid32 by default this should have
	been updated.

xfs/206

	Does not expect the ftype flag.  Didn't we change a generic
	filter to take care of this?

xfs/296

	Checking for capability on restored file
	-RESTORE_DIR/DUMP_SUBDIR/testfile cap_setgid,cap_setuid+ep
	-# file: RESTORE_DIR/DUMP_SUBDIR/testfile
	-security.capability

	Seems like theres some issues with file capabilities.

[-- Attachment #2: 33.diff --]
[-- Type: text/plain, Size: 7496 bytes --]

--- tests/xfs/033.out	2013-09-09 14:41:08.000000000 +0000
+++ /root/xfstests/results//xfs/033.out.bad	2013-11-06 10:54:25.000000000 +0000
@@ -30,165 +30,9 @@
         - reset superblock...
 Phase 6 - check inode connectivity...
 reinitializing root directory
-        - resetting contents of realtime bitmap and summary inodes
-        - traversing filesystem ...
-        - traversal finished ...
-        - moving disconnected inodes to lost+found ...
-Phase 7 - verify and correct link counts...
-resetting inode INO nlinks from 1 to 2
-done
-Corrupting rt bitmap inode - setting bits to 0
-Wrote X.XXKb (value 0x0)
-Phase 1 - find and verify superblock...
-Phase 2 - using <TYPEOF> log
-        - zero log...
-        - scan filesystem freespace and inode maps...
-        - found root inode chunk
-Phase 3 - for each AG...
-        - scan and clear agi unlinked lists...
-        - process known inodes and perform inode discovery...
-bad magic number 0x0 on inode INO
-bad version number 0x0 on inode INO
-bad magic number 0x0 on inode INO, resetting magic number
-bad version number 0x0 on inode INO, resetting version number
-imap claims a free inode INO is in use, correcting imap and clearing inode
-cleared realtime bitmap inode INO
-        - process newly discovered inodes...
-Phase 4 - check for duplicate blocks...
-        - setting up duplicate extent list...
-        - check for inodes claiming duplicate blocks...
-Phase 5 - rebuild AG headers and trees...
-        - reset superblock...
-Phase 6 - check inode connectivity...
-reinitializing realtime bitmap inode
-        - resetting contents of realtime bitmap and summary inodes
-        - traversing filesystem ...
-        - traversal finished ...
-        - moving disconnected inodes to lost+found ...
-Phase 7 - verify and correct link counts...
-done
-Corrupting rt summary inode - setting bits to 0
-Wrote X.XXKb (value 0x0)
-Phase 1 - find and verify superblock...
-Phase 2 - using <TYPEOF> log
-        - zero log...
-        - scan filesystem freespace and inode maps...
-        - found root inode chunk
-Phase 3 - for each AG...
-        - scan and clear agi unlinked lists...
-        - process known inodes and perform inode discovery...
-bad magic number 0x0 on inode INO
-bad version number 0x0 on inode INO
-bad magic number 0x0 on inode INO, resetting magic number
-bad version number 0x0 on inode INO, resetting version number
-imap claims a free inode INO is in use, correcting imap and clearing inode
-cleared realtime summary inode INO
-        - process newly discovered inodes...
-Phase 4 - check for duplicate blocks...
-        - setting up duplicate extent list...
-        - check for inodes claiming duplicate blocks...
-Phase 5 - rebuild AG headers and trees...
-        - reset superblock...
-Phase 6 - check inode connectivity...
-reinitializing realtime summary inode
-        - resetting contents of realtime bitmap and summary inodes
-        - traversing filesystem ...
-        - traversal finished ...
-        - moving disconnected inodes to lost+found ...
-Phase 7 - verify and correct link counts...
-done
-Corrupting root inode - setting bits to -1
-Wrote X.XXKb (value 0xffffffff)
-Phase 1 - find and verify superblock...
-Phase 2 - using <TYPEOF> log
-        - zero log...
-        - scan filesystem freespace and inode maps...
-        - found root inode chunk
-Phase 3 - for each AG...
-        - scan and clear agi unlinked lists...
-        - process known inodes and perform inode discovery...
-bad magic number 0xffff on inode INO
-bad version number 0xffffffff on inode INO
-bad (negative) size -1 on inode INO
-bad magic number 0xffff on inode INO, resetting magic number
-bad version number 0xffffffff on inode INO, resetting version number
-bad (negative) size -1 on inode INO
-cleared root inode INO
-        - process newly discovered inodes...
-Phase 4 - check for duplicate blocks...
-        - setting up duplicate extent list...
-root inode lost
-        - check for inodes claiming duplicate blocks...
-Phase 5 - rebuild AG headers and trees...
-        - reset superblock...
-Phase 6 - check inode connectivity...
-reinitializing root directory
-        - resetting contents of realtime bitmap and summary inodes
-        - traversing filesystem ...
-        - traversal finished ...
-        - moving disconnected inodes to lost+found ...
-Phase 7 - verify and correct link counts...
-resetting inode INO nlinks from 1 to 2
-done
-Corrupting rt bitmap inode - setting bits to -1
-Wrote X.XXKb (value 0xffffffff)
-Phase 1 - find and verify superblock...
-Phase 2 - using <TYPEOF> log
-        - zero log...
-        - scan filesystem freespace and inode maps...
-        - found root inode chunk
-Phase 3 - for each AG...
-        - scan and clear agi unlinked lists...
-        - process known inodes and perform inode discovery...
-bad magic number 0xffff on inode INO
-bad version number 0xffffffff on inode INO
-bad (negative) size -1 on inode INO
-bad magic number 0xffff on inode INO, resetting magic number
-bad version number 0xffffffff on inode INO, resetting version number
-bad (negative) size -1 on inode INO
-cleared realtime bitmap inode INO
-        - process newly discovered inodes...
-Phase 4 - check for duplicate blocks...
-        - setting up duplicate extent list...
-        - check for inodes claiming duplicate blocks...
-Phase 5 - rebuild AG headers and trees...
-        - reset superblock...
-Phase 6 - check inode connectivity...
-reinitializing realtime bitmap inode
-        - resetting contents of realtime bitmap and summary inodes
-        - traversing filesystem ...
-        - traversal finished ...
-        - moving disconnected inodes to lost+found ...
-Phase 7 - verify and correct link counts...
-done
-Corrupting rt summary inode - setting bits to -1
-Wrote X.XXKb (value 0xffffffff)
-Phase 1 - find and verify superblock...
-Phase 2 - using <TYPEOF> log
-        - zero log...
-        - scan filesystem freespace and inode maps...
-        - found root inode chunk
-Phase 3 - for each AG...
-        - scan and clear agi unlinked lists...
-        - process known inodes and perform inode discovery...
-bad magic number 0xffff on inode INO
-bad version number 0xffffffff on inode INO
-bad (negative) size -1 on inode INO
-bad magic number 0xffff on inode INO, resetting magic number
-bad version number 0xffffffff on inode INO, resetting version number
-bad (negative) size -1 on inode INO
-cleared realtime summary inode INO
-        - process newly discovered inodes...
-Phase 4 - check for duplicate blocks...
-        - setting up duplicate extent list...
-        - check for inodes claiming duplicate blocks...
-Phase 5 - rebuild AG headers and trees...
-        - reset superblock...
-Phase 6 - check inode connectivity...
-reinitializing realtime summary inode
-        - resetting contents of realtime bitmap and summary inodes
-        - traversing filesystem ...
-        - traversal finished ...
-        - moving disconnected inodes to lost+found ...
-Phase 7 - verify and correct link counts...
-done
+xfs_imap_to_bp: xfs_trans_read_buf() returned error 117.
+cache_node_purge: refcount was 1, not zero (node=0x20bc810)
+
+fatal error -- could not iget root inode -- error - 117
+_check_xfs_filesystem: filesystem on /dev/vdc is inconsistent (c) (see /root/xfstests/results//xfs/033.full)
+_check_xfs_filesystem: filesystem on /dev/vdc is inconsistent (r) (see /root/xfstests/results//xfs/033.full)

[-- Attachment #3: Type: text/plain, Size: 121 bytes --]

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: xfstest failures

[Ben Myers]

On Wed, Nov 06, 2013 at 02:54:51AM -0800, Christoph Hellwig wrote:
> xfs/296
> 
> 	Checking for capability on restored file
> 	-RESTORE_DIR/DUMP_SUBDIR/testfile cap_setgid,cap_setuid+ep
> 	-# file: RESTORE_DIR/DUMP_SUBDIR/testfile
> 	-security.capability
> 
> 	Seems like theres some issues with file capabilities.

IIRC Eric noticed that this was broken and submitted a test for it.  It would
be great if someone can work on it.  ;)

-Ben

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: xfstest failures

[Eric Sandeen]

On 11/6/13, 10:18 AM, Ben Myers wrote:
> On Wed, Nov 06, 2013 at 02:54:51AM -0800, Christoph Hellwig wrote:
>> xfs/296
>>
>> 	Checking for capability on restored file
>> 	-RESTORE_DIR/DUMP_SUBDIR/testfile cap_setgid,cap_setuid+ep
>> 	-# file: RESTORE_DIR/DUMP_SUBDIR/testfile
>> 	-security.capability
>>
>> 	Seems like theres some issues with file capabilities.
> 
> IIRC Eric noticed that this was broken and submitted a test for it.  It would
> be great if someone can work on it.  ;)

that's right, it's a known bug w/ a testcase but no fix yet.

I looked a bit, but ugh, xfsdump.

-Eric

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: xfstest failures

[Dave Chinner]

On Wed, Nov 06, 2013 at 02:54:51AM -0800, Christoph Hellwig wrote:
> Unfortunately it seems our number of test failures is still through the
> roof, mostly due to the lack of updates in xfstests for other changes.
> 
> To start with the quick group in xfs I see:
> 
> generic/263
> 
> 	This seems to be an old issue we've largely been ignoring
> 	forever IIRC.  Maybe we finally need an xfail group?

It passes on different configurations. e.g. it passes on my single
CPU VM with a 4k block size, but fails with 1k block size on the
same VM. It fails witha 4k block size on a 4 CPU VM but passes with
a 512 byte block size...

It's a race condition somewhere, because adding debug makes it stop
failing.  So it doesn't always fail, and it doesn't fail reliably,
either, which makes all attempts i've made to find it go nowhere.

> xfs/033
> 
> 	xfs_Repair now aborts due to a verifier failure in
> 	xfs_trans_read_buf.  I think this is a real bug introduced
> 	in xfs_repair when new changes were brought in.  Output diff
> 	attached.

It's an unexpected abort from the libxfs code from verifier detected
corruption. There's a few of these, and I'm slowly working my way
through them (e.g. the last patch in the lastest series).

> xfs/187
> 
> 	Echoes "Need to update test 187 so that initial subtests do not
> 	use features2".  Why do we make this a fail rather than notrun?

The problem is that the 32 bit project ID bit is being set by
default now, resulting in the sb_features2 field having a value set
in it.

mkfs now needs to be explicit to use 16 bit project IDs, and a
modified form of this patch needs to be added as well:

http://oss.sgi.com/archives/xfs/2013-06/msg00219.html

I need to update that patch and resend it.  I get this when I run
with a current mkfs with CRCs enabled:

xfs/187 0s ... [not run] attr v1 not supported

> xfs/199
> 
> 	Has an unexpected XFS_SB_VERSION2_PROJID32BIT in sb_features.
> 	Given that we switched to projid32 by default this should have
> 	been updated.

Well, it needs the same mkfs treatment to specifically use 16 bit
project IDs so that it still works on old kernels. And it needs the
_requires_projid16bit() from the above patch, too.

> xfs/206
> 
> 	Does not expect the ftype flag.  Didn't we change a generic
> 	filter to take care of this?

xfs/206 has it's own mkfs filter:

http://oss.sgi.com/archives/xfs/2013-10/msg00777.html

I asked that the generic mkfs filters also be modified to support
ftype, and there hasn't been any followup since then.


> xfs/296
> 
> 	Checking for capability on restored file
> 	-RESTORE_DIR/DUMP_SUBDIR/testfile cap_setgid,cap_setuid+ep
> 	-# file: RESTORE_DIR/DUMP_SUBDIR/testfile
> 	-security.capability
> 
> 	Seems like theres some issues with file capabilities.

Long standing problem with xfs_restore and the way it restores
attributes. The test was written without a fix having been made.

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: xfstest failures

[Mark Tinguely]

On 11/06/13 13:44, Dave Chinner wrote:
> On Wed, Nov 06, 2013 at 02:54:51AM -0800, Christoph Hellwig wrote:
>> Unfortunately it seems our number of test failures is still through the
>> roof, mostly due to the lack of updates in xfstests for other changes.
>>
>> To start with the quick group in xfs I see:

...

>> xfs/206
>>
>> 	Does not expect the ftype flag.  Didn't we change a generic
>> 	filter to take care of this?
>
> xfs/206 has it's own mkfs filter:
>
> http://oss.sgi.com/archives/xfs/2013-10/msg00777.html
>
> I asked that the generic mkfs filters also be modified to support
> ftype, and there hasn't been any followup since then.
>

and I said that _filter_mkfs() does not need to be changed for field 
type. The standard output is correct already.

http://oss.sgi.com/archives/xfs/2013-10/msg00781.html

You also said the standard output is correct, and asked that new 
features add environment variables in _filter_mkfs():

http://oss.sgi.com/archives/xfs/2013-10/msg00823.html

Don't see any feature including crcs doing that yet.

--Mark.

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: xfstest failures

[Christoph Hellwig]

On Wed, Nov 06, 2013 at 01:58:31PM -0600, Mark Tinguely wrote:
> 
> >>xfs/206
> >>
> >>	Does not expect the ftype flag.  Didn't we change a generic
> >>	filter to take care of this?
> >
> >xfs/206 has it's own mkfs filter:
> >
> >http://oss.sgi.com/archives/xfs/2013-10/msg00777.html

And why is this patch not merged?

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: xfstest failures

[Christoph Hellwig]

On Wed, Nov 06, 2013 at 12:20:47PM -0600, Eric Sandeen wrote:
> that's right, it's a known bug w/ a testcase but no fix yet.
> 
> I looked a bit, but ugh, xfsdump.

Maybe it's time you come up with an xfail mechanism at least?

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: xfstest failures

[Christoph Hellwig]

On Thu, Nov 07, 2013 at 06:44:17AM +1100, Dave Chinner wrote:
> > 	xfs_Repair now aborts due to a verifier failure in
> > 	xfs_trans_read_buf.  I think this is a real bug introduced
> > 	in xfs_repair when new changes were brought in.  Output diff
> > 	attached.
> 
> It's an unexpected abort from the libxfs code from verifier detected
> corruption. There's a few of these, and I'm slowly working my way
> through them (e.g. the last patch in the lastest series).

Well, we realsly should have fixes this as part of the merge.  Merging
code that introduces regressions for the default config should not be
acceptable.

> > xfs/187
> > 
> > 	Echoes "Need to update test 187 so that initial subtests do not
> > 	use features2".  Why do we make this a fail rather than notrun?
> 
> The problem is that the 32 bit project ID bit is being set by
> default now, resulting in the sb_features2 field having a value set
> in it.
> 
> mkfs now needs to be explicit to use 16 bit project IDs, and a
> modified form of this patch needs to be added as well:
> 
> http://oss.sgi.com/archives/xfs/2013-06/msg00219.html
> 
> I need to update that patch and resend it.  I get this when I run
> with a current mkfs with CRCs enabled:
> 
> xfs/187 0s ... [not run] attr v1 not supported

But it still breaks the v4 config.  I have to say enabling the 32bit
projids on v4 filesystems by default as a side effect of the crc
changes sound worse and worse.  The people who needed it already do on
v4 manually, and others will get it with the v5 rollout.

But if we want to stick to v4 + 32bit projid we should at least make
sure it does not break the tests.

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: xfstest failures

[Dave Chinner]

On Thu, Nov 07, 2013 at 12:22:34AM -0800, Christoph Hellwig wrote:
> On Thu, Nov 07, 2013 at 06:44:17AM +1100, Dave Chinner wrote:
> > > 	xfs_Repair now aborts due to a verifier failure in
> > > 	xfs_trans_read_buf.  I think this is a real bug introduced
> > > 	in xfs_repair when new changes were brought in.  Output diff
> > > 	attached.
> > 
> > It's an unexpected abort from the libxfs code from verifier detected
> > corruption. There's a few of these, and I'm slowly working my way
> > through them (e.g. the last patch in the lastest series).

Well, the initial xfsprogs crc support changes were effectively
merged unreviewed. That wasn't my fault - I asked that a crc-dev
branch be made while review was done so early adopters didn't need
to add 50+ patches to xfsprogs to be able to test the new
functionality and I didn't have to keep posting it while I waited
for someone to review it.

It didn't get reviewed - it got merged instead.

So, here we are, still cleaning up the pieces that review would have
probably caught. Well, I'm still trying to clean up the pieces, because
nobody else is and nobody seems to want the patches, either...

> > > xfs/187
> > > 
> > > 	Echoes "Need to update test 187 so that initial subtests do not
> > > 	use features2".  Why do we make this a fail rather than notrun?
> > 
> > The problem is that the 32 bit project ID bit is being set by
> > default now, resulting in the sb_features2 field having a value set
> > in it.
> > 
> > mkfs now needs to be explicit to use 16 bit project IDs, and a
> > modified form of this patch needs to be added as well:
> > 
> > http://oss.sgi.com/archives/xfs/2013-06/msg00219.html
> > 
> > I need to update that patch and resend it.  I get this when I run
> > with a current mkfs with CRCs enabled:
> > 
> > xfs/187 0s ... [not run] attr v1 not supported
> 
> But it still breaks the v4 config.

Actually, it doesn't. v4 configs give the same notrun output, which
is wrong but doesn't result in a failure (hence I didn't notice it).
Now that you've reported it I've just found a bug in the
_requires_attr_v1 function that makes it always fail and notrun the
test....

I have not looked at that patch since I posted it months ago because
it does what I need for v5 superblocks, and nobody else has bothered
to review or try it and so I don't know it's actually fundamentally
broken.  It's not until someone else comes along and says "all this
stuff is busted" that it becomes clear that there's a problem. So,
I'll fix the patch and post it again.

However, Christoph, you should not have found this stuff given it's
been almost 5 months since I sent patches to handle these cases.
This is a perfect example of what is wrong with the way XFS is being
maintained right now.

> I have to say enabling the 32bit
> projids on v4 filesystems by default as a side effect of the crc
> changes sound worse and worse.  The people who needed it already do on
> v4 manually, and others will get it with the v5 rollout.

Yes, but I did the right thing....

> But if we want to stick to v4 + 32bit projid we should at least make
> sure it does not break the tests.

... because I sent xfstest patches at the same time make sure it
didn't break the tests.  But I, unfortunately, cannot make the
maintainers review or take the patches...

That's the fundamental problem here.  When I change stuff, I can't
get the maintainers to do anything with the code I post unless I put
on my cranky pants and start shouting and making people cry. I hate
having to do this, but it seems like it's the only thing that the
maintainers respond to.

Quite frankly, XFS upstream is completely dysfunctional right now
and, as such, it's no longer a fun thing to work on.

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: xfstest failures

[Christoph Hellwig]

On Thu, Nov 07, 2013 at 10:57:22PM +1100, Dave Chinner wrote:
> Actually, it doesn't. v4 configs give the same notrun output, which
> is wrong but doesn't result in a failure (hence I didn't notice it).
> Now that you've reported it I've just found a bug in the
> _requires_attr_v1 function that makes it always fail and notrun the
> test....

It fails for me running latests xfstests, latest xfsprogs an latest xfs
tree in a x86 VM running the default mkfs options.

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: xfstest failures

[Christoph Hellwig]

On Thu, Nov 07, 2013 at 10:57:22PM +1100, Dave Chinner wrote:
> However, Christoph, you should not have found this stuff given it's
> been almost 5 months since I sent patches to handle these cases.
> This is a perfect example of what is wrong with the way XFS is being
> maintained right now.

> That's the fundamental problem here.  When I change stuff, I can't
> get the maintainers to do anything with the code I post unless I put
> on my cranky pants and start shouting and making people cry. I hate
> having to do this, but it seems like it's the only thing that the
> maintainers respond to.
>
I've not seen them reposted either.  While review and commit latencie
can vary and be very high the most effective counter measure is frequent
reposts.

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: xfstest failures

[Markus Trippelsdorf]

On 2013.11.07 at 22:57 +1100, Dave Chinner wrote:
> This is a perfect example of what is wrong with the way XFS is being
> maintained right now.
> 
> That's the fundamental problem here.  When I change stuff, I can't
> get the maintainers to do anything with the code I post unless I put
> on my cranky pants and start shouting and making people cry. I hate
> having to do this, but it seems like it's the only thing that the
> maintainers respond to.
> 
> Quite frankly, XFS upstream is completely dysfunctional right now
> and, as such, it's no longer a fun thing to work on.

Then why don't you just set up a couple of git trees on git.kernel.org
and ask Linus to pull directly from those?

-- 
Markus

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: xfstest failures

[Eric Sandeen]

On 11/7/13, 2:17 AM, Christoph Hellwig wrote:
> On Wed, Nov 06, 2013 at 12:20:47PM -0600, Eric Sandeen wrote:
>> that's right, it's a known bug w/ a testcase but no fix yet.
>>
>> I looked a bit, but ugh, xfsdump.
> 
> Maybe it's time you come up with an xfail mechanism at least?

What's the proposal there, a "fail" group for things known to still
fail everywhere?

so i.e. ./check -x fail ?  I can easily send a patch for that if
that's what folks want.

-Eric

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: xfstest failures

[Mark Tinguely]

On 11/07/13 02:16, Christoph Hellwig wrote:
> On Wed, Nov 06, 2013 at 01:58:31PM -0600, Mark Tinguely wrote:
>>
>>>> xfs/206
>>>>
>>>> 	Does not expect the ftype flag.  Didn't we change a generic
>>>> 	filter to take care of this?
>>>
>>> xfs/206 has it's own mkfs filter:
>>>
>>> http://oss.sgi.com/archives/xfs/2013-10/msg00777.html
>
> And why is this patch not merged?
>

It was never reviewed.

--Mark.

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: xfstest failures

[Christoph Hellwig]

On Thu, Nov 07, 2013 at 07:24:28AM -0600, Eric Sandeen wrote:
> On 11/7/13, 2:17 AM, Christoph Hellwig wrote:
> > On Wed, Nov 06, 2013 at 12:20:47PM -0600, Eric Sandeen wrote:
> >> that's right, it's a known bug w/ a testcase but no fix yet.
> >>
> >> I looked a bit, but ugh, xfsdump.
> > 
> > Maybe it's time you come up with an xfail mechanism at least?
> 
> What's the proposal there, a "fail" group for things known to still
> fail everywhere?
> 
> so i.e. ./check -x fail ?  I can easily send a patch for that if
> that's what folks want.

A mechnism to annotate a test as xfail, so that check would output them
at the end ala:

Expected failures:  common/263
Unexpected successes: reiser4/001

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: xfstest failures

[Eric Sandeen]

On 11/7/13, 7:27 AM, Christoph Hellwig wrote:
> On Thu, Nov 07, 2013 at 07:24:28AM -0600, Eric Sandeen wrote:
>> On 11/7/13, 2:17 AM, Christoph Hellwig wrote:
>>> On Wed, Nov 06, 2013 at 12:20:47PM -0600, Eric Sandeen wrote:
>>>> that's right, it's a known bug w/ a testcase but no fix yet.
>>>>
>>>> I looked a bit, but ugh, xfsdump.
>>>
>>> Maybe it's time you come up with an xfail mechanism at least?
>>
>> What's the proposal there, a "fail" group for things known to still
>> fail everywhere?
>>
>> so i.e. ./check -x fail ?  I can easily send a patch for that if
>> that's what folks want.
> 
> A mechnism to annotate a test as xfail, so that check would output them
> at the end ala:
> 
> Expected failures:  common/263
> Unexpected successes: reiser4/001
> 

The thing that's tricky about that is that what's expected depends
so heavily on what kernel is running.

Would an expected failure be only for tests which are known to be
not-fixed anywhere?

-Eric

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: xfstest failures

[Christoph Hellwig]

On Thu, Nov 07, 2013 at 07:46:43AM -0600, Eric Sandeen wrote:
> Would an expected failure be only for tests which are known to be
> not-fixed anywhere?


Exactly.  If you want to be fancy we could allow a drop-in file to
override it if you want something for RHEL testing or similar

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: xfstest failures

[Eric Sandeen]

On 11/7/13, 7:24 AM, Mark Tinguely wrote:
> On 11/07/13 02:16, Christoph Hellwig wrote:
>> On Wed, Nov 06, 2013 at 01:58:31PM -0600, Mark Tinguely wrote:
>>>
>>>>> xfs/206
>>>>>
>>>>>     Does not expect the ftype flag.  Didn't we change a generic
>>>>>     filter to take care of this?
>>>>
>>>> xfs/206 has it's own mkfs filter:
>>>>
>>>> http://oss.sgi.com/archives/xfs/2013-10/msg00777.html
>>
>> And why is this patch not merged?
>>
> 
> It was never reviewed.

Nor was xfstests: filter projid32bit info out of growfs & info output
which I sent originally, before the ftype stuff went in.

Nor was xfstests: New _require_* tests for CRC enabled filesystems which
Dave sent back in June, which Dave alluded to as fixing this as well.
I circled back to it in October w/ a suggestion but haven't seen a
repost.

This lag is clearly causing headaches for all of us; let's just take
a deep breath & get these taken care of.

We had a really high rate of change there for a while, and keeping up on
all fronts was tough.

There's been a bit of defensiveness in the replies here; let's get past
that & take Christoph's list of failures and just get them taken care of.

I'll try to go through the failures and either pick up existing patches,
or get new ones written, and get a new series on the list to get this all
cleaned up.

-Eric


_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: xfstest failures

[Christoph Hellwig]

On Thu, Nov 07, 2013 at 07:58:24AM -0600, Eric Sandeen wrote:
> We had a really high rate of change there for a while, and keeping up on
> all fronts was tough.
> 
> There's been a bit of defensiveness in the replies here; let's get past
> that & take Christoph's list of failures and just get them taken care of.
> 
> I'll try to go through the failures and either pick up existing patches,
> or get new ones written, and get a new series on the list to get this all
> cleaned up.

It also would be use if everyone could resend patches more than say 2
weeks old that haven't moved forward or outright rejected.

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: xfstest failures

[Eric Sandeen]

On 11/7/13, 8:00 AM, Christoph Hellwig wrote:
> On Thu, Nov 07, 2013 at 07:58:24AM -0600, Eric Sandeen wrote:
>> We had a really high rate of change there for a while, and keeping up on
>> all fronts was tough.
>>
>> There's been a bit of defensiveness in the replies here; let's get past
>> that & take Christoph's list of failures and just get them taken care of.
>>
>> I'll try to go through the failures and either pick up existing patches,
>> or get new ones written, and get a new series on the list to get this all
>> cleaned up.
> 
> It also would be use if everyone could resend patches more than say 2
> weeks old that haven't moved forward or outright rejected.
> 

That's probably a better plan than having me confuse things by cobbling
together a new series from multiple authors.  So for now I'll retract
my offer.  ;)  But let's get stuff reposted as needed and get it done.

-Eric

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: xfstest failures

[Ben Myers]

On Thu, Nov 07, 2013 at 05:48:48AM -0800, Christoph Hellwig wrote:
> On Thu, Nov 07, 2013 at 07:46:43AM -0600, Eric Sandeen wrote:
> > Would an expected failure be only for tests which are known to be
> > not-fixed anywhere?
> 
> 
> Exactly.  If you want to be fancy we could allow a drop-in file to
> override it if you want something for RHEL testing or similar

Good idea to have an override, since everybody has multiple flavors to test
which all have different sets of tests that fail.

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: xfstest failures

[Christoph Hellwig]

On Thu, Nov 07, 2013 at 07:24:53AM -0600, Mark Tinguely wrote:
> >>>xfs/206 has it's own mkfs filter:
> >>>
> >>>http://oss.sgi.com/archives/xfs/2013-10/msg00777.html
> >
> >And why is this patch not merged?
> >
> 
> It was never reviewed.

Consider it reviewed:

Reviewed-by: Christoph Hellwig <hch@lst.de>

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: xfstest failures

[Dave Chinner]

On Thu, Nov 07, 2013 at 05:27:39AM -0800, Christoph Hellwig wrote:
> On Thu, Nov 07, 2013 at 07:24:28AM -0600, Eric Sandeen wrote:
> > On 11/7/13, 2:17 AM, Christoph Hellwig wrote:
> > > On Wed, Nov 06, 2013 at 12:20:47PM -0600, Eric Sandeen wrote:
> > >> that's right, it's a known bug w/ a testcase but no fix yet.
> > >>
> > >> I looked a bit, but ugh, xfsdump.
> > > 
> > > Maybe it's time you come up with an xfail mechanism at least?
> > 
> > What's the proposal there, a "fail" group for things known to still
> > fail everywhere?
> > 
> > so i.e. ./check -x fail ?  I can easily send a patch for that if
> > that's what folks want.
> 
> A mechnism to annotate a test as xfail, so that check would output them
> at the end ala:
> 
> Expected failures:  common/263
> Unexpected successes: reiser4/001

If you have a test that fails in your test environment and you don't
want to run it, use the expunged test mechanism. You can maintain it
yourself for your own test environment.

$ cat tests/xfs/expunged
078
$ sudo MKFS_OPTIONS="-m crc=1" ./check -X expunged xfs/078
FSTYP         -- xfs (debug)
PLATFORM      -- Linux/x86_64 test2 3.12.0-rc7-dgc+
MKFS_OPTIONS  -- -f -m crc=1 /dev/vdb
MOUNT_OPTIONS -- /dev/vdb /mnt/scratch

xfs/078       [expunged]
Passed all 0 tests

If we really want to, we can add default expunged files for
different distros so they don't run tests that are known to fail and
are not likely to be fixed automatically.

That handles the "test doesn't fail everywhere" problem that xfail
has....

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: xfstest failures

[Dave Chinner]

On Thu, Nov 07, 2013 at 05:48:48AM -0800, Christoph Hellwig wrote:
> On Thu, Nov 07, 2013 at 07:46:43AM -0600, Eric Sandeen wrote:
> > Would an expected failure be only for tests which are known to be
> > not-fixed anywhere?
> 
> 
> Exactly.  If you want to be fancy we could allow a drop-in file to
> override it if you want something for RHEL testing or similar

Yup, that's exactly what the expunged test files are for. :)

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs