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.
