Opt分区变只读问题分析

I. 问题现象

165E\C管理机在使用过程中，可能会出现opt分区变为只读属性，opt分区只
可以读取，无法写入，进而导致应用工程下载失败，无法修改已有的工程配置情
况出现，此时执行mount命令查看opt属性已经变成了ro模式

II. 问题分析

获取内核打印信息如下：

对应的内核ubifs文件系统代码如下：


错误码-22（-EINVAL）指的是入参错误，入参lnum=-1.
ubifs_leb_unmap函数调用的地方比较多，代码跟踪起来比较费劲：

Ubifs文件系统变成只读的情况，网络上也有很多人遇到，但有结论的很少：
http://bbs.21ic.com/icview-464754-1-1.html
这个帖子中作者总结了am335x平台下的ubifs文件系统的几个问题及解决方
法，与只读问题相关的是问题二：

此问题从打印信息看与我们遇到的问题不是同一个，而且其提供的解决方案是针对am335x平台驱动代码，仅作为解决问题的一个参考。
http://lists. infradead .org/pipermail/linux-mtd/2014-June/054320.html
此贴中讨论的问题与我们遇到的问题很相像，但此贴最终没有给出一个解决措施，讨论的过程仅作为参考。

http://www. deyisupport .com/question_answer/dsp_arm/sitara_arm/f/25/t/105787.a
spx
此贴为TI的一个论坛帖，讨论的同样是am335x平台的ubifs文件系统的问题：

文件系统变为只读，现象与我们的相似，但对比内核的打印信息看应该不是
同一个问题，此贴中只读问题的原因是文件系统检测到一个bad CRC。
这个帖子目前也没有确定的解决措施，其中TI的工程师提出了他们的结论和规避
措施，他们认为此问题是ubifs文件系统的一个bug，还没有解决方案，建议更换
存储方式或者做重要数据的备份和擦除恢复：

http://lists. infradead .org/pipermail/linux-mtd/2010-May/030243.html
此贴中讨论的问题与我们遇到的情况类似：

并且帖子中提出了一种规避方案：

该贴认为出现最终的只读错误的原因是ubifs_rcvry_gc_commit函数错误返
回被忽略了：

在fs/ubifs/super.c的mount_ubifs函数中确实存在忽略错误返回值的问题：

而在ubifs_rcvry_gc_commit函数中按照帖子中提供的错误信息分析确实会
导致c->gc_lnum=-1：

而前面我们搜索ubifs_leb_unmap调用时，确实有很多分支是以c->gc_lnum为
入参的，进而会导致如下错误也解释的通了：

此猜想可以待问题复现后将代码的debug功能打开测试确认，如果同样会有
下面的打印信息，则我们遇到的问题与此贴问题相同：

Opt只读问题复现测试方案：
两台管理机，一台用于控制继电器通断，每隔30s（能保证受控制管理机在
此时间内能上电成功且运行测试代码）控制继电器断电一次，另一台管理机电源
受继电器控制，且管理机内正常烧录应用代码的同时上电自动运行测试代码（上
电自动进行opt分区内一个文件的写入操作，大小为2M，写完删除文件，重新创
建新的文件继续写入，如此循环），经过约一周时间不停断电测试，未发现只读
问题复现；

手动将opt分区填满，保证写文件的代码在写文件过程中会因为空间不足而失
败，手动断电几次，问题复现（后面经过多次测试，基本确定在此情况下，30s
断电一次，测试4小时内基本上都会复现opt变成只读的问题），按照上面分析猜
想，将系统中ubifs文件系统的debug功能打开，重新网络加载内核代码后上电，
有如下打印：

由打印发现确实出现了上面猜测的打印信息出现：

按照http://lists. infradead .org/pipermail/linux-mtd/2010-May/030243.html提供的
修改方案修改内核代码后测试：

测试结果 ：
1.两台165E管理机按照上面opt复现预案方式进行上下电压力测试时间超过2
周，未再发现opt只读问题复现。
2.另外一台165E管理机正常烧录应用程序，并且opt分区被人为填满、正常运
行循环写2M文件的测试程序情况下，外接电表，搭建正常测试环境，测试时间
超过2周，未发现系统异常和通信异常。
3.对165C进行对应测试，使用最新试流的版本，在opt人为填满且存在测试代
码情况下进行掉电压力测试，4小时内即可出现opt只读的问题。
4.按照上面提供的修改方案，修改kernel代码后更新内核重新上电故障即可消
除，且进行掉电压力测试时间超过12小时，未发现opt变成只读的问题出现。
测试结论 ：
通过上面的测试基本可以确定ubifs文件系统存在一定的bug，这个bug会导致
opt分区在某个特定的情况下出现ro问题，而且我们找到的解决方案可以有效的
解决这个问题；但是我们复现问题时使用了一种比较极限的情况，此种情况下复
现的opt只读问题与我们原来正常情况偶发出现的问题是否一致暂无结论，所以
以上提出的解决方案是否能够完全解决我们原来发现的opt只读问题无法完全保证。

III. 解决方法

按照下面方案进行修改：

IV. 总结和建议

1.通过测试基本确定目前我们使用的ubifs文件系统的代码存在bug，建议修改
此bug。
2.建议先在165C上变更版本进行试用。