RT-Thread 文件系统重构

17 个回答

shaolin 2009-04-03

这个没问题，也是确实需要做的

bernard 2009-04-10

这个没问题，也是确实需要做的

下周会收到一块新的STM32F103ZE开发板，应该SD卡硬件的问题不存在了，你时间多吗？或者我先做一些重构？

shaolin 2009-04-10

这个没问题，也是确实需要做的

下周会收到一块新的STM32F103ZE开发板，应该SD卡硬件的问题不存在了，你时间多吗？或者我先做一些重构？

行啊,你重构的话比较专业点,只是你精力够吗,我可以给你分担一点

bernard 2009-04-10

是啊，精力非常有限

不过，RTGUI需要文件系统的支持，文件精简我来做吧。默认不修改的加入到MDK工程中，编译不过呢

等这个好了，再加上AT91SAM7X256的SPI SD卡驱动，就可以正式加入到0.3.0的beta发布中来了

另外还得考虑下如何比较有效的测试下文件系统，USB的U盘？ftp server？一个要USB支持，一个要网络支持。上了AT91SAM7X256应该就可以用网络的方式测试了。

bernard 2009-04-22

文件系统应该如何来做测试比较好呢？

- 基本测试
- 多线程模式下的文件访问测试
- 压力测试
- 速度测试

DFS的一些命令行接口我已经输出一部分到finsh里了，测试部分有啥建议没？

shaolin 2009-04-22

原来搜集过的一些测试条目如下：bsp/s3c2410下有个file_op文件是用来做部分测试用的

1. 测试文件系统提供的所有API，特别是文件的创建、打开、关闭、读、写、定位、删除、查找等操(根据需求以及编程手册设计相应用例，需编程，在此不详述）
2. 测试系统允许打开最大文件数，注意测试正常情况以及打开文件数超出的情况
3. 测试系统允许创建的最大文件数，注意是否与存储介质的大小相关
4. 大文件的测试，应该根据文件系统的特点来设计用例，比如超过一个块的文件和占用所有空间的文件。
5. 文件名长度的限制
6. 同时打开或者写一个文件的操作
7. 断电数据保存功能
8. 文件操作过程断电的处理
9. 目录操作
10.创建、写入、删除文件后空间的变化情况
11.反复的读写，是否会对文件系统性能有影响或者破坏文件系统
12.满负荷或者接近满负荷情况下文件系统的性能
13.如提供命令行模式，则应测试文件系统相关的所有命令
14.对多个文件的同时读写
15.文件系统容错性，测试各种异常情况

bernard 2009-04-22

这个似乎比较全面啊，file_op中都包括了？ [s:154]

shaolin 2009-04-22

没有的，里面包含了API接口测试和压力测试。
长文件名之前不支持，用DFS的fat后可以测起来，
里面也有性能测试的一些时间参数，还没用起来。

shaolin 2009-04-22

文件系统的测试在模拟器上做比较方便，除性能测试外。
我在s3c2410/2440模拟器平台上先做case，开始测起来。

bernard 2009-04-22

好！这次得好好的在SD卡上测一测。

bernard 2009-04-23

========= STM32 文件系统的输出 =========


finsh>>ls("/")
Directory /:
MAKEFILE                458
UU              
TT              
        0, 0x0000
finsh>>ls("/")
Directory /:
MAKEFILE                458
UU              
TT              
        0, 0x0000
finsh>>cat("/Makefile")
# Makefile for Device Filesystem
#
DFS_ROOT_DIR    = ..

include $(DFS_ROOT_DIR)/config.mk

CFLAGS  += -I$(DFS_ROOT_DIR)/inc

DFS_OBJS        = $(DFS_SRC:.c=.o)

all: $(DFS_OBJS)
.PHONY: all

clean :
        $(RM) *.o *~ *.bak
        $(RM) .depend

dep : .depe     0, 0x0000

shaolin 2009-04-23

进展很快啊

bernard 2009-04-23

从长期发展的角度来看，DFS还是用自己原来编写的FAT实现比较好：
- 原来的问题，主要是把一些缓冲区直接开在栈上面了，这样会导致栈的使用量比较大。解决方法就是使用cache，这样这个将不是问题。（原来实现了FAT文件系统中的FAT表cache，可以想办法把它扩展一下，关键是处理好扇区和cache项的对应关系，使得section <--> cache buffer能够比较快的转换）
- 既然用了cache，那么原来所有fat_read_sectors和fat_write_sectors都需要放在cache中做缓存
- 原来的NOR/Nand Flash支持先可以不用考虑添加进来，FAT稳定下来后再做考虑。原来的MTD层应该还是不错的实现的，能够实现基本的擦除均衡。

bernard 2009-05-03

DFS-EFSL这个分支还是弱了些，原来期望比较高的cache也没能发挥重要的作用，而且存储介质的关系似乎也很大：
aozima的结果：
- 260K左右的文件，在44b0上需要8s才能读取出来（IDE硬盘）。

不过我的结果：
- 256k的文件，1s不到就读取出来了（SDIO SD卡）。

从aozima的测试来看，EFSL是采用一个个扇区进行磁盘读取，而FatFS对大文件则是采用一个簇一个簇的方式进行读取，在速度上快了很多。这样EFSL在多扇区读写上差异还是很明显，当然可以在DFS-EFSL里做一个优化，在进行大文件读写的时候直接做多扇区的读写，同时不再把这部分东西放到cache中了。

DFS-FAT呢？希望能尽早成熟起来。

aozima 2009-05-04

拒绝白嫖，拒绝键盘侠！

看来FATFS的这种读取方式是很先进的.

因此表现非凡

在IDE这种磁头需要寻道的地方表现也令人满意(AVR M64 9.2M)

上面都是作者给出的测试,实际测试令人满意,看来要好好参考

bernard 2009-05-04

现在DFS-EFSL和FATFS的操作方式已经十分类似了，只要大于一个扇区以上的数据就直接启用多扇区读写，这点从你测试的数据应该就可以明显的看出来。

另外DFS-EFSL对目录及FAT表的缓存应该做得不错，和FATFS相比有优势。另外DFS-EFSL的缓存还可以做优化，特别对内存大一些的系统。由于STM32的缘故有些感觉对于内存丰富些的系统支持力度有些不够，在考虑是否应该专门为这种系统启动一个子项目。