ESP32 Forum

Hello,
I am facing some odd issue in using SPIFFS with library provided by Loboris under
https://github.com/loboris/ESP32_spiffs_example

My SPIFFS operation flow is as below,
-> Created 3 files, taking name here as file1.txt, file2.txt and file3.txt with creating 3 task task1, task2 and task3 in app_main().
-> In each task, previously created file is opened (file1.txt, file2.txt and file3.txt are opened in task1, task2 and task3 respectively) in write mode, then write data and closed file. After writing data each file in their respective task is opened in read mode and then closed. As shown below snippet

task1()
{
while(1)
{
open file1 in write mode
close file1
open file1 in read mode
close file1
}
}
same way for task2 and task3.

-> In task1 directory files list is also printed using readdir().
-> Same operations of read and write as mentioned above is performed continuously in while(1) in each task.
-> Now the issue is, after few numbers of operations (which is very random,taking 300 to 400 average) file3.txt (taking for example) could not opened.
Strange thing here is in files list printed at that time of open error using readdir() is as below,

file1.txt
file2.txt
file2.txt
which should be file1.txt, file2.txt and file3.txt instead.
How is that happened...???

file3.txt is replaced with file2.txt, so could not open file3.txt and error code of spiffs_open() is -10023 (SPIFFS_ERR_CONFLICTING_NAME).
After that all operations of opening file3.txt got failed, Obviously because it is some how removed unexpectedly.

Have anybody any idea about this..?

For debugging I performed another tests by removing write operations, so in task while loop only continuous read operation will be performed. Same way test is also performed by doing only write operations.
In this, only write operation created this issue. It replaces file3.txt with file2.txt.

I tried these task operations by making them in critical section, but it does not work either.

Can anybody give some idea about this issue.. Hope I have explained it properly.

Thanks.

Hello,
Have any one got the same issue. Little help will be appreciated.

Thanks.

Hello,
I did a test in which only file write operations was performed in each task. It created the same issue, while in another test only file read operations was performed continuously in multiple tasks. These continuous read operations did not create any issues.

So I guess continuous file write operations creating this issue.

Anyone any guesses..??

Thanks.

Hi Loboris,

Would you please check above issue and provide your valuable comments we we are facing this issue since last few days?

Let me know if you need any more details or any further details regarding this issue which we are facing this issue into ESP32.

I must admit I have forgotten to enable the LOCK/UNLOCK (mutex) support (which does exists in spiffs) to make the spiffs operations thread safe.
Tomorow I'll make some test and push the update to GitHub.
Sorry for this oversight.

The SPIFFS GitHub repository is now updated.

• SPIFFS LOCK/UNLOCK (mutex) added to make spiffs operations thread safe
• MultiTask test added to example application

If you are using spiffs in some other projects, please copy spiffs directory from this repository to your project.
Only the files spiffs_vfs.c and spiffs_config.h are changed.

Hi Loboris,

Thanks for quick update

I will check it with example on Monday Morning and will update to you that it is working or not.

Did you check with multiple tasks with multiple files in long stress test on your updated SPIFFS repository?

We are getting problem in stress test like 1 to 2 hours test otherwise normal test was working without any issue. We have also checked that when we faced this issue at that time memory is still available and no any issue with that.

Anyway, I will update to you after checking your updated repository.

Thanks again for your support and update for that.

Hi Loboris

I have checked your updated SPIFFS library from GitHub and tested basic and overnight test cases which works fine without any issue.

So, Thanks for providing update for that.