> good to know... by 'manually stacking them' do you mean like, manually getting checksum between certain tasks by just typing it in?
No, I mean manually setting up dm-integrity on the drives and then passing those dm-integrity mapped devices to LVM for doing the rest of the operations one intends.
Integrity is distinct from encryption (except authenticated encryption) too, encryption's purpose is privacy, whereas the checksumming is to detect data corruption from various things such as failing drives or cables.
2^-32 chance of collision (undetectable corruption) might sound very small but past a certain amount of data written/read it becomes basically unavoidable.
Corruption is a *lot* more common than undetectable corruption so even just crc32 is still significantly better than nothing at all.
As for LUKS/dm-crypt and its integration with dm-integrity (which provides authenticated encryption), I'd say it depends on your setup. There are issues with trim/discard with said integration, so it might not be a good idea to use it with SSDs. Foregoing the integration (using one on top of the other manually without informing the system of the link) means that a lot of more efficient computation paths are ignored and performance suffers a bit, but with SSDs that can probably be made-up for in other ways.
(For fun, try stacking 4 FUSE systems on top of eachother. Performance will take a hit each time. Same concept, but slightly less dramatic here because the in-kernel penalty is lower.)
LisPi /
npub132…qgzqx
2025-02-20 05:56:20
in reply to nevent1q…jh4h
Author Public Key
npub1326y4p8mw4l750yc8e52n0xguvcl5j0dn88ul5r2gjva2sh2ay7qjqgzqxPublished at
2025-02-20 05:56:20Event JSON
{
"id": "238161c20c9a9075024b6ae2896a181dc352c676565890486faed5f2a9e47f08",
"pubkey": "8ab44a84fb757fea3c983e68a9bcc8e331fa49ed99cfcfd06a4499d542eae93c",
"created_at": 1740030980,
"kind": 1,
"tags": [
[
"p",
"8ab44a84fb757fea3c983e68a9bcc8e331fa49ed99cfcfd06a4499d542eae93c"
],
[
"p",
"020c1d63b6c6d3458561cb934589cbe02898aba48ad1b008dcfab3d8624d139e"
],
[
"e",
"225695995f3d65cecfe7f7cd07dea1acb3d3c8c42f817edc4bf2add081c06755",
"",
"reply",
"020c1d63b6c6d3458561cb934589cbe02898aba48ad1b008dcfab3d8624d139e"
],
[
"content-warning",
"re: linux lvm disk integrity / checksums"
],
[
"e",
"55149755698e08d8cea4fa8fd017635c122592bb0e0942b365836fda194ca803",
"",
"root",
"8ab44a84fb757fea3c983e68a9bcc8e331fa49ed99cfcfd06a4499d542eae93c"
],
[
"proxy",
"https://udongein.xyz/objects/454d4e00-abb7-4250-9a49-1a6879b3163f",
"activitypub"
],
[
"L",
"pink.momostr"
],
[
"l",
"pink.momostr.activitypub:https://udongein.xyz/objects/454d4e00-abb7-4250-9a49-1a6879b3163f",
"pink.momostr"
],
[
"-"
]
],
"content": "\u003e good to know... by 'manually stacking them' do you mean like, manually getting checksum between certain tasks by just typing it in?\r\n\r\nNo, I mean manually setting up dm-integrity on the drives and then passing those dm-integrity mapped devices to LVM for doing the rest of the operations one intends.\r\n\r\nIntegrity is distinct from encryption (except authenticated encryption) too, encryption's purpose is privacy, whereas the checksumming is to detect data corruption from various things such as failing drives or cables.\r\n\r\n2^-32 chance of collision (undetectable corruption) might sound very small but past a certain amount of data written/read it becomes basically unavoidable.\r\n\r\nCorruption is a *lot* more common than undetectable corruption so even just crc32 is still significantly better than nothing at all.\r\n\r\nAs for LUKS/dm-crypt and its integration with dm-integrity (which provides authenticated encryption), I'd say it depends on your setup. There are issues with trim/discard with said integration, so it might not be a good idea to use it with SSDs. Foregoing the integration (using one on top of the other manually without informing the system of the link) means that a lot of more efficient computation paths are ignored and performance suffers a bit, but with SSDs that can probably be made-up for in other ways.\r\n\r\n(For fun, try stacking 4 FUSE systems on top of eachother. Performance will take a hit each time. Same concept, but slightly less dramatic here because the in-kernel penalty is lower.)",
"sig": "03f7bccc0a015b2a45f1675434726141dac424ff093a1a31ba32bd5a0dca59d67afd9c01942f25e1cfb017aa4634f71bb093dabd0e82cc15ebda33f771a81974"
}