veyepar: VM block error injection, a novel approach for testing Linux storage

Author(s):	Tony Asleson
Location	Room 8
Date	jan Thu 16	Days Raw Files
Start	11:40	First Raw Start	error-in-template
Duration	0:45:0	Offset	None
End	12:25	Last Raw End
Chapters
Total cuts_time	None min.

https://lca2020.linux.org.au/schedule/presentation/69/
raw-playlist raw-mp4-playlist encoded-files-playlist mp4 svg png

assets release.pdf VM_block_error_injection_a_novel_approach_for_testing_Linux_storage.json
logs
Admin: episode episode list cut list raw files day marks day marks day image_files

State:

Locked:

clear this to unlock

Locked by:

user/process that locked.

Start:

initially scheduled time from master, adjusted to match reality

Duration:

length in hh:mm:ss

Name:

Video Title (shows in video search results)

Emails:

email(s) of the presenter(s)

Released:

has someone authorised pubication

Normalise:

Channelcopy:

m=mono, 01=copy left to right, 10=right to left, 00=ignore.

Thumbnail:

filename.png

Description:

markdown

One of the most important characteristics of any operating system is the ability to safely store and retrieve end user data.  However, this area can be one of the most difficult things to test completely.  Hardware manufacturers strive to make their hardware as reliable as possible, so testing error paths for uncommon conditions is problematic.  For developers having a simple easy to use way to create these types of errors is vital for ensuring correctness.  Developers have tools like scsi_debug, dm-flakey, and others to exercise these error paths, but they all have limitations.

Virtual machines are ubiquitous, but people may not think of using them for purposely and deliberately creating errors for testing.  We have a opportunity to provide a test environment that allows easy testing of these infrequent error paths.  To force the kernel down read error paths, write error paths, silent data corruption detection/correction, timeouts, etc., during all times of kernel operation and even before the kernel gets loaded by the boot loader.  It's the only way to present an error that is just like actual hardware.

Attend this talk to learn about:
* Importance of testing the storage stack
* Difficulties in testing
* Different approaches in generating storage errors
* Benefits of adding testing capabilities to virtual machine vs. other approaches
* Other possibilities (block histograms, access patterns, playback)
* A preview proof of concept written for scsi-disk device in QEMU
  https://github.com/tasleson/qemu/tree/block_error_inject

Comment:

production notes