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 <s...@fb.com> > > > > 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. > > This is William's intern project. I made some changes, all errors are mine. > > You > > are more than welcomed to test and add new features! > > > Ah. But then why isn't he mentioned in the From: or Signed-off: lines? > Shouldn't he be getting some more credits than just 'William'? > (Unless William is in fact an alias for Kyungchan Koh, in which case a > name mapping would be nice ...) William is infact an alias for Kyungchan Koh. I'll make the name consistent in next post. Thanks, Shaohua
