Adjust file inlining limit for SHA-512

[allisonkarlitskaya]

Brings me to another point, though: we need to adjust (double) our "max inline file size" when we're in SHA-512 mode...

Originally posted by @allisonkarlitskaya in #105 (comment)

[allisonkarlitskaya]

It might be nice to consider this in a bit more detail: the amount of space actually required to store an external file is:

• 4 bytes for the nul (-1) chunk pointer
• (currently, assuming both xattrs unshared):
  • metacopy:
    • 4 bytes for an xattr header
    • 16 bytes "overlay.metacopy"
    • 4 bytes: metacopy header
    • 32/64 bytes: binary fs-verity digest
  • redirect:
    • 4 bytes for an xattr header
    • 16 bytes for "overlay.redirect"
    • 66/130 bytes for redirect file path

vs. inline data which simply stores a file directly inline. In all cases, note that inodes are 32-byte aligned, so we should round the value up to a multiple of 32 (although we could argue about the presence of other xattrs impacting the alignment and only round up to the nearest multiple of 4).

That means the extra metadata associated with storing a SHA-256 external file is 4 + 4 + 16 + 4 + 32 + 4 + 16 + 66 = 146 bytes. Round up to 4 = 148. Round up to 32 = 160.

For SHA-512: 4 + 4 + 16 + 4 + 64 + 4 + 16 + 130 = 242 bytes. Round up to 4 = 244. Round up to 32 = 256.

These sizes would shrink by 32 bytes each if we included support for custom xattr prefixes, but the fact that we recently added rhel9 support to this crate argues against that slightly...

In any case, 64 is definitely too small for SHA-256 and merely doubling it for SHA-512 would be an insufficient accounting of the image-size cost of storing external redirects (even ignoring runtime costs of opening the redirected file)... Setting the limit for SHA-512 to 256 seems more reasonable.

[allisonkarlitskaya]

Another deeper: larger amounts of inlining might impose more difficult alignment requirements on our inodes, resulting in addition of padding in order to satisfy erofs's requirements of inline data being contained in a single page. The same requirements don't apply to xattr data.

A model of how likely an inode with (let's say) 256 bytes of inlined data is to require padding plays out roughly like looking at a random alignment inside of a 4096 byte block and seeing if it's possible to write 256 bytes of data without overlapping into the next block. If overlapping would be required, we'd need to pad to the end of the block.

So at 256 bytes of inline data, the chance of needing padding is 256/4096 = 0.625% and the average amount of padding required would be ~128 bytes. That's 8 bytes of wasted space per inode on average, which is pretty small.... I'm not sure we should spend too much time thinking about this.