<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">I just came across this on MickMake: The little filesystem (<a href="https://github.com/geky/littlefs" class="">https://github.com/geky/littlefs</a>)<div class=""><br class=""><div class="">Seems to have support for the most important things like directories (I think), wear leveling, power-loss handling and they claim a low RAM and ROM footprint.</div><div class="">Also it seems to do a great better than SPIFFS when it comes to performance: <a href="https://github.com/RIOT-OS/RIOT/pull/8316" class="">https://github.com/RIOT-OS/RIOT/pull/8316</a></div><div class=""><br class=""></div><div class="">Could it be an alternative?</div><div class=""><br class=""></div><div class="">Best regards,</div><div class="">Geir<br class=""><div><br class=""><blockquote type="cite" class=""><div class="">22. jan. 2018 kl. 04:16 skrev Mark Webb-Johnson <<a href="mailto:mark@webb-johnson.net" class="">mark@webb-johnson.net</a>>:</div><br class="Apple-interchange-newline"><div class=""><div class=""><blockquote type="cite" class="">I’d like to see some sort of wear leveling, although the nature of log files is that they might be nearly ideal for wear leveling. It’s the non-log settings files that are more of a challenge.<br class=""></blockquote><br class="">The current system we use is FAT over a wear-levelling layer (using same 4KB block size as the FAT layer, for simplicity).<br class=""><br class=""><blockquote type="cite" class="">How many files are we talking about? A flat (non-directory) structure might not be so bad with only a few files.<br class=""></blockquote><br class="">Not too many. Part of it is the user config, which we want to keep separate from generic user data. Using directories makes that simple.<br class=""><br class="">Regards, Mark.<br class=""><br class=""><blockquote type="cite" class="">On 21 Jan 2018, at 7:17 AM, HONDA S-2000 <<a href="mailto:s2000@audiobanshee.com" class="">s2000@audiobanshee.com</a>> wrote:<br class=""><br class="">My quick reaction on the second caveat is: How can any Flash file system be real-time? Flash writes that span blocks take longer than those that don’t. The only solution is RAM buffering and threading, but those have their impacts on embedded systems due to limited RAM and limited CPU for threads.<br class=""><br class="">I’ve used JFFS2 on Linux, but that’s hardly a real-time situation, even though we were getting near-real-time performance. Seems like JFFS2 might be too complex, unless it is built in layers where we could perhaps shed the high-level Posix features and just borrow the low-level, Flash-specific features.<br class=""><br class="">All in all, SPIFFS does seem a bit limited. However, FAT is rather limited by today’s standards…<br class=""><br class="">I’d like to see some sort of wear leveling, although the nature of log files is that they might be nearly ideal for wear leveling. It’s the non-log settings files that are more of a challenge.<br class=""><br class="">How many files are we talking about? A flat (non-directory) structure might not be so bad with only a few files.<br class=""><br class="">Brian<br class=""><br class=""><br class="">On Jan 19, 2018, at 10:32 AM, Greg D. <<a href="mailto:gregd2350@gmail.com" class="">gregd2350@gmail.com</a>> wrote:<br class=""><blockquote type="cite" class="">Yeah, that seems like a killer. Wear-leveled FAT, it is. They don't support something like JFFS2, do they? Probably overkill...<br class=""><br class="">Greg<br class=""><br class="">Mark Webb-Johnson wrote:<br class=""><blockquote type="cite" class="">OK, I looked into this is more detail…<br class=""><br class="">Notes<br class=""><br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>• Presently, spiffs does not support directories. It produces a flat structure. If SPIFFS is mounted under /spiffs creating a file with path /spiffs/tmp/myfile.txt will create a file called /tmp/myfile.txt in SPIFFS, instead of myfile.txt under directory /spiffs/tmp.<br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>• It is not a realtime stack. One write operation might last much longer than another.<br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>• Presently, it does not detect or handle bad blocks.<br class="">Maybe not… It seems that for our use-case, the wear levelled FAT maybe more suitable.<br class=""><br class="">Mark<br class=""><br class="">Mark Webb-Johnson wrote:<br class=""><blockquote type="cite" class="">ESP IDF 2.1 only had FAT support as a filesystem. We used this for the /store vfs mount, for config and script storage.<br class=""><br class="">ESP IDF 3.x now has SPIFFS as an option.<br class=""><br class="">SPIFFS is obviously more suited to embedded flash.<br class=""><br class="">What do people think about making the switch to SPIFFS for /store now?<br class=""><br class="">Doing so would probably not be hard (just a few lines of code change in the mounting of that /store partition), but would lose all config and script data in that partition (developers would have to disable vfs protection in menuconfig, then scp out first, to backup).<br class=""><br class="">Doing it later is not really an option.<br class=""><br class="">Thoughts?<br class=""><br class="">Mark<br class=""></blockquote></blockquote></blockquote><br class="">_______________________________________________<br class="">OvmsDev mailing list<br class=""><a href="mailto:OvmsDev@lists.teslaclub.hk" class="">OvmsDev@lists.teslaclub.hk</a><br class="">http://lists.teslaclub.hk/mailman/listinfo/ovmsdev<br class=""></blockquote><br class="">_______________________________________________<br class="">OvmsDev mailing list<br class=""><a href="mailto:OvmsDev@lists.teslaclub.hk" class="">OvmsDev@lists.teslaclub.hk</a><br class="">http://lists.teslaclub.hk/mailman/listinfo/ovmsdev<br class=""></div></div></blockquote></div><br class=""></div></div></body></html>