Since we don't need redundant metadata for the image itself, force creation of the filesystem to single profile instead of depending on sysfs detection.
Ideas for fixing it:
kickstart command --mkfsoptions MKFSOPTS, e.g. "-msingle"
kickstart command --metadata METADATALEVEL, e.g. "single"
could the installer detect "baremetal" vs "virtual" installations? And if "virtual" always use single for btrfs?
kickstart btrfs commands
OK I've create a bug against anaconda, it'll either get fixed there for all "virtual" installations including images; or kickstart; or ignore it. (It's maybe 15MiB of space savings in the image to use single instead of dup; once xz or zlib compressed.)
https://bugzilla.redhat.com/show_bug.cgi?id=1974018
Should I create a cloud-sig issue for this or should we just take the initiative and do it? A lot of us overlap between the two projects, but I figure this is sufficiently esoteric that it could just be a fedora btrfs project decision.
Now that btrfs-progs 5.15 is slated to default to dup profile for metadata, I think this is more relevant now. We'd previously discussed that we probably don't need duplicated metadata for cloud use case, if the file system were to run into corruption, we'd probably only care about detecting it in such rare cases? Rather than also being able to correct it.
Plus, correction is hypothetical. it would depend on one of the copies being OK. If dup metadata is somehow deduplicated by lower storage stack layers, self-healing will be obviated.
This should probably be a Cloud WG issue, yes.
Metadata Update from @chrismurphy: - Issue set to the milestone: Future Release (was: Fedora 35)
Login to comment on this ticket.