nuttx icon indicating copy to clipboard operation
nuttx copied to clipboard

Help with file system issue diagnosis when swapping between littlefs and fatfs.

Open g2gps opened this issue 8 months ago • 5 comments

I've encountered an issue while swapping the file system used for our application from LittleFS to FatFS, and would appreciate any help diagnosing the problem.

For my initial investigation, I've been conducting testing with the file system utilities in NuttX, in an attempt to narrow down the scope of the issue

In each case I'm testing using the rv-virt:citest configuration, with the following changes:

diff --git a/boards/risc-v/qemu-rv/rv-virt/configs/citest/defconfig b/boards/risc-v/qemu-rv/rv-virt/configs/citest/defconfig
index 919e6ecd81..f097a6fa88 100644
--- a/boards/risc-v/qemu-rv/rv-virt/configs/citest/defconfig
+++ b/boards/risc-v/qemu-rv/rv-virt/configs/citest/defconfig
@@ -60,6 +60,11 @@ CONFIG_FAT_LFN=y
 CONFIG_FS_AIO=y
 CONFIG_FS_FAT=y
 CONFIG_FS_HOSTFS=y
+CONFIG_FS_LITTLEFS=y
+CONFIG_FS_LITTLEFS_BLOCK_CYCLE=-1
+CONFIG_FS_LITTLEFS_BLOCK_SIZE_FACTOR=4
+CONFIG_FS_LITTLEFS_CACHE_SIZE_FACTOR=4
+CONFIG_FS_LITTLEFS_PROGRAM_SIZE_FACTOR=1
 CONFIG_FS_NAMED_SEMAPHORES=y
 CONFIG_FS_PROCFS=y
 CONFIG_FS_ROMFS=y
@@ -132,7 +137,9 @@ CONFIG_TESTING_LTP=y
 CONFIG_TESTING_MM=y
 CONFIG_TESTING_OPEN_MEMSTREAM=y
 CONFIG_TESTING_OSTEST=y
+CONFIG_TESTING_SMART_TEST=y
 CONFIG_TESTING_SCANFTEST=y
 CONFIG_TESTS_TESTSUITES=y
+CONFIG_TESTS_TESTSUITES_MOUNT_DIR="/mnt"
 CONFIG_TLS_NELEM=8
 CONFIG_USEC_PER_TICK=1000

and a rc.sysinit with:

mkrd -m 1 -s 512 2048
mkrd -m 2 -s 512 2048
mkfatfs /dev/ram1
mkdir /mnt
mount -t vfat /dev/ram1 /mnt/fatfs
mount -t littlefs -o forceformat /dev/ram2 /mnt/littlefs

I move the mount points to /mnt for the cmocka and fstests

Here's the testing I've done so far

smart test

smart_test fails on both fatfs and littlefs with multiple errors, for example:

nsh> smart_test -s 1000 -l 1000 /mnt/fatfs
Seek error on line 775
         Expected "This is line 775 at offset 64
"
         Received ""
996
Seek error on line 140
         Expected "This is line 140 at offset 64
"
         Received ""
997
Seek error on line 762
         Expected "This is line 762 at offset 64
"
         Received ""
998
Seek error on line 55
         Expected "This is line 55 at offset 64
"
         Received ""

cmocka

cmocka --suite fs has failures on fatfs:

[ RUN      ] test_nuttx_fs_stat01
[  ERROR   ] --- 1 != 0
[   LINE   ] --- kernel/fs/cases/fs_stat_test.c:160: error: Failure!
.....
.....
[ RUN      ] test_nuttx_fs_fstat01
[  ERROR   ] --- 0 != 1
[   LINE   ] --- kernel/fs/cases/fs_fstat_test.c:96: error: Failure!
[  FAILED  ] test_nuttx_fs_fstat01

and littlefs:

[ RUN      ] test_nuttx_fs_stat01
[  ERROR   ] --- 4 != 0
[   LINE   ] --- kernel/fs/cases/fs_stat_test.c:160: error: Failure!

fstest

Passes on littlefs:

nsh> fstest -m /mnt -n 10
....
Final memory usage:
VARIABLE  BEFORE   AFTER    DELTA
======== ======== ======== ========
arena     1e9eadc  1e9eadc        0
ordblks         4        4        0
mxordblk  1c92490  1c92490        0
uordblks   20a514   20a514        0
fordblks  1c945c8  1c945c8        0
File system tests done... OK: 20, FAILED: 0

Passes on fatfs:

nsh> fstest -m /mnt -n 10
Final memory usage:
VARIABLE  BEFORE   AFTER    DELTA
======== ======== ======== ========
arena     1e9eadc  1e9eadc        0
ordblks         4        4        0
mxordblk  1c94498  1c94498        0
uordblks   209614   209614        0
fordblks  1c954c8  1c954c8        0
File system tests done... OK: 20, FAILED: 0

Some initial thoughts:

  • The portion of our application which is problematic makes heavy use of ftell and fseek, however the data inconsistency is only apparent when using fatfs. We've been using littleFS for around 9 months without issue.
  • fstest doesn't make use of file streams, or seek, so it may not be catching the test which fails.
  • The cmocka failures seem unreleated, but are worth noting.
  • The smart_test file system check hints that something may be wrong, although I haven't looked any further yet.

Possibly there is further testing which could be done to further narrow down the issue? Or somebody else has noticed a similar issue?

g2gps avatar Jun 13 '24 06:06 g2gps