Make corrupt_geometry test continue to work with in-kernel formatting. - #2
Make corrupt_geometry test continue to work with in-kernel formatting.#2bmarzins wants to merge 2 commits into
Conversation
dt_device() was only using its rseed argument (which is the only argument that current callers actually set). Make it correctly handle all of its arguments to enable other users.
|
@fsuba Just a heads-up that the RHEL-113137 (and the associated MR https://gitlab.com/redhat/centos-stream/src/kernel/centos-stream-10/-/merge_requests/2442) broke a vdo test for dmtest-python. This fixes it to work both before and after the change. |
lorelei-sakai
left a comment
lorelei-sakai
left a comment
There was a problem hiding this comment.
This looks pretty reasonable to me. The only concern is checking for "Bad magic number": that string will happen any time we return the VDO_BAD_MAGIC error code, not just in this specific operation. In practice, though, we don't produce that error anywhere else.
| message = get_dmesg_log(start_time) | ||
| log.info(message) | ||
| assert_string_in(message, "Could not load geometry block") | ||
| assert_string_in(message, "VDO Status: Bad magic number") |
There was a problem hiding this comment.
Are you sure this is correct. I believe it should look for either "Could not load geometry block" for older kernels or "Could not parse geometry block" for newer vdoformat in kernel ones.
There was a problem hiding this comment.
If you're getting bad magic number back, then this concerns me. It could be that we need to check for all three messages.
There was a problem hiding this comment.
I was getting both messages: "VDO Status: Bad magic number" and either "Could not load geometry block" or "Could not parse geometry block". The Bad magic number was the one that was constant between releases. I assume that's because it checks the magic number first when reading the block, and both all 0s and all 1s falis that check. At any rate, your version will work fine, and has the benefit of being an easier drop-in test fix, since it doesn't require a different helper program.
Now that the kernel will format a device with a zeroed geometry block, calling wipe_device() won't actually work to corrupt the device anymore. It will just trigger in-kernel formatting. Instead write all 1s to the geometry block.
|
Closing in favor of #3 |
4 participants
The vdo/load_failure/corrupt_geometry test broke when the in-kernel formatting was added to vdo. The test previously corrupted the geometry block by using dd to fill it with 0s. Loading a table with a zeroed geometry block now triggers in-kernel formatting. Instead, the test now uses dt to fill the geometry block with all 1s.