public inbox for fstests@vger.kernel.org
 help / color / mirror / Atom feed
From: Dave Chinner <david@fromorbit.com>
To: Eryu Guan <guaneryu@gmail.com>
Cc: yang xu <xuyang.jy@cn.fujitsu.com>, fstests@vger.kernel.org
Subject: Re: [PATCH] xfs/444: add check for xfs_db write bno array
Date: Fri, 13 Apr 2018 23:42:10 +1000	[thread overview]
Message-ID: <20180413134210.GD5572@dastard> (raw)
In-Reply-To: <20180413043612.GF2932@desktop>

On Fri, Apr 13, 2018 at 12:36:12PM +0800, Eryu Guan wrote:
> > > But this issue looks like a bug in xfsprogs to me, not a missing feature
> > > in xfsprogs on RHEL7, so I tend to fail the test instead of adding a new
> > > _require rule & _notrun the test. And in this case, IMHO, I don't think
> > > it's necessary to do any update to the test, just leave the test as it
> > > is and file a new bug in Red Hat bugzilla.
> > 
> > ... this isn't a RHEL specific issue - it's an xfsprogs version
> > issue.  i.e.  any older distro that has a binary with a broken
> > "write array" command will fail this test. None of them are going to
> > get updated xfsprogs packages, so like having an old mkfs.xfs
> > binary, this test should run conditionally on having a version of
> > xfs_db that actually works correctly....
> 
> But I still think it's a pure bug in xfsprogs, not xfsprogs version
> issue nor a behavior change in xfsprogs, as we did support "write via
> array indexing", just that it was broken in a certain case, and commit
> 4222d000ed3b fixed that bug. We should expose bugs by letting the test
> fail, not paper over it by _notrun the test. 

Yes, it's a bug in xfsprogs. But it's a bug in a diagnostic
utility that is only used by test infrastructure and XFS
developers.

Yes, it's ialso fixed in recent version of xfsprogs, but you know
very well that we test distros that have ancient xfsprogs and will
never have this issue fixed in them. We use detectiona nd notrun to
avoid tests they should not run all the time, and I don't see how
this is any different.

I really don't understand why you are pushing back on this - why
should this specific infrastructure deficiency cause test failures,
when all the existing infrastructure support checks cause tests to
notrun rather than fail?

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

  reply	other threads:[~2018-04-13 13:42 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-04-12 10:00 [PATCH] xfs/444: add check for xfs_db write bno array yang xu
2018-04-12 12:09 ` Dave Chinner
2018-04-12 13:00   ` Eryu Guan
2018-04-12 23:00     ` Dave Chinner
2018-04-13  4:36       ` Eryu Guan
2018-04-13 13:42         ` Dave Chinner [this message]
2018-04-16  6:00           ` Eryu Guan
2018-04-16  9:07             ` [PATCH v2] common/xfs: Add require_xfs_db_write_array function yang xu
2018-04-16 17:22               ` Darrick J. Wong
     [not found]                 ` <5AD5721C.10709@cn.fujitsu.com>
2018-04-17  4:06                   ` Darrick J. Wong
2018-04-17  6:11                     ` [PATCH v3] " yang xu
2018-04-17 17:59                       ` Darrick J. Wong
2018-04-18  4:29                         ` Eryu Guan
  -- strict thread matches above, loose matches on Subject: below --
2018-04-16  6:27 [PATCH] xfs/444: add check for xfs_db write bno array Xu, Yang

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20180413134210.GD5572@dastard \
    --to=david@fromorbit.com \
    --cc=fstests@vger.kernel.org \
    --cc=guaneryu@gmail.com \
    --cc=xuyang.jy@cn.fujitsu.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox