ER StorProof

Write-and-verify creates test files in a selected directory, fills the chosen range, synchronizes and reopens the files, then compares every byte against the generated test data. It records errors and completed coverage. Separate write-only tasks and re-verification of retained test data are also available. Resumable write-and-verify uses a separate progress record and fully rechecks committed data when resumed.

Tests operate only on their own numbered regular files. New files are created exclusively, refusing existing names; explicitly reusing test data for write benchmarks will change that data. There is no raw-device writing or formatting. Writing still consumes free space and adds wear, so check the target, test size, and space reserve before starting. Command-line write tests use available space when no size is specified; choose an explicit range for a first test.

Benchmarks cover sequential, random, and mixed reads and writes. Standard mode transfers a fixed amount of data; time-based mode repeatedly accesses a working set within a measurement window; write-based mode combines fixed-volume writes with repeated reads. Throughput, IOPS, latency, and speed charts reveal how performance changes with the workload.

Working-set size is not total write volume: preparation, warm-up, and repeated measurements also generate traffic. Compare results with consistent sizes, workloads, cache policies, and environments. Bypassing the operating system’s file cache does not establish that device or virtual-machine host caches were bypassed, and scores from different tools are not directly comparable. A completed benchmark is not an integrity pass.

Burn-in combines file patterns such as sequences, random seeking, fixed bytes, and random data. The complete-cycle preset runs its required patterns in sequence. Verified soak initializes and verifies the working set, runs random requests with content comparison, then reopens the files for a full final check.

Factory file-cycle presets size test segments as a percentage of volume capacity and stop after a specified number of write/read cycles. Reaching that count does not mean every data pattern has been covered. Preview the range, cycles, and estimated traffic before starting. Cancellation and timeout are not normal completion, and burn-in cannot currently resume from a checkpoint.

Core provides the shared testing capabilities. For an individual check, choose a directory, task, and size in the terminal, preview the plan, and start. Automation can use JSON or programmatic interfaces. The same task keeps the same test logic and result semantics across these entry points.

Workbench brings target selection, recipes, preflight checks, start and stop controls, live monitoring, and results into a desktop workflow, with connections to remote test nodes. Recipes and target sets can be reused, with a new preflight required after changes. Node resources and volume constraints limit concurrency, and tasks on the same logical volume run serially. Automatic thermal control, formatting, and full production-line acceptance are not currently available.

Results distinguish a verified selected range, unverified writes, a completed benchmark, and a completed burn-in. Missing or truncated data within a known range, content errors, and cancellation cannot count as a pass. Automatic discovery verifies only the files present; checking the original full range requires an explicit size or a saved plan. Results can be exported and viewed offline. Supported device paths can also provide temperature, wear, or error information; missing data stays unknown. A pass does not prove full-drive capacity, power-loss persistence, or long-term reliability.

Core targets macOS, Windows, Linux, and Android; Workbench targets macOS, Windows 10+, and Ubuntu 24.04 desktops. Android currently requires a directory directly accessible through Termux or ADB, without a native mobile app or Android system document-picker integration. Architecture, filesystem, permissions, and device-health access must each be checked for the intended setup.