Debug的故事 1－MLC NAND不能成功mount
生活中总是会遇到奇奇怪怪的，形形色色的问题，工作中也不例外。作为一个记录，希望这些能帮助到一些同志。
先说说我最近碰到的问题。有个产品出货了有三年多的时间，部署的量也不是特别大，但是最近陆陆续续的接到客户的报告，说功能上有些问题，TAC部门的兄弟冲上去后，发现不是客户使用环境的问题，于是就RMA到直接到了研发端。
在展开具体的叙述之前，先做点基本的背景介绍。这个项目中用到了Intel的Atom CPU，这个CPU来自与Intel DHG （Digital Home Group），据说该部门是几年前为了Google TV的项目专门成立的，但不幸的是Google TV最终放弃了这个方案，然后，然后Intel就把这个部门解散了。所以这个芯片跟传统的x86有点不同。
基本的框图如下：
OS 是阉割版的Intel Linux.
这里面两个NAND 芯片，一个是SLC NAND做boot，kernal和file system的存储，另外一个是MLC NAND，主要目的是放了个factory image，如果不幸SLC里面的OS挂掉了，可以透过MLC NAND里的做OS recover的事情。这个memory的架构基本还算合理，因为SLC和MLC在可靠性和价格上的巨大差异，这也算是一个比较中规中矩的设计。（至于MLC和SLC为啥有这些差异，建议google）
MLC这边会在kernel起来的过程中被Linux OS mount，只有成功mount后OS才会继续往下执行。
拿到RMA的盒子后，HDMI这边木有输出，于是开盖接console （这个项目没有外部的console是一大败笔，这个console对软件开发和debug以及工厂生产实在太重要了），console有东西打印，OK，有console log总可以分析原因。
简单的分析log，发现是由于USB MLC NAND没有别Linux成功mount，所以整个OS没有继续往下执行。第一个问题出来了，为什么Linux没有能成功Mount这个USB MLC NAND呢？
这个flash的控制器是Phison提供的，Phison有提供一些debug的工具在windows下面，把板上这个MLC NAND接到Windows下，发现本身windows是可以看到U盘的（其实就是MLC NAND Flash），但是如果你想使用这个U盘是不可以的。第二个问题来了，为什么Windows下可以看到这个U盘但不能使用？
Phison的工具可以提供基本的SMART的信息，windows下读到的信息如下：
--------------------Device Information------------------
IC Version : 2251-50
FW Version : 03.07.10
FW Date : 2011-01-26
Flash Vendor : Samsung
Flash Type : MLC 8K
Flash ID : ec d5 84 72 50 42 ec 00
-------------------S.M.A.R.T Information----------------
Total Bad Block : 3
Number of Spare Block : 97
Average Erase Count : 3239
Spec. Flash Erase Cycle : 3000
Endurance Life Ratio : 0.00%
这个SMART信息也很奇怪，MLC基本的擦除寿命是3000次，这里明显已经超过很多了啊，而且是平均擦除的次数超过了3000次，这里发生了什么？
现在一共有这么几个问题出来了
1. 为什么Linux没有能成功Mount这个USB MLC NAND呢？
2. 为什么Windows可以发现该USB MLC NAND但不能正常使用？
3. 为什么平均擦写次数超过了3000次？
为了解答这几个问题，开始google和咨询相关的专家并且询问Phison的工程师了。
我们先看看问题一和问题二，我们可以合并这个问题成 “为什么Linux看不到U盘但是Windows可以看到？”这个问题很扯，那不是废话嘛——因为Linux和Windows detect到U盘的方式不一样嘛——虽然问题很扯，但是可以告诉我们几个事情
1. USB NAND控制器的硬件是好的
2. USB NAND控制器的FW是好的；这个FW是存放在MLC NAND开始的几个block的，并且为了可靠性，有几个多余的copy在。所以当在windows下，USB NAND控制器和host之间的handshake是OK的；
至于为啥Linux可以看到但不能用，可能的一个说法是我们在这个U盘上使用的文件系统是EXT3，这个Windows不支持的。
那为啥Linux下看不到呢，那只能是Linux下看到U盘的机制和Windows不同了，有啥不同呢？？
这个问题问的很好，可我估计能回答出来的没几个人，那么复杂的Linux USB mount机制，谁晓得？
以下是目前的几个解释：
Before USB NAND mounted, the Linux needs to scan the MLC NAND,is that true? This will cost a lot of time to finish scanning.
[NAND Controller Vendor]:This is the information I got from our RD, I think it will not “Scan” the flash, but just read the file system table, and if there is error in the file system table, then Linux will not mount the device.
However, we cannot be 100% sure of this, so if you have ways to check with Linux developer, will be the best.
[SW Team]: TheU-disk is ext3 file system, although window system can detect it as external disk, but we can't read/write disk as unsupported fs type.
Due to Window don't check u-disk file system when u-disk plug in. however Linux always check U-disk superblock after mount. Actually, Linux system won't "SCAN" all U-disk. it access the superblock only.
When system mount U-disk without -t (file system) specified, Linux will probe the superblock if any familiar file system are in listed. So, if u-disk EXT3 superblock is valid will taken action mount to Linux system directly.
There few way to checks u-disk status (superblock, badblocks) when ext3 superblock still health, otherwise we can't peek any u-disk info in Linux
简言之，就是说Linux kernel在mount U盘之前呢，还会scan super block的内容，如果这个super block区域挂掉了，kernel是无法成功mount U盘的。
Super block为啥会挂掉呢？厂商得解释是你的擦除次数太多了，已经超过了spec得规定，这样就没人保证在读取得时候这些super block的区域不会出问题。Phison用了另外的tool 去扫描整个MLC NAND，发现了不可预期的ECC错误。
至于Windows，能看到但是由于文件系统根本不同，所以自然不能使用。
好了，这两个问题看起来都有一个蛮合理的解释了，下一步就需要找找为何MLC NAND的擦除次数这么高呢？这个只能问软件的同事了，结果也很简单，系统软件需要写log文件，于是乎，这个log文件时时更新，可不是没几个月就写多了。
这里可能需要引申点，MLC NAND的写的操作是以page为单位的，但是Block(块)是 NAND Flash 擦除的最小单位。由于 NAND Flash 采用了高密集的存储单元,且擦写过程复杂,所以在使用过程中擦写多了,难 免会损坏一些存储单元,即块的擦写是有寿命的。由于 NAND Flash 是整块擦除,块内的页中如果有 一位或多位失效,整个块就会失效,出现所谓的坏块(Bad Block)。（引自网上的一篇文档）
但是每次写都会trig一个block的擦除，这个很要命，哪怕你就写1个bit进去，都需要把一个block擦除了写进去（当然没这么简单，这里只是简单描述下），这个机制决定了MLC NAND就不能这么老实的往里面写log 文件。
只能告诉软件让客户修改他们得软件，不能这么玩。
反思教训：
由于我们的客户之前的平台是PC，上面的HDD是没有写的限制的。当同样的思路应用在我们的系统上的时候，由于硬件的基本架构已经发生了根本性的改变，那么软件的思路也必须做出调整。
注释：
TAC：不是Tactical Air Command，是公司的售后技术服务团队；
RMA：Return Material Authorization的英文缩写，即退料审查；
先说说我最近碰到的问题。有个产品出货了有三年多的时间，部署的量也不是特别大，但是最近陆陆续续的接到客户的报告，说功能上有些问题，TAC部门的兄弟冲上去后，发现不是客户使用环境的问题，于是就RMA到直接到了研发端。
在展开具体的叙述之前，先做点基本的背景介绍。这个项目中用到了Intel的Atom CPU，这个CPU来自与Intel DHG （Digital Home Group），据说该部门是几年前为了Google TV的项目专门成立的，但不幸的是Google TV最终放弃了这个方案，然后，然后Intel就把这个部门解散了。所以这个芯片跟传统的x86有点不同。
基本的框图如下：
 |
系统的memory基本框图 |
OS 是阉割版的Intel Linux.
这里面两个NAND 芯片，一个是SLC NAND做boot，kernal和file system的存储，另外一个是MLC NAND，主要目的是放了个factory image，如果不幸SLC里面的OS挂掉了，可以透过MLC NAND里的做OS recover的事情。这个memory的架构基本还算合理，因为SLC和MLC在可靠性和价格上的巨大差异，这也算是一个比较中规中矩的设计。（至于MLC和SLC为啥有这些差异，建议google）
MLC这边会在kernel起来的过程中被Linux OS mount，只有成功mount后OS才会继续往下执行。
拿到RMA的盒子后，HDMI这边木有输出，于是开盖接console （这个项目没有外部的console是一大败笔，这个console对软件开发和debug以及工厂生产实在太重要了），console有东西打印，OK，有console log总可以分析原因。
简单的分析log，发现是由于USB MLC NAND没有别Linux成功mount，所以整个OS没有继续往下执行。第一个问题出来了，为什么Linux没有能成功Mount这个USB MLC NAND呢？
这个flash的控制器是Phison提供的，Phison有提供一些debug的工具在windows下面，把板上这个MLC NAND接到Windows下，发现本身windows是可以看到U盘的（其实就是MLC NAND Flash），但是如果你想使用这个U盘是不可以的。第二个问题来了，为什么Windows下可以看到这个U盘但不能使用？
Phison的工具可以提供基本的SMART的信息，windows下读到的信息如下：
--------------------Device Information------------------
IC Version : 2251-50
FW Version : 03.07.10
FW Date : 2011-01-26
Flash Vendor : Samsung
Flash Type : MLC 8K
Flash ID : ec d5 84 72 50 42 ec 00
-------------------S.M.A.R.T Information----------------
Total Bad Block : 3
Number of Spare Block : 97
Average Erase Count : 3239
Spec. Flash Erase Cycle : 3000
Endurance Life Ratio : 0.00%
这个SMART信息也很奇怪，MLC基本的擦除寿命是3000次，这里明显已经超过很多了啊，而且是平均擦除的次数超过了3000次，这里发生了什么？
现在一共有这么几个问题出来了
1. 为什么Linux没有能成功Mount这个USB MLC NAND呢？
2. 为什么Windows可以发现该USB MLC NAND但不能正常使用？
3. 为什么平均擦写次数超过了3000次？
为了解答这几个问题，开始google和咨询相关的专家并且询问Phison的工程师了。
我们先看看问题一和问题二，我们可以合并这个问题成 “为什么Linux看不到U盘但是Windows可以看到？”这个问题很扯，那不是废话嘛——因为Linux和Windows detect到U盘的方式不一样嘛——虽然问题很扯，但是可以告诉我们几个事情
1. USB NAND控制器的硬件是好的
2. USB NAND控制器的FW是好的；这个FW是存放在MLC NAND开始的几个block的，并且为了可靠性，有几个多余的copy在。所以当在windows下，USB NAND控制器和host之间的handshake是OK的；
至于为啥Linux可以看到但不能用，可能的一个说法是我们在这个U盘上使用的文件系统是EXT3，这个Windows不支持的。
那为啥Linux下看不到呢，那只能是Linux下看到U盘的机制和Windows不同了，有啥不同呢？？
这个问题问的很好，可我估计能回答出来的没几个人，那么复杂的Linux USB mount机制，谁晓得？
以下是目前的几个解释：
Before USB NAND mounted, the Linux needs to scan the MLC NAND,is that true? This will cost a lot of time to finish scanning.
[NAND Controller Vendor]:This is the information I got from our RD, I think it will not “Scan” the flash, but just read the file system table, and if there is error in the file system table, then Linux will not mount the device.
However, we cannot be 100% sure of this, so if you have ways to check with Linux developer, will be the best.
[SW Team]: TheU-disk is ext3 file system, although window system can detect it as external disk, but we can't read/write disk as unsupported fs type.
Due to Window don't check u-disk file system when u-disk plug in. however Linux always check U-disk superblock after mount. Actually, Linux system won't "SCAN" all U-disk. it access the superblock only.
When system mount U-disk without -t (file system) specified, Linux will probe the superblock if any familiar file system are in listed. So, if u-disk EXT3 superblock is valid will taken action mount to Linux system directly.
There few way to checks u-disk status (superblock, badblocks) when ext3 superblock still health, otherwise we can't peek any u-disk info in Linux
简言之，就是说Linux kernel在mount U盘之前呢，还会scan super block的内容，如果这个super block区域挂掉了，kernel是无法成功mount U盘的。
Super block为啥会挂掉呢？厂商得解释是你的擦除次数太多了，已经超过了spec得规定，这样就没人保证在读取得时候这些super block的区域不会出问题。Phison用了另外的tool 去扫描整个MLC NAND，发现了不可预期的ECC错误。
至于Windows，能看到但是由于文件系统根本不同，所以自然不能使用。
好了，这两个问题看起来都有一个蛮合理的解释了，下一步就需要找找为何MLC NAND的擦除次数这么高呢？这个只能问软件的同事了，结果也很简单，系统软件需要写log文件，于是乎，这个log文件时时更新，可不是没几个月就写多了。
这里可能需要引申点，MLC NAND的写的操作是以page为单位的，但是Block(块)是 NAND Flash 擦除的最小单位。由于 NAND Flash 采用了高密集的存储单元,且擦写过程复杂,所以在使用过程中擦写多了,难 免会损坏一些存储单元,即块的擦写是有寿命的。由于 NAND Flash 是整块擦除,块内的页中如果有 一位或多位失效,整个块就会失效,出现所谓的坏块(Bad Block)。（引自网上的一篇文档）
但是每次写都会trig一个block的擦除，这个很要命，哪怕你就写1个bit进去，都需要把一个block擦除了写进去（当然没这么简单，这里只是简单描述下），这个机制决定了MLC NAND就不能这么老实的往里面写log 文件。
只能告诉软件让客户修改他们得软件，不能这么玩。
反思教训：
由于我们的客户之前的平台是PC，上面的HDD是没有写的限制的。当同样的思路应用在我们的系统上的时候，由于硬件的基本架构已经发生了根本性的改变，那么软件的思路也必须做出调整。
注释：
TAC：不是Tactical Air Command，是公司的售后技术服务团队；
RMA：Return Material Authorization的英文缩写，即退料审查；
还没人转发这篇日记
