chore: deflake the blockfile testsuite #8696
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
mount supports
direct-iooption for loop block device. In the original loop setup, theDirectflag doesn't work even if the syscall returns successfully. In the patch, I useioctlto set the direct-io and return error if the old kernel doesn't support this.It's a cleanup for the snapshot test. The detach umount might cause unexpected issue. It's hard to debug in the github action. The umount without detach might be slow but it's easy to figure out the flaky cases.
The patch is trying to deflake the blockfile snapshot test case. The view-type snapshot mounts the device with readonly. If the filesystem needs to recovery, the kernel will return the EROFS and the error in
dmesgis like.For this case, I introduce a
viewHookhelper for test. It's used to mount the snapshot with write permission, so that the kernel can handle recovery at first. Then the ro mount won't fail.And using
8MiBis to reduce IO pressure. :)vendor: should sync when we applyvendor: update github.com/containerd/continuityEven if we use direct-io for loop, we still have the unsync error, like
So I change the fs/fstest to force sync for new file. Hopefully, containerd/continuity#228 it's acceptable.
I run this branch for test in azure Standard D4s v4. It's happy. :)