テストステ論

高テス協会会長が, テストステロンに関する情報をお届けします.

(writeboost report) Introducing dm-writeboost-tools

Since dm-writeboost gets in Debian and Ubuntu, it's attracting people's attention. My responsibility as the leading developer is to deliver more sophisticated kernel code and, userland tools.

To initialize and terminate the caching, Dmitry's management tool (https://gitlab.com/onlyjob/writeboost) is quite helpful but we need another tools to analyze cache device. This helps users

  • check if the cache device isn't broken
  • report the state of the cache device in case of trouble
  • learn deeply how writeboost works
  • (for me) debug

I developed tools in this weekend.

github.com

I chose to write in Go because

  • C is portable but bothering to maintain.
  • I don't like any scripting languages because I believe compilation help PR to justify its correctness.
  • My first choice was Rust but it's far from easiness (not for me but I want to involve other people) and still too young.
  • Go is well-balanced. Very easy to learn and community is getting mature.

The actual coding was done in a day but it required one another day to fix a single bug. Thanks Joe, to solve the problem. It was so hard.

https://groups.google.com/forum/#!topic/golang-nuts/DwQJ-zZ2uh8

I will show you how these tools are helpful.

wb_status

dmsetup status prints the information about the internal but it's little bit cryptic one line.

# dmsetup status wb
0 2097152 writeboost 635 762 6 24 23 18 531 2 0 0 0 1 0 0 0 2648 25 0 0 23 0 2635 0 1 10 writeback_threshold 0 nr_cur_batched_writeback 32 sync_data_interval 0 update_sb_record_interval 0 read_cache_threshold 0

Let's pass the line to wb_status and it's prettified.

# dmsetup status wb | ./wb_status
cursor pos: 635
# of cache blocks: 762
# of segments: 6
current id: 24
last flushed id: 23
last writeback id: 18
# of dirty cache blocks: 531
# of partial flushes: 1
write? hit? on_buffer? fullsize?
0 0 0 0 : 2
0 0 0 1 : 0
0 0 1 0 : 0
0 0 1 1 : 0
0 1 0 0 : 1
0 1 0 1 : 0
0 1 1 0 : 0
0 1 1 1 : 0
1 0 0 0 : 2648
1 0 0 1 : 25
1 0 1 0 : 0
1 0 1 1 : 0
1 1 0 0 : 23
1 1 0 1 : 0
1 1 1 0 : 2635
1 1 1 1 : 0

wb_meta

dm-writeboost writes metadata and data as a log. This command prints the metadata part. The information of segment_header appears first and sequence of each metablock follows.

# ./wb_meta /dev/hvg1/cache3m 3
id: 21
checksum: 3664294860
length: 127

  0 sector=1067192 dirty_bits=128
  1 sector=1067200 dirty_bits=255
  2 sector=1067208 dirty_bits=255
  3 sector=1067216 dirty_bits=255
  4 sector=1067224 dirty_bits=255
  ....
  124 sector=1068184 dirty_bits=255
  125 sector=1068192 dirty_bits=255
  126 sector=1068200 dirty_bits=127

wb_check

A log is detected corrupted if the checksum value on the disk isn't equal to the recomputed value. It's using crc32c algorithm that's typically used in storage softwares (iscsi, xfs and dm stuffs). Let's try

# ./wb_check /dev/hvg1/cache3m 3
# echo $?
0

Oh, no problem but what if using the totally irrelevant device?

# ./wb_check /dev/hvg2/back18g 3
# echo $?
1

Failed. it's working.

wb_dump

The last stuff is to dump the data block. But this is mainly for developers. Debugging storage kernel is very hard. Often I fight with the dump and become crazier.

# ./wb_dump /dev/hvg1/cache3m 126
17f000 000000 000000 000000 000000 000000 000000 000000 000000
*
17fe00 065553 065553 065553 065553 065553 065553 065553 065553
*
17fff0 065553 065553 065553 065553 065553 065553 065553 122553
180000

Go is nice. Kernel guys, Let's write Go!