RT-Thread 文件系统重构

发布于 2009-04-03 06:41:41
做个RT-Thread文件系统重构吧,当前的DFS和RT-Thread结合得还不是太紧密:
DFS原来是和DOOLOO联系在一起的,同时为了测试方便也做了Win32 & POSIX平台的包装

而现在改为RT-Thread的平台了,这些包装也就不需要了,所以可以考虑做如下的这些重构:
[list=a][li]
[*:300j06tv]直接使用RT-Thread的基本类型:rt_uint8_t,rt_uint16_t ,rt_uint32_t[/*:m:300j06tv]
[*:300j06tv]直接使用RT-Thread的基本调用:rt_thread,rt_semaphore等[/*:m:300j06tv]
[*:300j06tv]文件进一步精简,一些不必要的文件都取消掉,目录也可以考虑重新划分下[/*:m:300j06tv]
[*:300j06tv]NOR,Nand MTD设备类型暂时移除吧[/*:m:300j06tv]
[*:300j06tv]如果使用DFS中的FAT文件系统,还需要考虑好如下几点:
* 栈上开辟空间的大小(DFS实现得比较早,所以当时有些情况考虑得并不好,栈上面开辟的空间过大),用动态内存或cache来代替。
* cache的优化。[/*:m:300j06tv][/li]

shaolin,有时间来做这个吗?
read.jpg
test.jpg
hdd.jpg

查看更多

关注者
0
被浏览
10.1k
17 个回答
shaolin
shaolin 2009-04-03
这个没问题,也是确实需要做的
bernard
bernard 2009-04-10
这个没问题,也是确实需要做的


下周会收到一块新的STM32F103ZE开发板,应该SD卡硬件的问题不存在了,你时间多吗?或者我先做一些重构?
shaolin
shaolin 2009-04-10
这个没问题,也是确实需要做的


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


行啊,你重构的话比较专业点,只是你精力够吗,我可以给你分担一点
bernard
bernard 2009-04-10
是啊,精力非常有限

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

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

另外还得考虑下如何比较有效的测试下文件系统,USB的U盘?ftp server?一个要USB支持,一个要网络支持。上了AT91SAM7X256应该就可以用网络的方式测试了。
bernard
bernard 2009-04-22
文件系统应该如何来做测试比较好呢?

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

DFS的一些命令行接口我已经输出一部分到finsh里了,测试部分有啥建议没?
shaolin
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
bernard 2009-04-22
这个似乎比较全面啊,file_op中都包括了? [s:154]
shaolin
shaolin 2009-04-22
没有的,里面包含了API接口测试和压力测试。
长文件名之前不支持,用DFS的fat后可以测起来,
里面也有性能测试的一些时间参数,还没用起来。
shaolin
shaolin 2009-04-22
文件系统的测试在模拟器上做比较方便,除性能测试外。
我在s3c2410/2440模拟器平台上先做case,开始测起来。
bernard
bernard 2009-04-22
好!这次得好好的在SD卡上测一测。
bernard
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
bernard
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
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
aozima 2009-05-04
拒绝白嫖,拒绝键盘侠!
看来FATFS的这种读取方式是很先进的.
read.jpg

因此表现非凡
test.jpg

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

上面都是作者给出的测试,实际测试令人满意,看来要好好参考
bernard
bernard 2009-05-04
现在DFS-EFSL和FATFS的操作方式已经十分类似了,只要大于一个扇区以上的数据就直接启用多扇区读写,这点从你测试的数据应该就可以明显的看出来。

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

撰写答案

请登录后再发布答案,点击登录

发布
问题

分享
好友

手机
浏览

扫码手机浏览