A typical storage device finishes the benchmark in under 10 seconds,
but some extremely slow devices can take minutes, resulting in a
confusing UX that looks like we've frozen. Even worse, we keep
churning through all that I/O even though we know the device will
blow past our user-warning threshold.
So periodically check if we've timed out, and also use that to report
progress up into the Settings UI.
Test: manual
Bug: 62201209, 65639764, 67055204
Change-Id: I321397bcff230976f034cede0947d4a5a1f3e8a7
This had minimal impact on the results, since 95% of the writes were
performed through pwrite(), but it's important to fix this for future
benchmark suites.
Bug: 29759783
Change-Id: Ic628aab98b9f9def78508cc722899afdefed84ae
If we always write zeros, we're leaving a giant pile of known
plaintext at an almost deterministic location on newly formatted
volumes. To avoid this, repeat a 64K chunk of random data.
Bug: 22816936
Change-Id: Iedc067a519bd676a93b9d74ea4f9f77c84c8461c
Now that we're offering to store private app data on adopted storage
devices, the performance of those devices is much more important to
overall user experience.
To help set user expectations, this change offers to execute a
real-world benchmark on a storage device, returning a metric that can
be used to compare internal and external storage. The benchmark is
generated from the strace-instrumented storage access patterns of
typical apps.
A typical device completes the benchmark in under two seconds on
internal storage, a UHS-3 SD card is even faster (!), but a very slow
Class 4 SD card takes about 30 seconds to complete, giving us a clear
signal.
The measured benchmark numbers are logged along with information
about the storage device, such as manufacturer, model, etc. Card
serial numbers are scrubbed from output.
Bug: 21172095
Change-Id: I9b2713dafdfdfcf5d97bf1bc21841f39409a7e54
Jeff Sharkey
George Burgess IV
Elliott Hughes