linux-block.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Damien Le Moal <Damien.LeMoal@wdc.com>
To: Johannes Thumshirn <jthumshirn@suse.de>,
	Chaitanya Kulkarni <Chaitanya.Kulkarni@wdc.com>,
	"lsf-pc@lists.linux-foundation.org" 
	<lsf-pc@lists.linux-foundation.org>
Cc: Jens Axboe <axboe@kernel.dk>,
	"bvanassche@acm.org" <bvanassche@acm.org>,
	"hare@suse.de" <hare@suse.de>,
	"hch@infradead.org" <hch@infradead.org>,
	"jack@suse.cz" <jack@suse.cz>,
	"keith.busch@intel.com" <keith.busch@intel.com>,
	"martin.petersen@oracle.com" <martin.petersen@oracle.com>,
	"ming.lei@redhat.com" <ming.lei@redhat.com>,
	"osandov@fb.com" <osandov@fb.com>,
	"tytso@mit.edu" <tytso@mit.edu>, Sagi Grimberg <sagi@grimberg.me>,
	"linux-block@vger.kernel.org" <linux-block@vger.kernel.org>,
	"linux-ide@vger.kernel.org" <linux-ide@vger.kernel.org>,
	"linux-scsi@vger.kernel.org" <linux-scsi@vger.kernel.org>,
	"linux-nvme@lists.infradead.org" <linux-nvme@lists.infradead.org>
Subject: Re: [LSF/MM TOPIC] : blktests: status, an expansion plan for the storage stack test framework
Date: Thu, 7 Feb 2019 05:07:06 +0000	[thread overview]
Message-ID: <BYAPR04MB5816AD0D34E107EA79B69219E7680@BYAPR04MB5816.namprd04.prod.outlook.com> (raw)
In-Reply-To: 2ed684c6-38de-1717-5787-31b00c72ba4f@suse.de

On 2019/02/06 19:32, Johannes Thumshirn wrote:
> On 06/02/2019 06:21, Chaitanya Kulkarni wrote:
>> Hi,
>>
>> Since discussion of the storage stack and device driver at the LSFMM 2017
>> (https://lwn.net/Articles/717699/),  Omar Sandoval introduced a new framework
>> "blktests" dedicated for Linux Kernel Block layer testing.
>> (https://lwn.net/Articles/722785/, https://github.com/osandov/blktests).
>>  
>> As Linux Kernel Block layer is central to the various file systems and underlying
>> low-level device drivers it is important to have a centralized testing framework and
>> make sure it grows with the latest block layer changed which are being added based
>> on the different device features from different device types
>> (e.g. NVMe devices with Zoned Namespace support).
>>
>> Since then blktests has grown and became go-to framework where we have integrated
>> different stand-alone test suites like SRP-tests, NVMFTESTS, NVMe Multipath tests,
>> zone block device tests, into one central framework, which has made an overall block layer
>> testing and development much easier than having to configure and execute different
>> test cases for each kernel release for different subsystems such as FS, NVMe,
>> Zone Block devices, etc). 
>>
>> Here is the list of the existing test categories:-
>>
>> ├── block                                           28 Tests
>> ├── loop                                             07 Tests
>> ├── meta                                            12 Tests
>> ├── nbd                                              02 Tests
>> ├── nvme                                           28 Tests
>> ├── nvmeof-mp                                  12 Tests
>> ├── scsi                                              06 Tests
>> ├── srp                                               13 Tests
>> └── zbd                                              05 Tests
>> ---------------------------------------------------------------- 
>>            9 Categories                            ~110 Tests
>>
>> This project has gathered much attention and storage stack community is actively
>> participating and adding new test cases with different categories to the framework. 
>>
>> For storage track, we would like to propose a session dedicated to blktests. It is a great
>> opportunity for the storage developers to gather and have a discussion about:-
>>
>> 1. Current status of the blktests framework.
>> 2. Any new/missing features that we want to add in the blktests.
>> 3. Any new kernel features that could be used to make testing easier?
>> E.g. Implementing new features in the null_blk.c in order to have device
>> independent complete test coverage. (e.g. adding discard command for null_blk or any
>> other specific REQ_OP). Discussion about having any new tracepoint events in the block layer.
>> 4. Any new test cases/categories which are lacking in the blktests framework.
> 
> One thing I'd love to see is more hardware/driver specific tests. I'm
> sure Broadcom, Marvell, Huawei and all the others out there do have test
> suites for their HBA drivers but not a single one of these tests is
> publicly available.
> 
> We're also lacking tests for things like ioprio, persistent reservation,
> bcache and so on.

+1 for ioprio discussion. I mentioned my interest in discussing this in my
invite request. Having it as a topic would be great. Since we are in the middle
of blktest improvements for zoned devices, I can try to put together a proposal
as a discussion base.

> 
> Adding support for collecting gcov information after running a test case
> would also be awesome (this is missing in xfstests as well).
> 
> So I think a session on blktests can help us get the gap closed.
> 
> Byte,
> 	Johannes
> 


-- 
Damien Le Moal
Western Digital Research

  reply	other threads:[~2019-02-07  5:07 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-02-06  5:21 [LSF/MM TOPIC] : blktests: status, an expansion plan for the storage stack test framework Chaitanya Kulkarni
2019-02-06 10:32 ` Johannes Thumshirn
2019-02-07  5:07   ` Damien Le Moal [this message]
2019-02-15 22:14   ` Lee Duncan
2019-02-13 18:11 ` Bart Van Assche
2019-02-13 18:43   ` Omar Sandoval
2019-02-13 18:54     ` Bart Van Assche
2019-02-13 19:56       ` Omar Sandoval
2019-02-13 20:56         ` Bart Van Assche
2019-02-14  7:26   ` Chaitanya Kulkarni

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=BYAPR04MB5816AD0D34E107EA79B69219E7680@BYAPR04MB5816.namprd04.prod.outlook.com \
    --to=damien.lemoal@wdc.com \
    --cc=Chaitanya.Kulkarni@wdc.com \
    --cc=axboe@kernel.dk \
    --cc=bvanassche@acm.org \
    --cc=hare@suse.de \
    --cc=hch@infradead.org \
    --cc=jack@suse.cz \
    --cc=jthumshirn@suse.de \
    --cc=keith.busch@intel.com \
    --cc=linux-block@vger.kernel.org \
    --cc=linux-ide@vger.kernel.org \
    --cc=linux-nvme@lists.infradead.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=lsf-pc@lists.linux-foundation.org \
    --cc=martin.petersen@oracle.com \
    --cc=ming.lei@redhat.com \
    --cc=osandov@fb.com \
    --cc=sagi@grimberg.me \
    --cc=tytso@mit.edu \
    /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;
as well as URLs for NNTP newsgroup(s).