Sebastien Lorquet sebastien@lorquet.fr [nuttx]
2018-03-27 20:06:50 UTC
Hello
Ensuring data has been written to disk in proper order is a typical
requirement of embedded platforms.
It is not usually the case on normal desktop/server platforms, where
performance and caching is more important than actual non volatile
storage device access, in order to reduce IO operations and improve disk
throughput.
That's why, in embedded devices, we need file systems that ensure this
device consistency as best as possible. This is a responsibility of the
filesystem, not of the C language.
That's also why FAT family filesystems (and SD cards) are a total
nonsense in embedded devices where power can be shut down without any
warning or backup power.
SmartFS attempts to go in this direction but I am not aware of the
offered consistency guarantees.
littlefs from mbedOS was promising in this domain by promising atomic FS
updates as well as wear leveling, but I lack time and no one offered to
reimplement it for nuttx. Specs are available.
Sebastien
Ensuring data has been written to disk in proper order is a typical
requirement of embedded platforms.
It is not usually the case on normal desktop/server platforms, where
performance and caching is more important than actual non volatile
storage device access, in order to reduce IO operations and improve disk
throughput.
That's why, in embedded devices, we need file systems that ensure this
device consistency as best as possible. This is a responsibility of the
filesystem, not of the C language.
That's also why FAT family filesystems (and SD cards) are a total
nonsense in embedded devices where power can be shut down without any
warning or backup power.
SmartFS attempts to go in this direction but I am not aware of the
offered consistency guarantees.
littlefs from mbedOS was promising in this domain by promising atomic FS
updates as well as wear leveling, but I lack time and no one offered to
reimplement it for nuttx. Specs are available.
Sebastien
Well Greg, no surprise that you were right;)
For future refference from fsync(2)
indeed on SD card after power lose. Looks like I have to addÂ
parameter "how many bytes of data are you willing to lose";) and
manually call fsync after that ammount of data has been stored.
Thanks for fixing me Greg!
Too bad there isn't pure c89 sollution and one needs to use OS
specific functions.
Well... I guess I can always close and reopen file.
--
You received this message because you are subscribed to the Google
Groups "NuttX" group.
To unsubscribe from this group and stop receiving emails from it, send
For more options, visit https://groups.google.com/d/optout.
For future refference from fsync(2)
 As well as flushing the file data, fsync() also flushes
the metadata information associated with the file
But also as word of warningthe metadata information associated with the file
 Calling fsync() does not necessarily ensure that the entry in
the directory containing the file has also reached disk. For
that an explicit fsync() on a file descriptor for the directoryÂ
is also needed.
But in nuttx it seems calling fsync fixes this "issue" and data isthe directory containing the file has also reached disk. For
that an explicit fsync() on a file descriptor for the directoryÂ
is also needed.
indeed on SD card after power lose. Looks like I have to addÂ
parameter "how many bytes of data are you willing to lose";) and
manually call fsync after that ammount of data has been stored.
Thanks for fixing me Greg!
Too bad there isn't pure c89 sollution and one needs to use OS
specific functions.
Well... I guess I can always close and reopen file.
--
You received this message because you are subscribed to the Google
Groups "NuttX" group.
To unsubscribe from this group and stop receiving emails from it, send
For more options, visit https://groups.google.com/d/optout.