legacy_disk_layout: rootfs fs_size to the (almost) max
Copy some of the info from CL:1842312 and CL:1865692 that talks about
exactly what the extra space in the rootfs partition is used for.
Copied from those CLs:
Here the maximum is calculated as follows, solving for the unknown
variable "fs_MiB":
total_MiB = 2048
total_bytes = total_MiB * 1024 * 1024
fs_bytes = fs_MiB * 1024 * 1024
fs_blocks = fs_bytes / 4096
verity_blocks = div_round_up(fs_blocks, 128) + div_round_up(fs_blocks, 16384) + 1
verity_bytes = fs_bytes / 128 + fs_bytes / 16384 + 4096
fs_bytes + verity_bytes < total_bytes
fs_bytes + fs_bytes / 128 + fs_bytes / 16384 + 4096 < total_bytes
fs_bytes < (total_bytes - 4096) * 16384 / 16513
fs_MiB <= ((total_bytes - 4096) * 16384 / 16513) / (1024 * 1024)
fs_MiB <= ((total_MiB * 1024 * 1024 - 4096) * 16384 / 16513) / (1024 * 1024)
This gives us fs_MiB <= 2031. ...sure enough if you build with 2032
the build fails and with 2031 it passes.
As an emergency warning we'll leave an extra 40 and use 1991 vs. 2031.
BUG=chromium:1012296
TEST=build_image
Change-Id: I81918feed95cde45486031b4ae16f5c88e065535
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosutils/+/1907026
Tested-by: Daniel Campello <campello@chromium.org>
Reviewed-by: Will Bradley <wbbradley@chromium.org>
Reviewed-by: Steven Bennetts <stevenjb@chromium.org>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Reviewed-by: Chris McDonald <cjmcdonald@chromium.org>
Commit-Queue: Douglas Anderson <dianders@chromium.org>
diff --git a/build_library/legacy_disk_layout.json b/build_library/legacy_disk_layout.json
index a5fcc4b..1eed64d 100644
--- a/build_library/legacy_disk_layout.json
+++ b/build_library/legacy_disk_layout.json
@@ -93,13 +93,26 @@
"size": "2048 MiB"
},
{
- # Slot A rootfs. Rootfs + extras must fit.
- # FS size + Verity (64 * FS blocks).
- # Make sure that other layouts still has room for the
- # extras, should you increase FS size
+ # Slot A rootfs. Rootfs + extras (AKA verity) must fit, AKA:
+ # size <= FS size + Verity size
#
- # Note that updates will fail if the rootfs size
- # shrinks. (crbug.com/192136)
+ # Verity's size can be found by:
+ # verity_bytes = div_round_up(fs_bytes, 128) +
+ # div_round_up(fs_bytes, 16384) + 4096
+ #
+ # That means that the FS MiB should be:
+ # ((total_MiB * 1024 * 1024 - 4096) * 16384 / 16513) / (1024 * 1024)
+ #
+ # The reason to not set your fs_size to be exactly what is specified
+ # by the formula above is to make builds start failing a little bit
+ # before we're truly out of space, allowing a quick release valve to
+ # relieve some of the pressure while we try to find other ways to save
+ # space.
+ #
+ # Note that in the past it was observed that updates would fail if the
+ # rootfs size shrunk (crbug.com/192136). There are no known reasons to
+ # shrink the rootfs size, but if you come up with one you should
+ # revisit that bug and make sure it won't affect you.
#
# Changes to the offset of this partition may require
# changes in cros-signing/security_test_baselines/
@@ -113,7 +126,7 @@
"btrfs": "skinny-metadata"
},
"size": "2048 MiB",
- "fs_size": "1240 MiB",
+ "fs_size": "1991 MiB",
"uuid": "clear"
},
{
@@ -138,12 +151,6 @@
# installation will expand this to size from base.
"num": 5,
"size": "2 MiB"
- },
- {
- # Shrunken rootfs partition to support smaller USB sticks.
- # installation will expand this to size from base.
- "num": 3,
- "size": "1290 MiB"
}
],
# Used for factory install images.
@@ -175,15 +182,6 @@
"size": "2 MiB"
},
{
- # Shrunken rootfs partition to support smaller USB sticks,
- # and smaller recovery downloads.
- # Installation will expand this to size from base.
- # The offset to the beginning of this partition, and the FS
- # size must match base exactly to allow secure boot.
- "num": 3,
- "size": "1290 MiB"
- },
- {
# Stateful on recovery is dynamically resized larger.
"num": 1,
"size": "2 MiB"
