Discussion:
LittleFS - A high-integrity embedded file system
(too old to reply)
avyhovanec@yahoo.com [nuttx]
2018-01-03 14:34:26 UTC
Permalink
Hi, All.
I find this fs very promising. And i'm thinking about porting this FS to NuttX. At least for my project based on NuttX. Is it still interesting to someone?

https://os.mbed.com/blog/entry/littlefs-high-integrity-embedded-fs/ https://os.mbed.com/blog/entry/littlefs-high-integrity-embedded-fs/
Sebastien Lorquet sebastien@lorquet.fr [nuttx]
2018-01-03 14:52:27 UTC
Permalink
hello,

I find this interesting, here are some details

-we already have SmartFS, did you try it? Not a problem, FS competition is good.

-If you plan to port code, you have to make sure 1 - it fits the NuttX licence
and coding style, or 2 - you have to remplement it yourself. I strongly support
the second option, a port is not enough, as Greg will not maintain a fork of a
live project inside the source tree. Reimplementing the FS is a good way to find
bugs and check interoperability.

-we will probably want host tools to deal with FS images in this format

I am looking forward to test, I have a serious NuttX based board in the works,
and I will need a solid flash filesystem.

Sebastien
Post by ***@yahoo.com [nuttx]
 
Hi, All.
I find this fs very promising. And i'm thinking about porting this FS to
NuttX. At least for my project based on NuttX. Is it still interesting to someone?
https://os.mbed.com/blog/entry/littlefs-high-integrity-embedded-fs/
Sebastien Lorquet sebastien@lorquet.fr [nuttx]
2018-01-03 15:09:12 UTC
Permalink
Here is a design document
https://github.com/ARMmbed/mbed-os/blob/master/features/filesystem/littlefs/littlefs/DESIGN.md

Here is the disk format specification
https://github.com/ARMmbed/mbed-os/blob/master/features/filesystem/littlefs/littlefs/SPEC.md

Looks like we have enough to reimplement!


Supporting an mbed file system is good, this means mbed users have a migration
path to nuttx!


In the past I had some ideas to implement a flash file system with wear leveling
and power loss resilience, the idea was a mapping of virtual sectors with a
revision, not totally unlike this mbed idea.

What they made better than me is the integration of file system structure. I was
just trying to provide a solid "wear leveled block device" and have any other
file system on top, which is less optimal. One other problem was that I needed a
lot of RAM to implement the FS efficiently.


Sebastien
Post by Sebastien Lorquet ***@lorquet.fr [nuttx]
 
hello,
I find this interesting, here are some details
-we already have SmartFS, did you try it? Not a problem, FS competition is good.
-If you plan to port code, you have to make sure 1 - it fits the NuttX licence
and coding style, or 2 - you have to remplement it yourself. I strongly
support the second option, a port is not enough, as Greg will not maintain a
fork of a live project inside the source tree. Reimplementing the FS is a good
way to find bugs and check interoperability.
-we will probably want host tools to deal with FS images in this format
I am looking forward to test, I have a serious NuttX based board in the works,
and I will need a solid flash filesystem.
Sebastien
Post by ***@yahoo.com [nuttx]
 
Hi, All.
I find this fs very promising. And i'm thinking about porting this FS to
NuttX. At least for my project based on NuttX. Is it still interesting to someone?
https://os.mbed.com/blog/entry/littlefs-high-integrity-embedded-fs/
spudarnia@yahoo.com [nuttx]
2018-01-03 15:30:27 UTC
Permalink
Any version of LittleFS that works with the NuttX VFS will certainly be a different design. Whether you start with a Snapshot of LittleFS or re-implement from specification as Sebastien suggests. Either is a complete break from mbed.


So in this case, I am less concerned about a fork in the NuttX repository: There will never be updates; no bug fixes or enhancements from mbed will every be brought in. It becomes a maintenance responsibility of the NuttX community. [I personally will not support it. I have enough on my plate. So I hope you would also be signing up for lifetime support].


Sebastien is correct that any code brought in must be 100% compatible with the NuttX coding style or it will be declined. So don't waste any effort on this unless you are willing to take that on. There is a crappy tool at tools/indent.sh that might help. I also don't mind putting code a branch and helping you with interface and code compatibility issues before merging to master.


The other issue is licensing. All of the mbed code uses the Apache license which is not 100% compatible with the NuttX BSD license. Both are free and open licenses but with subtle differences. The biggest is that the Apache license is long and written in incomprehensible legal-ese so I don't think anyone really knows what it says... not until you end up on court due to a license violation and the judge carefully explains it to you.


So the long term difference between taking a snaphot and re-implementing from specs is the license. I advertise NuttX as a BSD licensed OS and so I cannot include incompatibly licensed code like Apache.


I have been thinking about adding a configuration option that would permit inclusion of Apache licensed code. So you would do 'make menuconfig', select Apache licensing, swear an oath, then you could mix apache code with NuttX.


There are other motivations to do this: Then we could include the Samsung Journaling enhancement to SmartFS (Apache) and we could include the MyNewt Bluetooth BLE stack (nimBLE).


Greg
Sebastien Lorquet sebastien@lorquet.fr [nuttx]
2018-01-03 15:41:47 UTC
Permalink
Reading through the docs, it seems that this filesystem is cleverly designed,
and the resistance to power loss is a VERY desirable feature for an embedded
system. It is also using a limited amount of RAM, which is interesting.

To avoid any licence issue, I also agree that the only option is to reimplement
it from scratch.

I would be willing to get involved, but only if I am not dealing with this
alone, because I have family occupations and cannot guarantee a 24/7 maintenance
effort.

The timeframe is great, since I am starting the board port for my hn70ap board (
https://github.com/f4grx/hn70ap ).

Sebastien
Post by ***@yahoo.com [nuttx]
 
Any version of LittleFS that works with the NuttX VFS will certainly be a
different design.  Whether you start with a Snapshot of LittleFS or
re-implement from specification as Sebastien suggests.  Either is a complete
break from mbed.
So in this case, I am less concerned about a fork in the NuttX repository: 
There will never be updates; no bug fixes or enhancements from mbed will every
be brought in.  It becomes a maintenance responsibility of the NuttX
community.  [I personally will not support it.  I have enough on my plate.  So
I hope you would also be signing up for lifetime support].
Sebastien is correct that any code brought in must be 100% compatible with the
NuttX coding style or it will be declined.  So don't waste any effort on this
unless you are willing to take that on.  There is a crappy tool at
tools/indent.sh that might help.  I also don't mind putting code a branch and
helping you with interface and code compatibility issues before merging to master.
The other issue is licensing.  All of the mbed code uses the Apache license
which is not 100% compatible with the NuttX BSD license.  Both are free and
open licenses but with subtle differences.  The biggest is that the Apache
license is long and written in incomprehensible legal-ese so I don't think
anyone really knows what it says... not until you end up on court due to a
license violation and the judge carefully explains it to you.
So the long term difference between taking a snaphot and re-implementing from
specs is the license.  I advertise NuttX as a BSD licensed OS and so I cannot
include incompatibly licensed code like Apache.
I have been thinking about adding a configuration option that would permit
inclusion of Apache licensed code.  So you would do 'make menuconfig', select
Apache licensing, swear an oath, then you could mix apache code with NuttX.
There are other motivations to do this:  Then we could include the Samsung
Journaling enhancement to SmartFS (Apache) and we could include the MyNewt
Bluetooth BLE stack (nimBLE).
Greg
Continue reading on narkive:
Loading...