SPIFFS_USE_MAGIC checking filesystem about spiffs HOT 8 CLOSED

Yes, you're correct in your reasoning. Creating an fs with e.g 32 blocks
and then mount it with 16 blocks at a later point would succeed at mount
point. However, if all 32 blocks contain data, the fs mounted with 16
would most certainly be corrupt, giving errors when reading and writing.
In fact, it might be impossible to do anything as spiffs must have at
least two blocks free.
Den 19 nov 2015 17:58 skrev "hreintke" [email protected]:

When mounting a FS with the the SPIFFS_USE_MAGIC set to 1, is then only
checked whether all blocks within the "FS range" having a magic number ?

If so, would you detect a failure when FS is created with size 1000 and
mounted with size 500 ?

If I missed the documentation for this, please point me to the location
and I will work from that.

—
Reply to this email directly or view it on GitHub
#59.

from spiffs.

Btw, just out of curiosity, is there an actual case of this? I always presumed the user would know the size of the fs.
(Damn it's hard answering issues on the mobile with swedish autocorrection 😉)

from spiffs.

Thanks for the quick answer.

I am working on the sming framework for esp8266.
In there, there is the possibility to

• download (Over The Air) a pre-filled filesystem to the esp.
• when flashing the application,on the esp, a FS can also be flashed over serial.
• and of course, esp8266 come with different flash sizes, I would like to keep the application the same on all.

This means that the application using the FS is not the same as the application which created it.
-> There might be a mismatch

I was wondering whether it would be possible to have a :

• first page magic number
• middle pages magic number
• last page magic number

And so create an almost no overhead possibility to check FS size.

I am (not yet) into the details of Spiffs implementation. Could you point me to the part of the code I should be investigating for this.

from spiffs.

Hmm, yes, it would be possible to have certain magics depending on block placement. But, it is a bit trickier than that: among all blocks, spiffs allow one block to have no magic. This is for the case of power-loss during block erase. If such a block is found during mount, it is properly erased and magic is written.

In worst case, this could be the first or the last block, confusing a naive algorithm.

You'll find the code for this @ https://github.com/pellepl/spiffs/blob/master/src/spiffs_nucleus.c#L290

Alas, I am certainly no expert on the Sming framework, but perhaps it is possible to write the fs-size on some other place in the SPI-flash instead, e.g. some parameter/config area?

from spiffs.

Yes, sure there are also other possibilities, f.e. the config area you mentioned.
I am now in the investigation phase, and as such also understanding the possibilities of the frameworks we use.

One more question :

If such a block is found during mount, it is properly erased and magic is written.

Doesn't this way of working break FS consistency, or can you recreate the contents from other locations?

from spiffs.

When spiffs finds one block not being properly erased it assumes this was due to an aborted garbage collection. Spiffs only erases a block when any essential info has been moved (or a user calls format).

So, I really hope it does not break anything ;)

When spiffs finds more than one block not being properly erased, it assumes corrupt filesystem and formats the lot.

Oh, and by properly erased it means the magic is found in the block. Spiffs always writes the magic directly after it erased a block.

Considering unexpected power losses, erasing is the most time consuming operation, so it should statistically be more prone to be aborted.

from spiffs.

Great and well thought design and implementation.

Will close the issue and continue with my design investigation.

Thanks a lot for answering my questions so quickly and extensive.

from spiffs.

Thanks. Don't hesitate to ask if you have more questions. Cheers!

from spiffs.