public inbox for linux-scsi@vger.kernel.org
 help / color / mirror / Atom feed
From: Eryu Guan <eguan@redhat.com>
To: Dmitry Monakhov <dmonakhov@openvz.org>
Cc: Christoph Hellwig <hch@infradead.org>,
	fstests@vger.kernel.org, linux-scsi@vger.kernel.org
Subject: Re: [PATCH 0/3] Improve block device testing coverage
Date: Fri, 31 Mar 2017 17:38:01 +0800	[thread overview]
Message-ID: <20170331093801.GK22845@eguan.usersys.redhat.com> (raw)
In-Reply-To: <8760ip28o8.fsf@dmlp.sw.ru>

On Fri, Mar 31, 2017 at 10:43:19AM +0300, Dmitry Monakhov wrote:
> Christoph Hellwig <hch@infradead.org> writes:
> 
> > On Thu, Mar 30, 2017 at 05:19:01PM +0400, Dmitry Monakhov wrote:
> >> During LSFMM we have discussed how to test lower-backend of linux IO-stack.
> >> Common opinion was that xfstests is the most obvious solution which cover
> >> most of use cases filesystem care about.
> >> 
> >> I'm working on integration T10-DIF/DIF data integrity features to ext4,
> >> for that reason we need to be shure that linux integrity framework is
> >> in working state, which is currently broken in several places.
> >> 
> >> In fact, it is relatively simple to add basic coverage tests for basic
> >> IO operations over virtual device with integrity support. All we need
> >> is to add lio target support.
> >
> > First:  Thanks for adding block layer testing!
> >
> > Second: even more so than Darrick's blockdev fallocate test this is
> > the wrong place.  If I run xfstests I want to test my file system,
> > not random block device features.  Please start a proper block device
> > testsuite instead, possibly by copy and pasting code from xfstests.
> Fair enough. I also not happy to place blkdev feature  to tests/generic
> namespace. But altearnative to fork xfstests infrastructure to dedicated
> test-framework only for blkdevice seems not very good. Because fork is
> always pain. I already maintain one internal fork of xfstests which
> tests our Vituozzo's speciffic features.
> 
> May be it would be reasonable idea to add didicated namespace
> 'tests/blockdev' in xfstests, and move all blkdev related tests here?
> IMHO this is good idea. Because filesystem relay on some basic
> features from blkdev which should be tested explicitly, because
> implicit testing is too hard to debug/investigation.

I'm not sure if xfstests is the right place for blockdev tests,
especially for the pure blockdev level features (at least Darrick's
blockdev tests are testing fallocate(2) interface).

But yeah, a new tests/blockdev dir would be good if we eventually decide
adding blockdev tests to xfstests, so they're not run by default when
people want to test filesystems.

Thanks,
Eryu

  reply	other threads:[~2017-03-31  9:38 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-03-30 13:19 [PATCH 0/3] Improve block device testing coverage Dmitry Monakhov
2017-03-30 13:19 ` [PATCH 1/3] add lio-target helpers Dmitry Monakhov
2017-03-30 13:19 ` [PATCH 2/3] add test: generic/420 check information lead for lio-fileio Dmitry Monakhov
2017-03-30 13:19 ` [PATCH 3/3] add test: generic/421 basic blockdev T10-DIF-TYPE1 integrity checks Dmitry Monakhov
2017-03-31  6:57 ` [PATCH 0/3] Improve block device testing coverage Christoph Hellwig
2017-03-31  7:43   ` Dmitry Monakhov
2017-03-31  9:38     ` Eryu Guan [this message]
2017-03-31 10:02       ` Dmitry Monakhov
2017-03-31 15:11         ` Bart Van Assche
2017-03-31 16:08           ` Darrick J. Wong

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=20170331093801.GK22845@eguan.usersys.redhat.com \
    --to=eguan@redhat.com \
    --cc=dmonakhov@openvz.org \
    --cc=fstests@vger.kernel.org \
    --cc=hch@infradead.org \
    --cc=linux-scsi@vger.kernel.org \
    /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