[GitHub] [incubator-nuttx] patacongo commented on issue #2092: sim:nxffs and sim:spiffs Test failure

[GitBox <gi...@apache.org>]

patacongo commented on issue #2092:
URL: https://github.com/apache/incubator-nuttx/issues/2092#issuecomment-727608447


   I am not sure if this related, but there is documented SPIFFS bug in the TODO list (should be a GIT issue):
   
   ```
     Title:       SILENT SPIFFS FILE TRUNCATION
     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.
   ```
   
   I think that the real world exposure of this problem is rare since it depends on a condition where the physical media becomes full while there is still cached data.  However, the spiffs test does show this failure.  It would probably go away with a different random seed, but I wanted to keep the problem in place and repeatable so that it could be fixed sometime.
   
   I think that the fix would be to reserve sectors that are at least the size of the cache so that this condition could not occur.
   


----------------------------------------------------------------
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