Problem Description
ROCm CLI starts multi-GB downloads and extractions without ever checking whether there is room for them. There is no free-space check anywhere in the codebase, and no handling of the resulting out-of-space error, so a user with a nearly-full disk gets a low-level write failure partway through an install rather than an upfront "you need N GB free".
Verified by searching apps/, crates/, engines/, and xtask/ for available_space, free_space, statvfs, ENOSPC, StorageFull, disk_space, fs2, and nix::sys::statvfs, plus prose variants (no space, out of space, insufficient disk, free disk) — zero hits. Nothing maps ErrorKind::StorageFull to a user-facing message.
sysinfo is already a dependency of crates/rocm-dash-collectors (used for CPU/memory metrics). sysinfo::Disks appears only in a TODO comment at crates/rocm-dash-collectors/src/host.rs:57, so the capability is available but unused.
This is made worse by the fact that a failed write currently leaks its partial file (see the companion issue on orphaned partial downloads), so hitting a full disk both fails the install and permanently consumes the space that was left.
Steps to Reproduce
- On a machine with less free space than the SDK requires, run an SDK install.
- The install begins downloading and fails partway through with a write error, rather than refusing upfront with a space requirement.
Suggested Fix
Check available space before starting a download or extraction and fail early with the required and available amounts. The natural checkpoints are the SDK install paths in apps/rocm/src/therock.rs (the tarball download at line 1062 and the extraction that follows it) and the shared helper download_file_to_path in crates/rocm-core/src/lib.rs:115.
Two details worth deciding:
- Extraction needs headroom well beyond the compressed artifact, so the check should account for the extracted size, not just the download.
Content-Length gives the download size cheaply where the server provides it; the extracted size needs either a manifest value or a conservative multiplier.
It would also help to surface a clear message when a write does fail for lack of space, instead of the raw OS error.
Additional Information
Found while investigating unbounded disk growth from repeated installs.
Problem Description
ROCm CLI starts multi-GB downloads and extractions without ever checking whether there is room for them. There is no free-space check anywhere in the codebase, and no handling of the resulting out-of-space error, so a user with a nearly-full disk gets a low-level write failure partway through an install rather than an upfront "you need N GB free".
Verified by searching
apps/,crates/,engines/, andxtask/foravailable_space,free_space,statvfs,ENOSPC,StorageFull,disk_space,fs2, andnix::sys::statvfs, plus prose variants (no space,out of space,insufficient disk,free disk) — zero hits. Nothing mapsErrorKind::StorageFullto a user-facing message.sysinfois already a dependency ofcrates/rocm-dash-collectors(used for CPU/memory metrics).sysinfo::Disksappears only in a TODO comment atcrates/rocm-dash-collectors/src/host.rs:57, so the capability is available but unused.This is made worse by the fact that a failed write currently leaks its partial file (see the companion issue on orphaned partial downloads), so hitting a full disk both fails the install and permanently consumes the space that was left.
Steps to Reproduce
Suggested Fix
Check available space before starting a download or extraction and fail early with the required and available amounts. The natural checkpoints are the SDK install paths in
apps/rocm/src/therock.rs(the tarball download at line 1062 and the extraction that follows it) and the shared helperdownload_file_to_pathincrates/rocm-core/src/lib.rs:115.Two details worth deciding:
Content-Lengthgives the download size cheaply where the server provides it; the extracted size needs either a manifest value or a conservative multiplier.It would also help to surface a clear message when a write does fail for lack of space, instead of the raw OS error.
Additional Information
Found while investigating unbounded disk growth from repeated installs.