storage: Avoid writing the whole device in coalesce tests

[glehmann]

This is done by:

• writing in only a small piece of data at the beginning, in the middle
  and at the end of the device
• creating the snapshot/clone
• writing for data in an already used location and a non-used one
• triggering the coalesce
• finally verifying that the data we generated is accessible as expected

Still not necessarily clear to me:

• Are we losing something by not filling the drive?
• How much data needs to be written to the disk? For now the tests is writing 4 chunks of 2GiB of data max, independently of the actual device size.

This PR is part of a tree containing 19 PRs:

1. master
2. storage: avoid removing the xva/vdi before going in the debugger #436 → master
3. storage: test large volumes #437 → storage: avoid removing the xva/vdi before going in the debugger #436
4. host: include mdadm RAID devices in disk detection #447 → storage: test large volumes #437
5. Update randstream to 0.5.0 #446 → host: include mdadm RAID devices in disk detection #447
6. "storage: Avoid writing the whole device in coalesce tests" (this PR) → Update randstream to 0.5.0 #446
7. storage: avoid writing the whole device in migration tests #450 → storage: Avoid writing the whole device in coalesce tests #449
8. xva/vdi: only write a small data amount in large volumes for faster tests #452 → storage: avoid writing the whole device in migration tests #450
9. storage: test full device write #453 → xva/vdi: only write a small data amount in large volumes for faster tests #452
10. storage: test that we can't create a vdi over its max allowed size #454 → storage: test full device write #453
11. storage: add jobs for large volume tests #461 → storage: test that we can't create a vdi over its max allowed size #454
12. skip large volume tests for zvol and nfsv4 #464 → storage: add jobs for large volume tests #461
13. storage: add comprehensive tests for lvmohba storage repositories #470 → skip large volume tests for zvol and nfsv4 #464
14. storage: free space for XVA import by destroying source VM first #471 → storage: add comprehensive tests for lvmohba storage repositories #470
15. storage: limit data written per VDI with --write-volume-cap #481 → storage: free space for XVA import by destroying source VM first #471
16. Add Packer configuration to build a minimal Alpine 3.23 UEFI VM for XCP-ng tests #523 → storage: limit data written per VDI with --write-volume-cap #481
17. migration: create a xfs sr on the second host for intra/cross-pool migration #497 → storage: limit data written per VDI with --write-volume-cap #481
18. Enhance block device management #498 → migration: create a xfs sr on the second host for intra/cross-pool migration #497
19. Add VHD_MAX and QCOW2_MAX symbolic size constants #500 → Enhance block device management #498
20. partially_populate_device: align span positions to block size for better performance #509 → Add VHD_MAX and QCOW2_MAX symbolic size constants #500

[dinhngtu]

I'd suggest writing data based on the translation unit of the virtual disk (e.g. if LVM stripe size is 4MB, write a small block every 3.99 MB). This will test writes to many suboffsets of the translation unit, and also test the whole range of the virtual disk at the same time. However, I imagine each backend/format combination will have a different translation unit requirement

[Nambrok]

It might be good to have a helper to generate and validate data. You could give it a list of place to write and it could return a list of checksum that you can give to the validate one. It would simplify coalesce_integrity which is becoming big.

[glehmann]

That's kind of what I did in the next commit (the list of places is hardcoded), to reuse those functions in other tests. I'm moving that commit in this PR.

[dinhngtu]

The write size can be as big as 2 GiB, this might not work on smaller VDIs especially if writes overlap. Although it'll just need a note.