From: Dmitry Monakhov <dmonakhov@openvz.org>
To: Christoph Hellwig <hch@infradead.org>
Cc: fstests@vger.kernel.org, linux-scsi@vger.kernel.org
Subject: Re: [PATCH 0/3] Improve block device testing coverage
Date: Fri, 31 Mar 2017 10:43:19 +0300 [thread overview]
Message-ID: <8760ip28o8.fsf@dmlp.sw.ru> (raw)
In-Reply-To: <20170331065702.GA17435@infradead.org>
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.
>
> That's how I started the test suite for qemu's block layer for example.
Do you mean qemu/tests/qemu-iotests ?
next prev parent reply other threads:[~2017-03-31 7:43 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 [this message]
2017-03-31 9:38 ` Eryu Guan
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=8760ip28o8.fsf@dmlp.sw.ru \
--to=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