-
-
Notifications
You must be signed in to change notification settings - Fork 100
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Will esp_littlefs support large capacity TF Card? #211
Comments
In esp_littlefs.c:936: size_t max_allowed_blk_cnt = 0;
if (((uint64_t)sdcard->csd.capacity * (uint64_t)sdcard->csd.sector_size) > SIZE_MAX) {
max_allowed_blk_cnt = SIZE_MAX / sdcard->csd.sector_size;
ESP_LOGW(ESP_LITTLEFS_TAG, "SD card is too big (sector=%d, count=%d; total=%llu bytes), throttling to maximum possible %u blocks",
sdcard->csd.sector_size, sdcard->csd.capacity,
(((uint64_t)sdcard->csd.capacity * (uint64_t)sdcard->csd.sector_size)), max_allowed_blk_cnt);
} else {
max_allowed_blk_cnt = sdcard->csd.capacity;
} here esp_littlefs limit partition max size to SIZE_MAX |
@huming2207 what was the reason for this check? I'm not too familiar with the |
Sorry for the late reply. Yes I think the SD card driver itself should be able to support 16TB. I did ask the ESP-IDF maintainer before. I will try if I can find that discussion thread later. |
See:
And yes, I think I should fix this logic: if (((uint64_t)sdcard->csd.capacity * (uint64_t)sdcard->csd.sector_size) > SIZE_MAX) {
max_allowed_blk_cnt = SIZE_MAX / sdcard->csd.sector_size;
ESP_LOGW(ESP_LITTLEFS_TAG, "SD card is too big (sector=%d, count=%d; total=%llu bytes), throttling to maximum possible %u blocks",
sdcard->csd.sector_size, sdcard->csd.capacity,
(((uint64_t)sdcard->csd.capacity * (uint64_t)sdcard->csd.sector_size)), max_allowed_blk_cnt);
} else {
max_allowed_blk_cnt = sdcard->csd.capacity;
} It should be only reject to work if either the SD card sector count and sector size is bigger than UINT32_MAX (as per discussed here: https://github.com/littlefs-project/littlefs/blob/master/SPEC.md#0x0ff-lfs_type_superblock I will fix this later tonight if I can. But so far I don't have hardware set up at the moment as I'm busy working on something else, so I can't test it. |
@yiming564 if you want, please try my branch here: 15846f4 Please test throughly and report if that works or not. I don't have test hardware and I don't have time to test at the moment. 😅 |
@huming2207 I have tested your program and SD Card can be successfully mounted, and I also wrote a simple program to test whether LittleFS can really support large partition: ...
// Only a part of my code.
#include <sys/stat.h>
#include <fcntl.h>
#include <memory.h>
static const size_t blk = 0x10000, blk_cnt = 1 << 17; // 8 GiB
#define TEST_PATH (EXT_PATH "/BigFile.txt")
esp_err_t stress_test()
{
ESP_LOGI(app_tag, "Start stress test.");
int fd = open(TEST_PATH, O_WRONLY | O_CREAT, 0777);
APP_CHECK_WITH_LOG(fd >= 0, ESP_ERR_NOT_FOUND, app_tag, "Cannot create %s", TEST_PATH);
uint8_t *buf = malloc(blk);
memset(buf, 'A', blk);
for (int i = 0; i < blk_cnt; i++)
{
if ((i & 31) == 0) ESP_LOGI(app_tag, "Written %u/%u blk.", i, blk_cnt);
APP_CHECK_WITH_LOG(write(fd, buf, blk) != -1, ESP_FAIL, app_tag, "Write failed!");
}
ESP_LOGI(app_tag, "Completed!");
close(fd), free(buf);
struct stat st;
stat(TEST_PATH, &st);
ESP_LOGI(app_tag, "File size check: %lu Bytes", st.st_size);
return ESP_OK;
}
... This program tried to create a 8 GiB file and fill it. I tested the program on my own hardware, and found the writing speed is unexpectedly slow:
About 48 KiB/s, that's pretty slow. It may take days to fill the file. |
P.S. sdmmc is configured as 4-line, 40 mhz. |
Thanks for the report! @yiming564
What about bigger blocks? In your code the Also have you tried increasing the cache size? I think this speed somewhat make sense. From our impression earlier we tested with the XTX SD NAND, it was also very slow. We were trying to implement a time series database to store our log, so the latency and speed is critical for us. But LittleFS (and/or ESP-VFS) was too slow. We then moved to our own lower-level filesystem implementation instead. |
@huming2207 thank you for the reply.
emm I don't suppose and I think the theoretical transmission speed limit is |
hmmm yea... have you tested the raw SD card write speed (just by calling the SDMMC APIs)? @yiming564 |
Yep. But I think this is a bug somewhere I need to find out. For FATFS on ESP-IDF with SD card, people are getting MB/s level speed, see:
Meanwhile, another question for @yiming564 , did you enable |
Also @yiming564 can you please try running this: https://github.com/espressif/esp-idf/tree/v5.4/examples/storage/perf_benchmark I'm also trying to set up an enviroment to test out. So far I only have one spare SD card at home that allows me to do random experiments. It's horrible but it still works. On the card reader of my Kensington Thunderbolt3 dock, it gets this speed by running
|
Hmm yea, even with official demo and SDSPI at 20MHz, ESP-IDF v5.4, LittleFS has already lost the game compared to FATFS: With FATFS:
With LittleFS:
|
With SDMMC 4-lane, it looks a bit better, but I think either I've got a rubbish SD card breakout board from Taobao, or the SD card itself is crap. The benchmark didn't quite work when there's a huge amount of data: As you see, the FATFS benchmark will always die in the middle, but the performance looks better than SDSPI for sure:
With LittleFS however it completed the test (because the bottleneck wasn't at the SDMMC connection, probably at the LittleFS side 😅), and the performance is a bit embarrassing:
|
I don't really have much to offer here, but here are some relevant github issues (that don't really offer any additional suggestions): The general thoughts are that littlefs may not be great for sd cards, but it doesn't seem too well-researched. @huming2207 I think those changes should work, but sure why they are not. Another (probably inconsequential) thing is that I don't think SD cards benefit from wear-leveling, as they should handle that internally on their own. This can be done by setting |
Hmm, I don't know either. I think something went wrong with my hardware setup. I have some CSNP16GCR01-AOW SD NAND chips and breakout boards in my hand now. I should try it out later. |
For SD cards, throughput can be increased if the block size read or written at once is increased. As I understand from esp_littlefs code, there are two issues:
(This is based on a cursory look at the code, apologies if I got something wrong.) |
Hi @igrr , thanks for the reply.
So far I limited to 512 bytes only (same size as SD card sector), that's even worse 😅 I've tried to make the block bigger but somehow didn't work for me. I suspect my hardware setup has some issues and I will solder another breakout board and test it again.
Yea I think that's another problem. LittleFS probably only does one block at a time. I guess to fix this might need to hack the
|
Hi @huming2207, sorry for taking a week to reply to you. I have tested LittleFS's writing speed when SD Card is directly connected to my computer via a USB 3.0 SD Card Reader, and the writing speed is about 6 MB/s (5.72 MiB/s):
P.S. I use littlefs-fuse to access LittleFS on Linux. And I've also tested FATFS's writing speed when SD Card is connected to ESP32-S3 and writing speed is 13.76 MiB/s, more than twice as much as LittleFS's writing speed:
I don't know the specific data structure littlefs used, but ... I wonder maybe littlefs itself is poorly designed? |
we'd really need some sort of profiling to indicate where the performance issue is. Maybe just as a broad shotgun-style checking, it might be good to see if littlefs is writing a single-block at a time while fatfs is writing multiple: |
to keep conversation focused; closing this one and we can continue #214 . |
LittleFS can support large partition, but it seems that esp_littlefs limited TF Card's partition size to 0xffffffff, because ESP32 is a 32-bit platform and SIZE_MAX is 0xffffffff.
Will esp_littlefs remove the limit and support large partition?
The text was updated successfully, but these errors were encountered: