spiffs_gc(fs, total - used) returns ERR_FULL
I'm looking for an easy way to GC (erase) all the currently free pages. Reason: i want to really wipe the data of the file(s) that have just been deleted (which may include sensitive data, like credentials).
SPIFFS_gc requires the amount of space desired, and since i want all the free space wiped out i just do this:
u32_t total, used;
SPIFFS_info(&fs, &total, &used);
int r = SPIFFS_gc(&fs, total - used);
LOG(LL_INFO, ("total %d used %d => r %d e %d", total, used, r, SPIFFS_errno(&fs)));
however, the result is ERR_FULL:
total 113201 used 21586 => r -10001 e -10001
i need to subtract a couple pages for GC to actually work. this should not be the case, GC should not give up when passed total - used and wipe every free page.
Hi, ah yes, that is a known "feature". The user calling of gc was a bit experimental to start with, but I admit above should work. It might have to do with that spiffs always need two blocks free. I need to check up the code a bit. I'll be back.
@rojer, just thinking here. Would it be valuable with an extra flag when creating files marking them as sensitive - where a delete would actually write 0 to all data of that file? It would be semi safe of course, if power is lost in the middle of a delete. Hmm...
i think instead a special call, remove_and_erase or some such (imagination is failing me at the moment). which would basically combine remove and gc of the specific blocks used by the file.
(in that sense "overwriting" with 0xff sounds better - it doesn't matter what the byte value is, but 0xff is good because it is free space, basically).
On 15/03/2017 06:01, Deomid Ryabkov wrote:
i think instead a special call, |remove_and_erase| or some such (imagination is failing me at the moment). which would basically combine remove and gc of the specific blocks used by the file. (in that sense "overwriting" with 0xff sounds better - it doesn't matter what the byte value is, but 0xff is good because it is free space, basically).
You could overwrite with all 0x00 as that wouldn't require any GC at all.....
will the data go into the same pages though? i thought they will be relocated
On 15/03/2017 09:58, Deomid Ryabkov wrote:
will the data go into the same pages though? i thought they will be relocated
no -- you can't do the writing, but the spiffs layer could (with a new API -- or even a new open mode)
yep, either would be fine with me. i can open("foo", O_I_KNOW_WHAT_IM_DOING_DO_NOT_RELOCATE_ON_WRITING), then just write zeroes and remove()
I'd prefer a special O_ I think. O_OVERWRITE maybe, unless someone else comes up with a more explanatory name.
what? you don't like O_I_KNOW_WHAT_IM_DOING_DO_NOT_RELOCATE_ON_WRITING? :)
O_OVERWRITE SGTM.
still, making spiffs_gc work with total - used should be done, it's confusing as it is now.
Lol! I try to keep column size below 80 you know 😉 Agree, I need to have a peek on that. I cannot remember the details now, but I think there's a problem lurching around there somewhere.