Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

SPIFFs is deprecated #1170

Closed
pille opened this issue Sep 11, 2020 · 8 comments
Closed

SPIFFs is deprecated #1170

pille opened this issue Sep 11, 2020 · 8 comments
Labels
discussion stale This issue will be closed soon because of prolonged inactivity

Comments

@pille
Copy link
Contributor

pille commented Sep 11, 2020

SPIFFs is not being worked on since 2017 and is now deprecated.
there's an almost drop in replacement called LittleFS.
the project should move to the new FS implementation, especially since the upcoming release plans to facilitate the flash more that before.

https://arduino-esp8266.readthedocs.io/en/latest/filesystem.html#spiffs-deprecation-warning

@pille pille added the bug label Sep 11, 2020
@pbolduc
Copy link
Contributor

pbolduc commented Sep 12, 2020

Sorry, I dont agree with the label of bug. I would think this issue is more of an enhancement. The page you reference says SPIFFs is deprecated. This means we should move off of it, not that it is no implemented correctly.

@pbolduc
Copy link
Contributor

pbolduc commented Sep 12, 2020

They share a compatible API but have incompatible on-flash implementations, so it is important to choose one or the per project as attempting to mount a SPIFFS volume under LittleFS may result in a format operation and definitely will not preserve any files, and vice-versa.

This makes it difficult to migrate to without having a backup and restore function. If a new version of WLED moved to LittleFS, then the saved data on the flash file system would be lost. When people upgrade versions they dont expect their settings to be lost.

The actual File and Dir objects returned from either filesystem behave in the same manner and documentation is applicable to both. To convert most applications from SPIFFS to LittleFS simply requires changing the SPIFFS.begin() to LittleFS.begin() and SPIFFS.open() to LittleFS.open() with the rest of the code remaining untouched.

This is promising as the code required to change should be minimal.

@Aircoookie Aircoookie added discussion and removed bug labels Sep 12, 2020
@Aircoookie
Copy link
Owner

Aircoookie commented Sep 12, 2020

Thank you for bringing up this point. I agree that we should try to avoid SPIFFS since deprecation is not done lightly, the core developers have their reasons. Running un-maintained code with lots of documented, but unfixed issues could prove to be highly detrimental in the long run. 0.11.0 is the first WLED version that will utilize the Filesystem to a significant degree.

Currently I am working on storing Presets in FS and the code works flawlessly with both filesystems from the limited testing I've done so far.

The often mentioned benefit of LittleFS being faster is not something I can necessarily confirm - the operations used to add a new preset are 120ms on average running LittleFS instead of 25ms with SPIFFS but as long as any operation stays below 500ms we should be fine either way!

On ESP32 it is a different story since there is no LittleFS support built into the core yet (but it could be coming soon!), but if possible I want to use LittleFS by default on both platforms since I regard it as more future proof and I do not want to have to migrate to an incompatible filesystem down the line. Manual backup/restore via the filesystem /edit page is easy enough but a major inconvenience if necessary for updating multiple units.

@pille
Copy link
Contributor Author

pille commented Sep 12, 2020

just wanted to bring this topic up, before you release FS support.
i already saw your future-proof WLED_FS definition 😉

@lorol
Copy link

lorol commented Sep 13, 2020

You can try to plug https://github.com/lorol/LITTLEFS while waiting for blessed esp32 support within IDF and Arduino esp32 core. PlatformIO projects can also use it with little tweaks.
rjwats/esp8266-react#197

The functional difference with esp8266' LittleFS "folderless-SPIFFS-like" implementation is an eventual need to iterate and create/delete folders at application, on file creation and deletion if you want to use old code made for SPIFFS. But this can be done on later revisions if absolutely required.

@pfeerick
Copy link
Contributor

Until (and if, since their reason for not following the ESP8266 core is that the ESPIDF natively supports SPIFFS) the ESP32-Arduino gods depreciate SPIFFs, I don't see any real reason to use LittleFS over there - or can you make a data partition blob that can be flashed on both an ESP8266 and an ESP32? If that were the case, that alone would be a good reason to switch, especially not. Regardless, it is a good idea to use LittleFS on the ESP8266 now, since this is effectively new code and SPIFFS is depreciated, and AFAIK will be pulled in v3 of the ESP8266-Arduino core. Sticking with SPIFFS there will only result in later headaches, so better small ones now than bigger ones later!

@lorol
Copy link

lorol commented Sep 20, 2020

Too many useless words from your and my side.
Yes, l provided a mean to make and flash a data to LittleFS partition. The driver is through IDF and it is as much native as it could be at all. Just test you wish.

@stale
Copy link

stale bot commented Jan 18, 2021

Hey! This issue has been open for quite some time without any new comments now. It will be closed automatically in a week if no further activity occurs.
Thank you for using WLED!

@stale stale bot added the stale This issue will be closed soon because of prolonged inactivity label Jan 18, 2021
@stale stale bot closed this as completed Jan 25, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
discussion stale This issue will be closed soon because of prolonged inactivity
Projects
None yet
Development

No branches or pull requests

5 participants