Check risk of 24-bit snapshot time overflow with LVM Thin Provisioning

[qubesuser]

LVM Thin Provisioning has a concept of "time", which is a 32-bit field in the thin pool superblock that is however stored in a 24-bit field in the block mapping btree, where it's used to determine if a block was changed after snapshotting where the remaining 40 bits of the 64-bit value indicate the block number a virtual block is mapped to.

This "time" field is incremented every time a snapshot is created in __create_snap in dm-thin-metadata.c, but I can't find any check for overflow at 16 million snapshot creations, and it also looks like that overflow would cause data corruption since the not-fitting-in-24-bits value would end up passed to pack_block_time where it would corrupt the block number field since it just uses an OR without masking to combine those values (and anyway, it would result in incorrect CoW behavior).

It's possible however that there is some mechanism that prevents this that I overlooked; I could not find any mention of this issue on the web.

It's currently probably not a problem in practice in Qubes, because with 2 snapshots created on each VM start, it would take around 460 VM starts per day to cause the overflow in 50 years, but it would become a problem if some new Qubes feature requires taking snapshots at a much higher rate.