I wrote an extension to file to report the total space and the free space, and got some interesting results.
There is about 120kb free when the file system is first formatted.
Due to wear levelling (I guess), spiffs quickly uses up the free blocks, so you have all the blocks used with only a few pages in use on each one.
As you add files, spiffs looks for a block with free space and writes the file there.
If the block doesn't have enough free pages, spiffs seems to fill up the block and just quit writing the file.
Files can only span a few logical blocks?
So, unless you are using a bunch of 240 byte files, it can be difficult to actually use all that free space.
Now, it is quite possible that I am misunderstanding the data spiffs is providing, but a little bit of experimentation seems to hold up.
If you are interested, this is how I extended file.c in app/modules:
Code: Select allstatic int file_freespace (lua_State *L)
{
lua_pushinteger(L, fs.block_count * fs.cfg.phys_erase_block - fs.stats_p_allocated * fs.cfg.log_page_size);
return 1;
}
static int file_totalspace (lua_State *L)
{
lua_pushinteger(L, fs.block_count * fs.cfg.phys_erase_block);
return 1;
}
It's probably counting logical blocks instead of physical blocks, but it doesn't matter because they are set the same.
Either way, when I got to about half the free space used, I started having trouble writing large files completely. As I added more small files, free space started acting erratically. Maybe the allocated pages include pages marked for deletion. I'll keep trying to get better understanding, but right now, it looks like the file system isn't able to use all the free space it has.
Posted: Thu Feb 12, 2015 12:25 pm