You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In composefs we support (and effectively recommend) inlining <= 64 byte files - it can especially be useful for zero sized files which are not uncommon.
Let's change what is done here to do that by default. One notable thing is this decision changes the fsverity digest of the composefs.
For example,
$ podman run --pull=newer --rm -ti quay.io/centos-bootc/centos-bootc:stream9 bash
# find /etc -type f -size -65c | wc -l
493 # out of 1337
# find /usr -type f -size -65c | wc -l
572 # out of 26376
#
So just about 3% of files, but far from nothing.
Today ostree doesn't do this because basically composefs is just glued onto the side of its already extant on-disk representation which we need to maintain for backcompat, so there's no point currently until we have a composefs-native store there. In contrast composefs representation in this project is AFAIK still subject to change, so let's make some changes.
The text was updated successfully, but these errors were encountered:
In composefs we support (and effectively recommend) inlining <= 64 byte files - it can especially be useful for zero sized files which are not uncommon.
Let's change what is done here to do that by default. One notable thing is this decision changes the fsverity digest of the composefs.
For example,
So just about 3% of files, but far from nothing.
Today ostree doesn't do this because basically composefs is just glued onto the side of its already extant on-disk representation which we need to maintain for backcompat, so there's no point currently until we have a composefs-native store there. In contrast composefs representation in this project is AFAIK still subject to change, so let's make some changes.
The text was updated successfully, but these errors were encountered: