WD MyCloud卷故障问题的解决

肺炎性长假期间闲来无事，把原来故障无法读取的WD MyCloud自带3T硬盘又翻出来，看能不能修复。一番折腾后，竟然用Disk Genuis格式化成功。貌似出问题的扇区刚好是某分区的起始位置，只要不在乎数据丢失，能忍受Windows试图加载分区的超长等待和出错后，最终用DG的扫描和修复功能成功修复格式化，连原先SMART的C5告警都恢复正常了，现在硬盘看上去没有任何异常。

接下来自然就要恢复WD MyCloud了。参考原来写过的教程 WD MyCloud救砖笔记，很快完成刷机，并按照预期正常进入系统UI界面、设置硬盘工作模式、自动格式化等等，完成后也能看见硬盘空间为2.94T，看上去一切正常。然而，一次重启之后，系统UI界面出现一个警告，且磁盘空间显示为0。反复重启都是这个错误。

image.png

开启SSH服务并登录后，用mount命令，发现 /dev/sda2这个2.9TB的主数据分区，并没有被挂载。正常情况下，它应该被挂载到 /mnt/HD/HD_a2目录。难道分区创建的时候有问题？又按照俄罗斯大神的教程反复尝试几次，结果都一样，只要经历一次重启，数据分区就无法挂载。

查找相关错误资料，无意中发现某个记录硬盘升级扩容的帖子中，分区步骤比俄罗斯大神的步骤多了一步：mkfs.ext4 /dev/sda2，也就是把/dev/sda2格式化为ext4格式，难道是这个问题？

于是在WD MyCloud已经刷机，UI界面能正常启动的情况下，SSH登录上去，用gdisk 查看分区信息，如下：

root@WDMyCloud /etc # gdisk /dev/sda
GPT fdisk (gdisk) version 0.8.10

Partition table scan:
  MBR: protective
  BSD: not present
  APM: not present
  GPT: present

Found valid GPT with protective MBR; using GPT.

Command (? for help): p
Disk /dev/sda: 5860533168 sectors, 2.7 TiB
Logical sector size: 512 bytes
Disk identifier (GUID): F240F7A7-A98C-4B85-83B8-814D0937E04F
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 5860533134
Partitions will be aligned on 2048-sector boundaries
Total free space is 2014 sectors (1007.0 KiB)

Number  Start (sector)    End (sector)  Size       Code  Name
   1            2048         4196351   2.0 GiB     8200  Linux swap
   2        16779264      5860533134   2.7 TiB     0700  Microsoft basic data
   3        14682112        16779263   1024.0 MiB  0700  Microsoft basic data
   4         4196352         6293503   1024.0 MiB  0700  Microsoft basic data
   5         6293504         8390655   1024.0 MiB  0700  Microsoft basic data
   6         8390656        12584959   2.0 GiB     0700  Microsoft basic data
   7        12584960        14682111   1024.0 MiB  0700  Microsoft basic data

可以看到第二个分区，也就是sda2的分区类型是0700，Microsoft basic data。难道这就是原因？
用命令行mke2fs -t ext4 /dev/sda2，把sda2格式化为ext4分区，然后重启系统，一切恢复正常，多次重启也没问题。

你以为到这里就结束了吗？其实还有未解之谜。

格式化为ext4后，用gdisk查看，分区类型还是显示0700 Microsoft basic data，但系统运行一切正常，mount命令的输出中有下面这行：

/dev/sda2 on /mnt/HD/HD_a2 type ext4 (rw,noatime,nodiratime,barrier=0,usrquota,grpquota)

看来分区类型和操作系统实际加载所使用的分区类型参数，可以不一致？
搜索资料，发现这篇文章说了一段：

Disk partition tables include type codes, which are coded names or numbers associated with specific uses of partitions. OSes can use the type codes as they see fit. For the most part, Linux ignores partition type codes, but Windows doesn't—it uses partition type codes as a filter to determine which partitions to attempt to use. Specifically, the Microsoft Basic Data type code (EBD0A0A2-B9E5-4433-87C0-68B6B72699C7) identifies a filesystem that Windows can understand, such as FAT or NTFS. Unfortunately, for years Linux has used this same type code to identify its filesystem partitions on GPT disks;

大意就是，Linux通常会忽略分区识别符。Microsoft Basic Data这种格式，本来是微软用来标记Windows能识别的分区格式的，而很不幸Linux刚好也用了相同的代码来标识为GPT分区。

回想刷机步骤中，并没有对sda2进行格式化，所以分区实际上应该没有建立正确的ext4格式，导致系统挂载失败。不过，为什么刷机后第一次启动时，系统能够识别出硬盘并提示格式化成功呢？为什么系统自己格式化没有格式化成ext4呢？这个我没找到答案。

俄罗斯大神的刷机步骤，很可能是在一块曾经正常使用的硬盘上进行的，即使硬盘分区被删除并重建，因为分区的位置不变，分区后可能还存在符合ext4格式的分区信息，这样挂载就可以成功。而我在修复硬盘时抹去了一些信息，这种情况下，就必须手动进行一次格式化。

最终总结：

1. Linux可能会忽略分区标识，而只是按照挂载参数使用分区。
2. WD MyCloud在系统初始化时，很可能没有真正按照ext4来格式化数据分区，从而导致挂载失败。
3. 要解决问题，可以在进行分区时，用mkfs.ext4命令格式化sda2，也可以在刷机完成后用mke2fs命令格式化。
4. 只要不顾虑数据丢失，WD MyCloud随便怎么刷，放心刷。