nixos/lib/make-ext4-fs: fall back to resize2fs -M if exact resize fails #79368
Conversation
sorki
requested review from
samueldr and
lovesegfault
and removed request for
samueldr
|
I'm now questioning the old code path. Shouldn't we prefer always using If it's because it would end up bigger, it looks like we could run it twice or thrice to get it a bit more snug, but at the expense of performance. Since we're now bzipping the resulting image, it won't affect the hydra build. The main issue we may have is small SD devices and small eMMCs, but that should still be under 4GiB, and certainly far under 8GiB. |
|
I've tried running it 10 times in a loop (according to launchpad comment) but only the first iteration had any effect. |
|
Right, but comparing our current resize thing, with |
|
Not aware of any drawbacks but I'm no expert when it comes to |
nixos/lib/make-ext4-fs.nix
Outdated
| echo "Failed, resizing to minimum allowed by resize2fs" | ||
| fsck.ext4 -y -f $img | ||
| resize2fs $img -M | ||
| ) |
There was a problem hiding this comment.
Prefer only resize once, with -M, rather than fail once, then doing it with -M.
This also means we might be able to remove some dead code around here, which is good, no?
There was a problem hiding this comment.
I'm all for it when it comes to deleting redundant code, updated with snuggly resize dropped.
|
This increases the partition size from 2.0 GiB to 2.4GiB, but considering it only adds 1MiB to the final build artifact, it's not an issue. We were not targeting 2.0GiB to fit on a small SD card, but only for hydra. |
The root filesystem resizing step, `resize2fs -M', does not provide any
control over the amount of slack left in the result. It can produce an
arbitrarily tight fit, depending on how well the payload aligns with
ext4 data structures.
This is problematic, as NixOS must create a few files and directories
during its first boot, before the root is enlarged to match the size of
the containing SD card.
An overly tight fit can cause failures in the first stage:
mkdir: can't create directory '/mnt-root/proc': No space left on device
or in the second stage:
install: cannot create directory '/var': No space left on device
A previous version of `make-ext4-fs' (before PR NixOS#79368) was explicitly
"reserving" 16 MiB of free space in the final filesystem. Manually
calculating the size of an ext4 filesystem is a perilous endeavor,
however, and the method it employed was apparently unreliable.
Reverting is consequently not a good option.
A solution would be to create some sort of "balloon" occupying inodes
and blocks in the image prior to invoking `resize2fs -M', and to remove
these temporary files/directories before the compression step.
This changeset takes the simpler approach of simply dropping the
resizing step.
Note that this does *not* result in a larger image in general, as the
current procedure does not truncate the `.img' file anyway. In fact, it
has been observed to yield *smaller* compressed images---probably
because of some "noise" left after resizing. E.g., before-vs-after:
-r--r--r-- 2 root root 607M 1. Jan 1970 nixos-sd-image-21.11pre-git-x86_64-linux.img.zst
-r--r--r-- 2 root root 606M 1. Jan 1970 nixos-sd-image-21.11pre-git-x86_64-linux.img.zst
The root filesystem resizing step, `resize2fs -M', does not provide any
control over the amount of slack left in the result. It can produce an
arbitrarily tight fit, depending on how well the payload aligns with
ext4 data structures.
This is problematic, as NixOS must create a few files and directories
during its first boot, before the root is enlarged to match the size of
the containing SD card.
An overly tight fit can cause failures in the first stage:
mkdir: can't create directory '/mnt-root/proc': No space left on device
or in the second stage:
install: cannot create directory '/var': No space left on device
A previous version of `make-ext4-fs' (before PR #79368) was explicitly
"reserving" 16 MiB of free space in the final filesystem. Manually
calculating the size of an ext4 filesystem is a perilous endeavor,
however, and the method it employed was apparently unreliable.
Reverting is consequently not a good option.
A solution would be to create some sort of "balloon" occupying inodes
and blocks in the image prior to invoking `resize2fs -M', and to remove
these temporary files/directories before the compression step.
This changeset takes the simpler approach of simply dropping the
resizing step.
Note that this does *not* result in a larger image in general, as the
current procedure does not truncate the `.img' file anyway. In fact, it
has been observed to yield *smaller* compressed images---probably
because of some "noise" left after resizing. E.g., before-vs-after:
-r--r--r-- 2 root root 607M 1. Jan 1970 nixos-sd-image-21.11pre-git-x86_64-linux.img.zst
-r--r--r-- 2 root root 606M 1. Jan 1970 nixos-sd-image-21.11pre-git-x86_64-linux.img.zst
(cherry picked from commit 7c2adb1)
Workaround to fix resize2fs failures on
armv7landaarch64. I would drop the exact resizing but it seems to work fine onx86and might affect image reproducibility. There's not much to be gained by aggressive resizing (other than reproducibility) due tozstdcompression anyway. Side-note: when usingsdImagethe image is by default compressed again withbz2which only causes it grow a little.See also
Motivation for this change
Things done
sandboxinnix.confon non-NixOS linux)nix-shell -p nixpkgs-review --run "nixpkgs-review wip"./result/bin/)nix path-info -Sbefore and after)