-
@fanoush - looks like @Gordon has found the issue.
My point was that writing the same file size back after a deletion would not result in fragmentation. The fragmenter stress test app needed to start with a file of say 500 bytes, (maybe packed with spaces on the end), then write it back with a smaller size (say 480 bytes). This then maroons 20 bytes that have to be tracked. Repeat multiple times with different app files that are shrunk and then expanded and you would fragment the storage.
@Gordon, great news, will update my firmware and try it out.
HughB-
The fragmenter needed to start with a file of say 500 bytes, (maybe packed with spaces on the end), then write it back with a smaller size (say 480 bytes). This then maroons 20 bytes that have to be tracked.
if you write file with 500 bytes, then 'overwrite' it with 480 bytes you end with 500 bytes of (tracked) dead space + 480 bytes of newly allocated space because nothing is reclaimed until you fill everything and/or compact
fanoush
You don't do that. That's why the compact is there. You can't write to same place twice without block erase. So you always write to 'new' erased space. And once you are out of it you start erasing to reclaim dead space and fill it again with valid data next to each other. then you end with one free erased area and continue until it is filled again. Or did I miss your point? Could be.
What I mean is that https://www.espruino.com/Reference#l_Storage_erase just marks dead space which is unusable until you do
compact()