重新理清加密文件系统的思路，在一定范围内进行调优、测试，在调试过程中暴露出许多bug。本文记录发现问题、解决问题的思路以及对问题的简要分析，随着工作进展不断更新。目前仍有大量问题亟待解决。
工作清单
- 不同文件类型测试
- 读写性能测试
- 优化
问题汇总
问题：修改文本后，前部分正确解密，后部分乱码
场景复现： 复制文本到加密目录，使用gedit 或者 vim 打开 开头部分添加若干行内容，保存后再次打开。
定位问题：读操作每次读4096，为8整数倍，写操作会在不足8字节处开始
修改方案：写操作先判断应用层传递count大小是否为8整数倍，调整后调用vfs_write，多出8字节部分不处理。
问题：音频视频PDF无法加解密
分析：加密算法问题，考虑更换加密算法
问题：无法完美还原明文。
场景复现：使用gedit打开文件，点击save，再次打开。
无法正确解密文件。前部分正确。中间一部分错误一部分正确。
过程：使用桌面程序打开加密文本进行修改，保存过程出现卡顿，再次打开无法正常显示。
分析：初步怀疑是脏页读写机制导致文件内容错乱。
使用save as 到另外文件夹，可以将明文复制过去，判断应用程序使用应用程序缓存直接复制，而非调用底层页缓存等。排除底层问题。
定位问题在写操作。内核打印每次写操作上层请求大小count成功读写返回大小err ，发现每次读偏移量为相同值 8192 ，save 和save as时写入大小出现若干为 8191 。该处导致保存后再次读出现问题。
问题：使用vi打开创建修改文本正确，换用gedit打开保存后，乱码
解决思路：调整接受到应用层写请求count 大小，内层添加写大小调整，确保每次写操作执行量为 8*n
问题：使用gedit修改保存后57328字节处3个字符错误
解决方案：调整文件偏移量*ppos 从8整数倍开始写
问题：使用vi打开修改正确，换用gedit打开保存后全文错误。
分析：调用堆栈式文件系统写操作，在保存操作的时候并不是全文顺序写入
性能测试
选择恰当的工具测试文件系统的性能，不使用文件系统模版，使用空白文件系统模版，使用添加加解密模块的文件系统分别测试，找出性能瓶颈，以及最大可优化点，对其进行优化。
工具选择
IOzone Filesystem Benchmark—a filesystem benchmark tool
fdtree—The fdtree software is used for testing the metadata performance of a file system
测试读写性能
安装iozone
使用iozone -i 0 -i 1 -f /home/yzr/Desktop/cont/iozone -Rab /home/yzr/Desktop/memcpy.xls -n 10k -g 1g -y 2k -q 8M
生成excel放到官网提供的模版里处理数据得到炫酷的3D图像。
-i 0 write/rewrite -i 1 read/reread 仅测试读写
块最小值为2k 块最大值为8M
问题：
测试wrapfs带有加解密模块的wrapfs文件系统，以reclen(record length I/O请求的大小)为8192读写时会killed
临时方案：
最小块为8k 最大块为4M 文件大小从10K到800M
先分析数据，之后研究原因
对具有加密模块的文件系统测试出现问题！rewrite 后无法读
单独测试写性能
分析：
性能调优
测试前要先清空缓存
方法总结
- 分析原因
- 列举可能影响性能的调优参数
- 定位性能瓶颈