On Tue, Aug 08, 2017 at 02:31:54PM -0600, Jens Axboe wrote: > On 08/07/2017 10:36 AM, Shaohua Li wrote: > > On Mon, Aug 07, 2017 at 10:29:05AM +0200, Hannes Reinecke wrote: > >> On 08/05/2017 05:51 PM, Shaohua Li wrote: > >>> From: Shaohua Li <[email protected]> > >>> > >>> In testing software RAID, I usually found it's hard to cover specific > >>> cases. > >>> RAID is supposed to work even disk is in semi good state, for example, > >>> some > >>> sectors are broken. Since we can't control the behavior of hardware, it's > >>> difficult to create test suites to do destructive tests. But we can > >>> control the > >>> behavior of software, software based disk is an obvious choice for such > >>> tests. > >>> While we already have several software based disks for testing (eg, > >>> null_blk, > >>> scsi_debug), none is for destructive testing, this is the reason we > >>> create a > >>> new test block device. > >>> > >>> Currently the driver can create disk with following features: > >>> - Bandwidth control. A raid array consists of several disks. The disks > >>> could > >>> run in different speed, for example, one disk is SSD and the other is > >>> HD. > >>> Actually raid1 has a feature called write behind just for this. To test > >>> such > >>> raid1 feature, we'd like the disks speed could be controlled. > >>> - Emulate disk cache. Software must flush disk cache to guarantee data is > >>> safely stored in media after a power failure. To verify if software > >>> works > >>> well, we can't simply use physical disk, because even software doesn't > >>> flush > >>> cache, the hardware probably will flush the cache. With a software > >>> implementation of disk cache, we can fully control how we flush disk > >>> cache in a > >>> power failure. > >>> - Badblock. If only part of a disk is broken, software raid continues > >>> working. > >>> To test if software raid works well, disks must include some broken > >>> parts or > >>> bad blocks. Bad blocks can be easily implemented in software. > >>> > >>> While this is inspired by software raid testing, the driver is very > >>> flexible > >>> for extension. We can easily add new features into the driver. The > >>> interface is > >>> configfs, which can be configured with a shell script. There is a > >>> 'features' > >>> attribute exposing all supported features. By checking this, we don't > >>> need to > >>> worry about compability issues. For configuration details, please check > >>> the > >>> first patch. > >>> > >> Any particular reason why you can't fold these changes into brd or > >> null_blk? > >> After all, without those testing features it is 'just' another ramdisk > >> driver... > > > > null_blk isn't a good fit. ramdisk might be, but I try to not. We are adding > > new interfaces, locks and so on. Adding the features into ramdisk driver > > will > > mess it up. Binding it to ramdisk driver will make adding new features > > harder > > too, because the test driver doesn't really care about performance while > > ramdisk does. > > 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. Thanks, Shaohua
