You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@nuttx.apache.org by GitBox <gi...@apache.org> on 2021/04/05 17:00:10 UTC

[GitHub] [incubator-nuttx] v01d opened a new issue #3406: SILENT SPIFFS FILE TRUNCATION

v01d opened a new issue #3406:
URL: https://github.com/apache/incubator-nuttx/issues/3406


   ```
     Description: Under certain corner case conditions, SPIFFS will truncate
                  files.  All of the writes to the file will claim that the
                  data has been written but after the file is closed, it may
                  be a little shorter than expected.
   
                  This is due to how the caching is implemented in SPIFFS:
   
                  1. On each write, the data is not written to the FLASH but
                     rather to an internal cache in memory.
                  2. When the a write causes the cache to become full, the
                     content of cache is flushed to memory.  If that flush
                     fails because the FLASH has become full, write will
                     return the file system full error (ENOSPC).
                  3. The cache is also flushed when the file is closed (or
                     when fsync() is called).  These will also fail if the
                     file system becomes full.
   
                  The problem is when the file is closed, the final file
                  size could be smaller than the number of successful writes
                  to the file.
   
                  This error is probably not so significant in a real world
                  file system usage:  It requires that you write continuously
                  to SPIFFS, never deleting files or freeing FLASH resources
                  in any way.  And it requires the unlikely circumstance that
                  the final file written has its last few hundred bytes in
                  cache when the file is closed but there are even fewer bytes
                  available on the FLASH.  That would be rare with a cache
                  size of a few hundred bytes and very large serial FLASH.
   
                  This issue does cause the test at apps/testing/fstest to
                  fail.  That test fails with a "Partial Read" because the
                  file being read is smaller than number bytes written to the
                  file.  That test does write small files continuously until
                  file system is full and even the the error is rare.  The
                  boards/sim/sim/sim/configs/spiffs test can used to
                  demonstrate the error.
     Status:      Open
     Priority:    Medium.  It is certain a file system failure, but I think that
                  the exposure in real world uses cases is very small.
   ```


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
users@infra.apache.org