Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add the btrfs partitioning mode #694

Merged
merged 22 commits into from
Jul 4, 2024
Merged

Add the btrfs partitioning mode #694

merged 22 commits into from
Jul 4, 2024

Conversation

ondrejbudai
Copy link
Member

@ondrejbudai ondrejbudai commented May 16, 2024

(This is a revived #422.)

This PR has basically three parts:

  1. The first commits fix already existing btrfs code in the library (it was never used before). Just tiny fixes. I tried to add tests where they had been missing before.
  2. The "middle section" adds missing parts for btrfs subvolume. The scaffolding was there, but the translation from an abstract partition table to osbuild stages was missing.
  3. The final section is the actual addition of a btrfs partitioning mode. When this mode is used, a root partition from the base partition table is converted to a btrfs one with a subvolume. The code for adding more btrfs subvolumes based on blueprint mountpoints was already there.

Weird parts:

  • When a btrfs partitioning mode is used, the compression is hard-coded to zstd:1. It would be great if this could be configured per an image type/distro/arch, but the partitioning code currently cannot do such specific things. In the end, this should be probably also user-configurable. However, I think that this default value is alright for the starters, we can always iterate on this.
  • Setting min-size for extra mountpoints is a weird thing, because the extra mountpoints are translated to subvolumes... Maybe we should just error out if the min size is set with btrfs and depend just on the total size customization... Happy to discuss this!

TODO:

  • more tests (especially for ensureBtrfs)

@achilleas-k
Copy link
Member

  • When a btrfs partitioning mode is used, the compression is hard-coded to zstd:1. It would be great if this could be configured per an image type/distro/arch, but the partitioning code currently cannot do such specific things. In the end, this should be probably also user-configurable. However, I think that this default value is alright for the starters, we can always iterate on this.

I can't say for sure (I don't remember), but I bet we gave little consideration for this when adding it. It was probably a decision to add it and figure out the config later. Like you said, it's a sane enough default.

  • Setting min-size for extra mountpoints is a weird thing, because the extra mountpoints are translated to subvolumes... Maybe we should just error out if the min size is set with btrfs and depend just on the total size customization... Happy to discuss this!

I remember thinking about this, going back and forth on ideas for how to handle sizing. One idea was to sum up the min sizes and set the whole volume as the sum. Erroring out on sizing for subvols also makes sense though.

Copy link
Contributor

@mvo5 mvo5 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I did not got very far but some nitpicks/comments ideas inline before I call it a day :) Thanks for the work on this, looks very nice so far and I really think this will help bootc!

pkg/disk/btrfs_test.go Outdated Show resolved Hide resolved
pkg/disk/btrfs.go Show resolved Hide resolved
pkg/disk/disk_test.go Outdated Show resolved Hide resolved
pkg/disk/disk_test.go Show resolved Hide resolved
pkg/disk/partition_table.go Show resolved Hide resolved
pkg/disk/partition_table.go Outdated Show resolved Hide resolved
mvo5
mvo5 previously approved these changes May 17, 2024
Copy link
Contributor

@mvo5 mvo5 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you! This looks very nice! I focused on the code in the review and did not dig into how fedora uses btrfs and how that maps but it seems also fine. Great stuff, some ideas/nitpicks inline but no blockers (from my POV).

pkg/disk/partition_table.go Show resolved Hide resolved
pkg/disk/partition_table.go Show resolved Hide resolved
pkg/disk/partition_table_test.go Show resolved Hide resolved
pkg/disk/partition_table_test.go Show resolved Hide resolved
pkg/osbuild/device_test.go Outdated Show resolved Hide resolved
pkg/osbuild/device_test.go Outdated Show resolved Hide resolved
pkg/osbuild/disk_test.go Show resolved Hide resolved
@bcl
Copy link
Contributor

bcl commented May 20, 2024

  • Setting min-size for extra mountpoints is a weird thing, because the extra mountpoints are translated to subvolumes... Maybe we should just error out if the min size is set with btrfs and depend just on the total size customization... Happy to discuss this!

Or only error if the min-size is larger than the total volume size?

Copy link

This PR is stale because it has been open 30 days with no activity. Remove "Stale" label or comment or this will be closed in 7 days.

@github-actions github-actions bot added the Stale label Jun 22, 2024
Copy link

This PR was closed because it has been stalled for 30+7 days with no activity.

@github-actions github-actions bot closed this Jun 29, 2024
@mvo5 mvo5 reopened this Jul 2, 2024
@mvo5 mvo5 removed the Stale label Jul 2, 2024
Copy link
Member

@achilleas-k achilleas-k left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM but I have some git commit and history related nitpicks:

  • There are a couple of commits with long messages.
  • Can we get the history cleaned up a bit? For instance squashing the small follow-up commits into the ones that introduced the small issue.

pkg/osbuild/disk_test.go Show resolved Hide resolved
pkg/disk/disk_test.go Show resolved Hide resolved
mvo5
mvo5 previously approved these changes Jul 3, 2024
Copy link
Contributor

@mvo5 mvo5 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fwiw, I like it but my review only counts +0.5 as I did a bunch of tweaks to it. If this gets merged I will also look at a small followup to see if #694 (comment) makes sense and I am thinking about testing this more, maybe via #732 even - we give the partition code a bunch of inputs and see if we get the expected btrfs (but maybe I'm overthinking things here :)

@achilleas-k
Copy link
Member

achilleas-k commented Jul 3, 2024

Merge conflicts

Prior this commit, the GenUUID method of Btrfs didn't propagate the
generated UUID to a subvolume. Thus, when GetFSSpec was called
on the subvolume, an empty UUID was returned. Thus, invalid
kernel arguments were generated (for root fs), and the system
rendered to be unbootable.
ForEachMountable is called for every subvolume, thus if there was one
btrfs partition with multiple subvolumes, the code generated multiple
mkfs.btrfs stages for one partition, breaking the build.

This commit adds a tiny bit of logic for ensuring that we call mkfs just
once per each partition.
So the code just panicked before. Let's generate a device name in
a similar way as we do for a luks container.
This commit also adds a test that covers both mkfs.btrfs (see the previous
commit) and creating subvolumes.
This commit also adds a semi-fake partition table with a Btrfs setup.
This commits also removes the generic opts (MntOpts) from btrfs subvolumes.
They were not used anywhere, and I think it's much better to make all
supported mount options explicit, rather than storing them in a generic
array.
TODO: needs tests

The conversion code from raw partitioning is basically the same as the one
for LVM. The main difference is that LVM just embeds an already defined
filesystem, but btrfs-ication needs to do some guessing because the code
actually creates a new partition: specifically, I just hardcoded the
compression to zstd:1. This is not ideal, but it's the Fedora's default,
so it's imho fine as the first iteration.
This is weird, because we just hardcode zstd:1, but it's good enough
for the starters (and also inspired by Fedora).

I also introduced a constant for the default btrfs compression.
mvo5 added 7 commits July 4, 2024 09:31
Add new TestGenImageKernelOptionsBtrfsNotRootCmdlineGenerated() to
check that no commandline is generated for non "/" partitions.
A new test TestCreatePartitionTableBtrfsify was added.

This test also uncovered a small bug in ensureBtrfs() that got
fixed along the way.
@mvo5
Copy link
Contributor

mvo5 commented Jul 4, 2024

Merge conflicts

Should be fixed now.

achilleas-k
achilleas-k previously approved these changes Jul 4, 2024
Copy link
Member

@achilleas-k achilleas-k left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Approving but the error from the linter should be fixed to avoid weird loop side-effects.

@mvo5
Copy link
Contributor

mvo5 commented Jul 4, 2024

Approving but the error from the linter should be fixed to avoid weird loop side-effects.

Linter error is addressed.

@mvo5 mvo5 enabled auto-merge July 4, 2024 14:15
Copy link
Member Author

@ondrejbudai ondrejbudai left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

fwiw, the changes from Michael are wonderful, thanks!

@mvo5 mvo5 added this pull request to the merge queue Jul 4, 2024
Merged via the queue into osbuild:main with commit d28a8a8 Jul 4, 2024
16 of 17 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants