Skip to content

repart: Sort the partition list by partition offset#42488

Open
jonas2515 wants to merge 2 commits into
systemd:mainfrom
jonas2515:repart-sort-by-real-offset
Open

repart: Sort the partition list by partition offset#42488
jonas2515 wants to merge 2 commits into
systemd:mainfrom
jonas2515:repart-sort-by-real-offset

Conversation

@jonas2515
Copy link
Copy Markdown
Contributor

@jonas2515 jonas2515 commented Jun 4, 2026

Currently the partition list is ordered like this: First come the partitions that exist as definition files (could be pre-existing partitions or could be new ones), then come the pre-existing partitions that aren't matched to a definition file.

This ordering is visible to the user when we print our partition table, and it doesn't really make sense from a UX perspective: Partition tables are usually either presented in order of the partition indices, or in order of the partition offsets. Arguably the latter would be nicer here, since the visualization below is already ordered by physical offsets.

So reorder the list after we assigned the new partitions to their respective free areas, according to the physical offset (or, for partitions to newly create, the order that we will allocate them in).

Another potential upside of this is that we could rely on the partition order in the code now more, too.

To ensure it keeps working, also add a test in the integration tests for it.

Screenshot before:
Screenshot From 2026-06-05 00-58-07

Screenshot after:

Screenshot From 2026-06-05 00-58-16

@github-actions github-actions Bot added tests repart please-review PR is ready for (re-)review by a maintainer labels Jun 4, 2026
@github-actions
Copy link
Copy Markdown

github-actions Bot commented Jun 5, 2026

Claude review of PR #42488 (b08d5a4)

The reordering logic is correct and memory-safe — node ownership stays well-defined, the list head stays consistent, the insertion sorts terminate, and no downstream consumer (partno/offset assignment, supplement resolution, place/grow, JSON dump) depends on the old ordering. The new integration test is auto-discovered, deterministic across architectures, self-consistent, and would fail without the code change. A few maintainability/clarity notes only:

Suggestions

  • Sentinel offsets in existing bucketsrc/repart/repart.c:11292 — dropped/suppressed/new-unallocated partitions still have offset == UINT64_MAX and sort to the tail; restrict the offset sort to real on-disk partitions or document the sentinel behavior.
  • Extract reorder into a helpersrc/repart/repart.c:11310 — the ~40-line anonymous { ... } block would read better as a named context_*() helper, matching the file's idiom.
  • Use LIST_POP for the first loopsrc/repart/repart.c:11250 — the bucket-split loop could use the while ((p = LIST_POP(...))) idiom of the other three loops instead of LIST_FOREACH_WITH_NEXT plus a manual LIST_REMOVE.
  • Use unsigned/size_t for partition counterssrc/repart/repart.c:4326n_partitions/cur_n_partition are declared unsigned int; prefer size_t for both the CODING_STYLE unsigned-form rule and consistency with the file's other partition counters.

Nits

  • Hoist duplicated LIST_REMOVEsrc/repart/repart.c:11279 — the LIST_REMOVE call is identical in both if/else branches and can be moved before the conditional.
  • Missing assert(context)src/repart/repart.c:11246context_sort_partitions() omits the leading assert(context); used by the other context_*() helpers in this file.
  • Dropped partitions break dump underlinesrc/repart/repart.c:11292 — appending all dropped partitions to the tail suppresses the size/padding sum underline on the last rendered row in context_dump_partitions() whenever anything is dropped (terminal table only).
  • Redundant sfdisk assertions in testtest/units/TEST-58-REPART.sh:849 — the trailing sfdisk --dump assert_in block largely duplicates the JSON diff, and its truncated patterns don't validate uuid/name.

Workflow run

Workflow run

Comment thread src/repart/repart.c Outdated
Comment thread src/repart/repart.c Outdated
Comment thread src/repart/repart.c Outdated
@jonas2515 jonas2515 force-pushed the repart-sort-by-real-offset branch from 7b2d6bf to ef0dfd3 Compare June 5, 2026 11:01
Comment thread src/repart/repart.c
@jonas2515 jonas2515 force-pushed the repart-sort-by-real-offset branch from ef0dfd3 to 23f366d Compare June 6, 2026 14:36
Comment thread src/repart/repart.c Outdated
Comment thread src/repart/repart.c
@jonas2515 jonas2515 force-pushed the repart-sort-by-real-offset branch from 23f366d to 86cc59f Compare June 6, 2026 15:49
Comment thread src/repart/repart.c Outdated
Comment thread test/units/TEST-58-REPART.sh
jonas2515 added 2 commits June 6, 2026 18:04
Claude found a small bug with the partition table we print: We filter out
partitions with p->dropped while making the table, but we want to put an
underline after the last row of the table. In the case where the last entry
in the context->partitions list is a dropped partition, the check for
!p->partitions_next returns FALSE when it actually *is* the last row in the
table.

So move to a check that's based on a pre-counted number of partitions to
print rather than checking for !p->partitions_next.

Co-developed-by: Claude Opus 4.8 <[email protected]>
Currently the partition list is ordered like this: First come the partitions that
exist as definition files (could be pre-existing partitions or could be new ones),
then come the pre-existing partitions that aren't matched to a definition file.

This ordering is visible to the user when we print our partition table, and it
doesn't really make sense from a UX perspective: Partition tables are usually
either presented in order of the partition indices, or in order of the partition
offsets. Arguably the latter would be nicer here, since the visualization below
is already ordered by physical offsets.

So reorder the list after we assigned the new partitions to their respective free
areas, according to the physical offset (or, for partitions to newly create, the
order that we will allocate them in).

Another potential upside of this is that we could rely on the partition order in
the code now more, too.

To ensure it keeps working, also add a test in the integration tests for it.
@jonas2515 jonas2515 force-pushed the repart-sort-by-real-offset branch from 86cc59f to b08d5a4 Compare June 6, 2026 16:04
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

claude-review please-review PR is ready for (re-)review by a maintainer repart tests

Development

Successfully merging this pull request may close these issues.

2 participants