Quote:
Originally Posted by Toni Wilen
- Fill the partition (optional parameter: how much to fill) with random size files (optional parameter: min and max size) with random contents (so that if some data block overwrites other file's block, checksum must be guaranteed changed). Checksum must be calculated from original generated data. Must be much better algorithm than CRC-32! Must stop immediately if error detected.
- After partition has been filled, each file must be read and checksum calculated. All checksums must match 100%.
- Then randomly chosen files should be deleted and new random size files generated (with same checksum generation as in first step)
- Repeat (stop with Control-C)
File size/name random generator should use user given seed value parameter so that exact same test can be replicated.
It does not matter if disk isn't 100% filled, it isn't important. Important test case is to guarantee nothing gets corrupted (or filesystem crash) when creating/reading/deleting files.
EDIT: Also some way to only rewrite existing file partially would be nice to have but it can make checksumming more complex.
Program must work even if more than one instance is running simultaneously (to simulate multiple programs doing disk accesses at the same time). Must work even if both are using same path = file names should not have collisions.
Also very important: must runnable from CLI, (no GUI!), all messages must be written to standard output.
Obviously I run it in emulation for best (disk) performance.
(Don't discuss pointless stuff like "writing too much". It does not happen, even with SSD. Unless you do continuous writing at max speed for a year or more.)
|
Thanks for input Toni. I like the pseudo main loop you described as it's more refined than my immediate thoughts.
For tools like this I agree with NO GUI. CLI is best choice for script-able and reproducible testing with standard output messages so it can be shown or redirected to a file, e.g >PC:log.txt.
I would also run it using emulation for best performance and being able to stress it further than I would be able to with real hardware. It would still be interesting to test with real hardware.
I'm very tempted to get started writing such a filesystem test tool and put it on a github for any one interested.
This might also be the time where I start investigating and use modern Amiga cross compilers for Windows instead of using eg. SAS/C in AmigaOS.