Repository navigation
K2GO-555 fix(deploy): byte-weighted rootfs extract progress and ETA - #747
Merged
Merged
Conversation
…extract Parse a GNU tar -tv line into member path + byte size. The path can contain spaces, so the parse anchors on the fixed date/time; link targets are stripped so the path matches what the extract pass prints. Dirs/symlinks/hardlinks count 0 bytes. Pure + unit-tested (samples verbatim from the bundled libtar 1.35 on device). First piece of byte-weighted rootfs extract progress.
… for regular files only Device nodes show major,minor in the size column; the path-traversal and rootfs guards read every member, so the parser must not drop a member whose size field is not a byte count. Capture the path for all member types; parse a byte size only for a regular file.
…r rate A rate over the last window, not the cumulative average from the start. The cumulative average reads too low after a slow start and lags a recovery, which is what made the rootfs extract ETA read absurd minutes. Content-exchange and the extract pass will share this one pure, unit-tested helper.
List with tar -tv and keep each member size, so the extract bar and ETA are weighted by uncompressed bytes written, not file count. Members vary hugely in size, so the file-count ETA climbed to absurd values mid-extract on a slow phone and a healthy install looked hung. The extract rate is a trailing window, not the cumulative average from the pass start. Byte weighting degrades to file count when the listing yields no sizes, so the bar can never stall at zero. Ripple: the traversal and rootfs guards now get parsed paths, not the raw tar -t lines they used before; the rootfs validator extracts a probe member by that path, so it must be the clean path. VERIFY still counts compressed bytes read.
…vadoc Review pass: onProgress done/total are bytes in byteMode (advisory; consumers use percent); use ':' not '--' per CLAUDE.md.
luisguzman-adfa
changed the title
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What changes
tools/rebuild-dashboard.sh: on the staging install, reuse the livebetter_sqlite3.nodewhen better-sqlite3 is unchanged, instead of a full node-gyp recompile. Any mismatch (version change, binary does not load, or a new native dep) falls back to compiling from source.sleep 3with a poll up to 45 s (K2GO_REBUILD_STAGE_TIMEOUT), shared with the live verify through onepoll_smokehelper.K2GO_REBUILD_DRYRUN=1) that stops after the staged build and smoke, with no live promote.Why
sleep 3false-failed the staged smoke and aborted the update. The poll absorbs the boot time.Verifications
sleep 3would have false-failed); promote, restart and live verify passed. The reuse path finished in about 4.5 min; the recompile it replaces is about 20 min on this hardware.Notes
tools/rebuild-dashboard.shis the updater, not the dash-node source, so there is no dash-node version bump or changelog entry.