Little FS IO operation gets extremely slow

Hi, 

I am using sample project (with the name of LittleFS) and am using nRF52840 dev kit. I modified the project to run a loop of 100 iteration. In the loop I am writing 1KB array in separate file on external flash (mx25r64). Most of the the time the process of opening, writing 1KB data and closing the file takes around 100 to 150ms. But sometimes one of the step (out of opening, writing or closing file) gets stuck for upto 13 seconds. Which is considerably longer than the average. 

Has anyone else experienced anything like that? What should I do to eliminate the random SLOW IOs



the function that writes the file (and is called in a loop from main()) does things like:

int64_t s2 = k_uptime_get();
rc = fs_open(&file, fname, FS_O_CREATE | FS_O_WRITE);

int64_t s3 = k_uptime_get();

rc = fs_seek(&file, 0, FS_SEEK_SET);
int64_t s4 = k_uptime_get();

rc = fs_write(&file, data, len);
int64_t s5 = k_uptime_get();

fs_close(&file);
int64_t s6 = k_uptime_get();


int64_t res1 = s2 - s1;
int64_t res2 = s3 - s2;
int64_t res3 = s4 - s3;
int64_t res4 = s5 - s4;
int64_t res5 = s6 - s5;


int64_t res_all = (res1 + res2 + res3 + res4 + res5);

/**
* @brief Print them out
*
*/
printk("init = %lld, open = %lld, seek = %lld, write = %lld, close = %lld, \t\t total = %lld\n", res1, res2, res3, res4, res5, res_all);



The overlay file is:



/delete-node/ &storage_partition;

/ {
fstab {
compatible = "zephyr,fstab";
lfs1: lfs1 {
compatible = "zephyr,fstab,littlefs";
mount-point = "/lfs1";
partition = <&lfs1_part>;
automount;
read-size = <64>;
prog-size = <64>;
cache-size = <256>;
lookahead-size = <128>;
block-cycles = <512>;
};
};
};

&mx25r64 {
partitions {
compatible = "fixed-partitions";
#address-cells = <1>;
#size-cells = <1>;

lfs1_part: partition@0 {
label = "storage";
reg = <0x0 0x800000>;
};
};
};

/ {
chosen {
nordic,pm-ext-flash = &mx25r64;
};
};


The prj.conf are:


CONFIG_MAIN_STACK_SIZE=40960

# Let __ASSERT do its job
CONFIG_DEBUG=y

CONFIG_LOG=y

CONFIG_FLASH=y
CONFIG_FLASH_MAP=y
CONFIG_FLASH_PAGE_LAYOUT=y

CONFIG_FILE_SYSTEM=y
CONFIG_FILE_SYSTEM_LITTLEFS=y

CONFIG_APP_WIPE_STORAGE=n

CONFIG_LOG_BUFFER_SIZE=60240
Parents Reply Children
  • Hi,

    Please do let me know if you find something. 

    Thanks!

  • Hi,

    Could you state which pins you're using that results in this speed?

    imtiz_ahmed said:
    One strange thing I have notice is that if you add fs_unlink(fname); after fs_close(&file); inside fs_write_bytes_to_file(...), which of course will delete the file after it is written, everything works fine, I tried with the loop of 1000 and I could get 9 files per sec, by if I do not delete the file, I get avg or 2 or 3 files a sec. 

    This is a bit unclear to us, could you elaborate what you mean when you do this? 

    But sometimes one of the step (out of opening, writing or closing file) gets stuck for upto 13 seconds.

    The amount of time this takes could also indicate that either something not beeing properly connected or that the application does something important for a long time before it allows for FS to do its thing. Could you check and verify if this is not the case?

    Kind regards,
    Andreas

  • Hello, 

    This is a bit unclear to us, could you elaborate what you mean when you do this? 

    I am using nRF52840 dev kit and used one of the sample projects called LittleFS. I am not doing anything other than writing 1KB array in new file. I call the function that does the file IO in a loop, the function opens a new file in create mode, writes the 1KB array to it and then closes it. The code is as basic as it can get. 

    The amount of time this takes could also indicate that either something not beeing properly connected or that the application does something important for a long time before it allows for FS to do its thing. Could you check and verify if this is not the case?

    Again, since I am using nRF52840 dev kit and the external flash (mx25r64) that comes mounted on the dev board, I am not sure there is any chance of improper connection. It is not a custom board. 

    BTW, I have attached the full sample project that can be run on nRF52840 dev kit to see the results, if you happen to have the time for it of course. 

    Thanks for taking time to reply!

  • Thank you for elaborating 

    What I believe is happening is that you've reached the garbage collection part of the littlefs design.

     This case, When ist littlefs garbage collection / flash erase block called? mentions this briefly and links to the design-readme of littlefs: https://github.com/littlefs-project/littlefs/blob/master/DESIGN.md which should elaborate on it

    The garbage collection procedure takes quite a while, so I would recommend you to investigate if this is what you're observing

    Kind regards,
    Andreas

Related