vrunkel
Request: Stress Test Mode
Fantastic work! It's great to have an F3X app on modern MacOS versions. I do miss the F3X UI though.
My request... add a 'stress test' option, looping the write/read operation to a set duration (time) or count (number of loops).
Thank you!
Since flash memory storage has a relative fixed life - and comparatively small, though better than in recent years - any such test would have to bebe accompanied by a huge number of "this may shorten the life of your device" blinking confirmations.
Wear leveling and devices that have embedded microcontrollers to disperse the write traffic over a larger number of cells can (and does) help, but on a full-ish card, there are only so may places that stress-tested data can go and it can leave a battle scar on the device. Newer generations also make it easier to "hide" a spare percentage of safe cells that can be brought out if needed. (This is why we have so many 400MB drives when you know full well the memory chips are sized at 512MB, for example.)
A good SLC device with good firmware can have write cycles of hundreds of thousands of cycles. A terrible TLC device can have life cycles ranging in the hundreds of cycles. Just spinning through a loop updating every card on the device (a "stress test") could easily destroy the device in an afternoon.
If you're a manufacturer using F3XSwift to test cards fro manufacturing cycles, it's important that someone stress-test a representative sample to see where they die. If you're an independent reviewer looking to see if the devices meet the published specs (and we need this, too.) then sacrificing your cards/devices in the name of science can be OK Doining it to the Photos directory of someone's $1200 phone that doesn't have replaceable memory is just irresponsible.
Should this project try to nanny users from destroying their devices? {shrug} Should it make it easy to destroy devices that are embedded in someone else's hardware? Not so sure.
Instead of a "hammer the card/drive until it dies" mode, I'd find a much more useful mode to be to graph the speed of writes over the (single) session you're testing. Knowing that it accepts X MB/sec in the early writes when caching is easy, but only .1X when it has to actually touch silicon is quite useful. A simple graph of the existing test would be handy.
So while I'm not a developer on this project, I'd be terrified to implement an actual stress test mode because the life cycles of these devices is such that you can easily permanently destroy many devices in the target hardware pool. I'd absolutely consult legal for an indemnification clause that would ensure that I wouldn't be held liable for accelerating the demise of a customer's hardware.
"It's complicated."
