请教一个文件系统的问题

ltj021

在一个系统性能比较差的平台上开发应用，发现FAT文件系统再支持多任务同时写操作时有些问题。问题是这样的：
通话过程中录音，录音文件是写到T卡上，同时给T卡通过蓝牙发数据，会发现录音数据有时无法写入，而导致录音的task timeout，丢出异常。
负责录音的task优先级还比蓝牙写文件的任务优先级高，经分析发现问题是因为蓝牙传输时一次会写入比较大的数据块，比较耗时，通过减小蓝牙传输buffer的大小，可以降低问题出现的机率。 但类似的问题还存在，例如录音时候，下载MMS，解决方案是减小MMS的下载速率。
但这样解决问题太累了，有没有一个从文件系统方面来解决的办法。
请大家帮忙一下，看看有没有解决办法

canny

FileMgr在一个写入请求未完时，再收到Write的Task, 应该立即返回了“RET_BUSY”......

其实一般是让录音的task在受到ret_busy时进行等待的，但这是个实时性强的task.....

一般service处理req共斥是采取request queue进行异步处理,但这个适合FileMgr吗？很多FileMgr是直接传入的Buffer指针，而不进行Buffer copy，那如果让录音task提出request不管请求就继续走，还是不行啊.......

canny

1、很多FileMgr的write是一次命令时候完全死锁的同步模式.....这样的话，不是简单降低蓝牙的总BufferSize，而是在蓝牙在写文件的时候，不是一次wrtie.....而是多次少量的写入那个 BT的Buffer的内容；同时让 recording 的Task 在收到ret_busy时候，暂时等待再试(或者Task本身就会等待)，这样试试如何？

2、做Request queue，不过，不仅仅记录命令参数，而且要Malloc Size，将写入的Data copy过来.......改动过后，只有queue full的时候才能返回之前的ret busy......
ap的write请求，都只能向queue添加一项(在队前还是队尾这是优先级了).....
然后 check queue，依次运行queue中的命令......

一般mobile mgr等模块都一定会做这个，仿造那个来做吧.....

huazjxy

建议给文件读写io做个缓冲buffer,避免频繁操纵文件系统……