YAFFS2与UBIFS下ls命令行为差异原因及优化方案咨询

• Linux内核版本：3.2.0
• 架构：ARMV7L GNU/Linux
• CPU：AM335x

1. 原Flash文件系统为UBIFS，因不明原因易损坏，已替换为YAFFS2。
2. 某文件夹每秒生成一个文件，需定期检查Flash剩余空间，确保该文件夹占用不超过50%；当占用超限时，删除最早生成的文件，直到剩余空间达标。
3. 最初编写了依赖ls -rt的Shell脚本实现该功能：

#!/bin/sh

folder_path="/path/to/folder"
min_space_percent=50

while true
do
    free_space=$(df -k | grep "/dev/mtdblock" | awk '{print $4}')
    oldest_file=$(ls -rt $folder_path | head -n 1)
    oldest_file_path="$folder_path/$oldest_file"
    
    if [ $free_space -gt $min_space_percent ]
    then
        rm $oldest_file_path
    else
        break
    fi
    
done

执行上述脚本时出现RS-485通信异常，排查发现：当文件夹内文件数量超过一千时，执行ls -rt就会触发该问题；且该问题仅在YAFFS2文件系统中出现，UBIFS下无此异常。

1. 分析认为，YAFFS2文件系统性能较差时，处理大量文件会导致系统响应变慢、CPU占用过高，进而引发RS-485通信异常。
2. 编写C程序查找最早生成的文件，每次遍历文件后添加2ms延迟以降低资源占用：文件数约5000时可正常运行，但文件数进一步增大时，仍会影响RS-485通信。

int main(int argc, char *argv[]) {
    DIR *dir;
    struct dirent *entry;
    struct stat file_stat;
    time_t earliest_time = time(NULL);
    char *earliest_file = NULL;

    if (argc != 2) {
        printf("Usage: %s <directory>\n", argv[0]);
        exit(EXIT_FAILURE);
    }

    dir = opendir(argv[1]);
    if (dir == NULL) {
        perror("opendir");
        exit(EXIT_FAILURE);
    }

    while ((entry = readdir(dir)) != NULL) {
        char *filename = entry->d_name;
        char filepath[1024];
        sprintf(filepath, "%s/%s", argv[1], filename);

        if (stat(filepath, &file_stat) == -1) {
            perror("stat");
            continue;
        }

        if (file_stat.st_mtime < earliest_time) {
            earliest_time = file_stat.st_mtime;
            earliest_file = filename;
        }
        usleep(2000);
    }

    printf("Earliest file: %s\n", earliest_file);

    closedir(dir);
    exit(EXIT_SUCCESS);
}

1. YAFFS2与UBIFS下ls -rt行为差异的具体原因是什么？ #

核心差异源于两个文件系统的元数据存储和访问机制：

• UBIFS：采用日志式设计，元数据（文件修改时间、目录条目等）采用索引化存储并支持批量缓存。执行ls -rt时，UBIFS可快速从缓存或索引中获取所有文件的时间戳，排序开销低；同时对大量文件的目录遍历做了优化，CPU占用和IO延迟可控。
• YAFFS2：专为NAND Flash设计，但元数据与文件数据混存，无全局索引。执行ls -rt时，需逐个读取每个文件的inode获取修改时间，每一次元数据读取都会触发Flash随机IO——NAND Flash的随机IO性能远低于顺序IO，文件数量上千时，大量随机IO会耗尽系统IO资源，CPU需等待IO完成导致系统卡顿，进而影响对实时性要求高的RS-485通信。此外，YAFFS2无目录遍历缓存优化，每次ls都需重新扫描所有目录条目，文件越多扫描时间越长，资源占用越高。

2. 如何更好地解决该问题？ #

可从避免全量遍历、降低IO开销、优化资源调度三个维度入手：

方案一：维护文件生成顺序的索引文件 #

• 每次生成新文件时，将文件名追加到固定日志文件（如file_order.log），最早的文件始终在日志开头。
• 删除文件时，直接读取日志第一行获取最早文件名，删除后移除该行。
• 优势：完全避免目录遍历和元数据读取操作，IO开销极低，上万文件也不影响系统性能。
• 示例脚本片段：

# 生成文件时追加到日志
echo "new_file_$(date +%s)" >> /path/to/folder/file_order.log

# 删除最早文件时
oldest_file=$(head -n 1 /path/to/folder/file_order.log)
rm "/path/to/folder/$oldest_file"
sed -i '1d' /path/to/folder/file_order.log

方案二：优化C程序，减少无效IO与合理调度CPU #

• 利用readdir返回的d_type过滤掉.和..目录，减少无效stat调用。
• 去掉固定2ms延迟，改为每遍历N个文件（如100个）调用sched_yield()主动让出CPU，给RS-485通信进程留运行时间。
• 记录上次找到的最早文件时间戳，后续遍历仅更新更早的文件记录，或达到删除条件后提前终止遍历。
• 优化后的C程序片段：

// 过滤掉当前目录和上级目录
if (strcmp(entry->d_name, ".") == 0 || strcmp(entry->d_name, "..") == 0) {
    continue;
}
// 每遍历100个文件主动让出CPU
static int count = 0;
if (++count % 100 == 0) {
    sched_yield();
}

方案三：调整YAFFS2挂载参数 #

• 挂载时添加noautoblock参数禁用自动块大小调整，减少元数据碎片化；添加nocheckpoint参数关闭自动检查点（需评估业务风险，若允许重启后短暂元数据不一致可使用）。
• 挂载命令示例：mount -t yaffs2 /dev/mtdblockX /mnt/flash -o noautoblock,nocheckpoint
• 注意：仅能缓解问题，需配合其他方案使用。

方案四：限制文件夹文件数量上限 #

• 提前根据50%空间阈值计算最多保留的文件数，每次生成新文件时，若数量超过上限直接删除最早文件，无需检查剩余空间。
• 优势：简化逻辑，避免df和目录遍历开销，实时性更强。

内容的提问来源于stack exchange，提问作者Moran