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

[Bart Van Assche <Bart.VanAssche@wdc.com>]

On Tue, 2017-08-08 at 15:13 -0600, Jens Axboe wrote:
> On 08/08/2017 03:05 PM, Shaohua Li wrote:
> > > 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.

Hello Jens,

Would you consider it acceptable to make the mode in which null_blk stores
data the default? I know several people who got confused by null_blk by
default not retaining data ...

Thanks,

Bart.