devicemapper-rs
devicemapper-rs copied to clipboard
Write a test to find out what happens when data low water is bigger than actual device
We would like to know exactly what happens if we tell the thinpool that its low water mark is larger than the data device itself. This is a test that could probably be run well by setting up a thinpool, and then specifying the too-large low water mark. It is probably not necessary to set up any thin devices on the the thinpool for the test.
It is reasonably to try first using the command-line, i.e., dmsetup.
@mulkieran, device mapper seems to not care about the low water mark being too large.
[gchin@to-be-determined stratis-storage]$ lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sda 8:0 0 119.2G 0 disk
├─sda1 8:1 0 1G 0 part /boot
├─sda2 8:2 0 11.9G 0 part [SWAP]
├─sda3 8:3 0 50G 0 part /
├─sda4 8:4 0 1K 0 part
└─sda5 8:5 0 56.3G 0 part /home
sdb 8:16 0 111.8G 0 disk
├─sdb1 8:17 0 4G 0 part
├─sdb2 8:18 0 5G 0 part
└─sdb3 8:19 0 5G 0 part
[gchin@to-be-determined stratis-storage]$ sudo dmsetup create thin1 --table '0 8388608 thin-pool /dev/sdb1 /dev/sdb2 2048 9999999999999999999 0'
[gchin@to-be-determined stratis-storage]$ lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sda 8:0 0 119.2G 0 disk
├─sda1 8:1 0 1G 0 part /boot
├─sda2 8:2 0 11.9G 0 part [SWAP]
├─sda3 8:3 0 50G 0 part /
├─sda4 8:4 0 1K 0 part
└─sda5 8:5 0 56.3G 0 part /home
sdb 8:16 0 111.8G 0 disk
├─sdb1 8:17 0 4G 0 part
│ └─thin1 253:0 0 4G 0 dm
├─sdb2 8:18 0 5G 0 part
│ └─thin1 253:0 0 4G 0 dm
└─sdb3 8:19 0 5G 0 part
@waltdisgrace Can you display the thinpool's table, also? We want to check if the value was silently changed to another value, or not. My guess is that we'll find that the low water mark is as you set it.
[gchin@to-be-determined devicemapper-rs]$ sudo dmsetup table thin1 0 8388608 thin-pool 8:17 8:18 2048 9999999999999999999 0
So, now, how does it behave? We'll have to figure out how to explore this question.
So, that devicemapper accepts a very large number does kind of make sense. That's a reasonable way for a client to indicate that it never wants to receive low-water related events.
But there are two interesting questions.
-
It seems that an event is only triggered when the low-water mark is crossed. It is crossed when the free space was above the low-water mark, but then drops below it. So stratisd should never compute a low-water mark that exceeds the existing free space. But it could compute the low-water mark and then set it at a time when the free space has already dropped. So, at computation time, it's below the free space, but when it is set, it is already above the free space. We should consider this in our strategy for setting this low water mark in stratisd.
-
When you suspended and then resumed the thinpool it appeared that no event was sent. We should try to determine if that was really true, or if we were misreading the dmsetup info output somehow.
We should set up a test to use inotify_wait to check for the event when the thinpool is suspended and resumed.