Jbaublitz metadata rework integrity

[mulkieran]

No description provided.

[packit-as-a-service]

Congratulations! One of the builds has completed. 🍾

You can install the built RPMs by following these steps:

• sudo yum install -y dnf-plugins-core on RHEL 8
• sudo dnf install -y dnf-plugins-core on Fedora
• dnf copr enable packit/stratis-storage-stratisd-3733
• And now you can install the packages.

Please note that the RPMs should be used only in a testing environment.

[mulkieran]

Help text for integrity size spec for file size predictor is:

      --integrity-tag-spec <integrity_tag_spec>
          Integrity tag specification defining the size of the tag to store a checksum or other value for each block on a device.
          
          [default: 512b]
          [possible values: 0b, 32b, 512b]

stratis-cli would do the same.

[jbaublitz]

Just one comment.

[jbaublitz]

I'm struggling to understand the logic of rounding up to the nearest byte if we're representing this as bits. This seems to defeat the purpose of representing it as bits in the first place. Could you explain a little bit more what you're trying to do here?

[mulkieran]

The 4095 in the expression '+4095 & !4095' is implicitly in units of bytes. If I don't round up, then the value for the tag space may underestimate by 7 the number of bits required. If, by a weird chance, that underestimate is also divisible by 4096, then the total allocation for integrity metadata is nicely aligned but up to 7 bits short of what might be required.

[jbaublitz]

I think this is another reason why the units would make more sense in bytes. The best case scenario is that we end up overestimating in a way that rounds to Mo8 hash sizes no matter what so this does not seem like we are getting anything from representing it as bits.

[mulkieran]

I would be happy to change the order of operations. Instead of multiplying the number of blocks by the bits value and then rounding up to the nearest byte, rounding the bits value up to the nearest byte and multiplying it by the number of blocks. Of course, that has no effect at this point on the computation's result.

What I think would be shortsighted at this point is limiting our D-Bus API and our pool-level metadata to allow only units of bytes.

I'll make the proposed change.

[mulkieran]

Pool metadata snippet, accepting all defaults:

 "data_tier": {
            "blockdev": {
                "allocs": [
                    [
                        {
                            "length": 16242688,
                            "parent": "ec6d3a58-4b5b-4878-9d11-c8f42b12ec8a",
                            "start": 8192
                        }
                    ]
                ],
                "devs": [
                    {
                        "integrity_meta_allocs": [
                            [
                                16250904,
                                524264
                            ]
                        ],
                        "uuid": "ec6d3a58-4b5b-4878-9d11-c8f42b12ec8a"
                    }
                ]
            },
            "integrity_spec": {
                "allocate_superblock": true,
                "block_size": 4096,
                "journal_size": 262144,
                "tag_spec": "B512"
            }
        }
    },