Re: [PATCH 0/5] block: a virtual block device driver for testing

On 08/08/2017 03:05 PM, Shaohua Li wrote:

quoted

I'm curious why null_blk isn't a good fit? You'd just need to add RAM
storage to it. That would just be a separate option that should be set,
ram_backing=1 or something like that. That would make it less critical
than using the RAM disk driver as well, since only people that want a "real"
data backing would enable it.

It's not that I'm extremely opposed to adding a(nother) test block driver,
but we at least need some sort of reasoning behind why, which isn't just
"not a good fit".

Ah, I thought the 'null' of null_blk means we do nothing for the
disks. Of course we can rename it, which means this point less
meaningful. I think the main reason is the interface. We will
configure the disks with different parameters and do power on/off for
each disks (which is the key we can emulate disk cache and power
loss). The module paramter interface of null_blk doesn't work for the
usage. Of course, these issues can be fixed, for example, we can make
null_blk use the configfs interface. If you really prefer a single
driver for all test purpose, I can move the test_blk functionalities
to null_blk.

The idea with null_blk is just that it's a test vehicle. As such, it
would actually be useful to have a mode where it does store the data in
RAM, since that enables you to do other kinds of testing as well. I'd be
fine with augmenting it with configfs for certain things.

-- 
Jens Axboe