阵列降级然后显示存储空间损坏无法挂载
情况一
输入
lsblk查看所有磁盘
sdb 8:16 0 3.6T 0 disk
└─sdb1 8:17 0 3.6T 0 part
└─md127 9:127 0 0B 0 raid5
sdc 8:32 0 3.6T 0 disk
└─sdc1 8:33 0 3.6T 0 part
└─md127 9:127 0 0B 0 raid5
sdd 8:48 0 111.8G 0 disk
├─sdd1 8:49 0 94M 0 part /boot/efi
├─sdd2 8:50 0 79.9G 0 part /
└─sdd3 8:51 0 31.8G 0 part
sde 8:64 0 3.6T 0 disk
└─sde1 8:65 0 3.6T 0 part
└─md127 9:127 0 0B 0 raid5从上个输出中，我们可以看到此用户组了raid5 但是实际上还有个sda磁盘只是我没复制。然后实际上是用了4个盘组了raid5但是由于sda磁盘降级，所以我们仍然可以使用剩下三个磁盘sdb1 sdc1 sde1）组成降级raid5。
如果看到的是部分磁盘下面没有显示md127类似字眼而是直接是一个sdb1的分区相关（如果连sdb1都没有 直接一个sdb说明这是一个完全没有被分区的硬盘，就不要操作了），请按照情况2进行处理
停止md127阵列（从上面可以获得md127在每个磁盘都有所以他是个阵列标识符）
mdadm --stop /dev/md127尝试以降级模式拉起阵列
mdadm --assemble --force --run /dev/md127 /dev/sdc1 /dev/sdb1 /dev/sde1注意 /dev/sdc1 /dev/sdb1 /dev/sde1 这几个需要替换成你阵列的磁盘盘符 。
然后我们进入飞牛就可以看到存储空间已经是被了，点击挂载稍等片刻即可
情况二
输入
lsblk查看所有磁盘
sda 8:0 0 2.7T 0 disk
└─sda1 8:1 0 2.7T 0 part
sdb 8:16 0 2.7T 0 disk
└─sdb1 8:17 0 2.7T 0 part
sdc 8:32 0 2.7T 0 disk
└─sdc1 8:33 0 2.7T 0 part
└─md0 9:0 0 0B 0 raid5
sdd 8:48 0 111.8G 0 disk
├─sdd1 8:49 0 94M 0 part /boot/efi
├─sdd2 8:50 0 63.9G 0 part /
└─sdd3 8:51 0 47.8G 0 part
sde 8:64 0 2.7T 0 disk
└─sde1 8:65 0 2.7T 0 part
└─md0 9:0 0 0B 0 raid5与情况一不同，这个情况我们可以看到 md0 是一个raid5阵列，从上述分区我们看出sda1 sdb1 应该也是raid5阵列的一部分，但是可能由于断电或者数据线主板问题造成突然在传输过程中中断导致阵列信息受损，这种情况我们仍然可以强行拉起数据但有较大可能出现部分文件损坏的可能性。
以下命令中涉及的 /dev/sda 之类的字眼需要替换为对应操作的盘符！
确认可能的阵列盘符是否是Linux RAID
fdisk -l /dev/sda /dev/sdb这行代码输出中我们只需要看每个硬盘是否包含Linux RAID 的字符，如果没有说明这个盘不是阵列盘，请勿往下操作。
确认raid超级块中的阵列ID是否一致和Events值
mdadm --examine /dev/sda1
mdadm --examine /dev/sdb1
mdadm --examine /dev/sdc1
mdadm --examine /dev/sde1示例返回
#sda盘
/dev/sda1:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x1
Array UUID : 41b98f7a:d2629480:0d6ba7ae:4f46844a
Name : 1101:0 (local to host 1101)
Creation Time : Fri Mar 14 15:34:45 2025
Raid Level : raid5
Raid Devices : 4
Avail Dev Size : 5860269056 sectors (2.73 TiB 3.00 TB)
Array Size : 8790398976 KiB (8.19 TiB 9.00 TB)
Used Dev Size : 5860265984 sectors (2.73 TiB 3.00 TB)
Data Offset : 261120 sectors
Super Offset : 8 sectors
Unused Space : before=261040 sectors, after=3072 sectors
State : clean
Device UUID : a304a755:2df34e4f:b5775b77:cf4148f5
Internal Bitmap : 8 sectors from superblock
Update Time : Sat Apr 19 16:15:49 2025
Bad Block Log : 512 entries available at offset 24 sectors
Checksum : 828e9b9a - correct
Events : 10199
Layout : left-symmetric
Chunk Size : 512K
Device Role : Active device 3
Array State : AAAA ('A' == active, '.' == missing, 'R' == replacing)
#sdb盘
/dev/sdb1:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x1
Array UUID : 41b98f7a:d2629480:0d6ba7ae:4f46844a
Name : 1101:0 (local to host 1101)
Creation Time : Fri Mar 14 15:34:45 2025
Raid Level : raid5
Raid Devices : 4
Avail Dev Size : 5860269056 sectors (2.73 TiB 3.00 TB)
Array Size : 8790398976 KiB (8.19 TiB 9.00 TB)
Used Dev Size : 5860265984 sectors (2.73 TiB 3.00 TB)
Data Offset : 261120 sectors
Super Offset : 8 sectors
Unused Space : before=261040 sectors, after=3072 sectors
State : active
Device UUID : f9ed027c:ec6d42bd:47db6b90:b771b3db
Internal Bitmap : 8 sectors from superblock
Update Time : Sat Apr 19 16:18:59 2025
Bad Block Log : 512 entries available at offset 24 sectors
Checksum : 16559411 - correct
Events : 10241
Layout : left-symmetric
Chunk Size : 512K
Device Role : Active device 1
Array State : AAA. ('A' == active, '.' == missing, 'R' == replacing)
#sdc盘
/dev/sdc1:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x1
Array UUID : 41b98f7a:d2629480:0d6ba7ae:4f46844a
Name : 1101:0 (local to host 1101)
Creation Time : Fri Mar 14 15:34:45 2025
Raid Level : raid5
Raid Devices : 4
Avail Dev Size : 5860269056 sectors (2.73 TiB 3.00 TB)
Array Size : 8790398976 KiB (8.19 TiB 9.00 TB)
Used Dev Size : 5860265984 sectors (2.73 TiB 3.00 TB)
Data Offset : 261120 sectors
Super Offset : 8 sectors
Unused Space : before=261040 sectors, after=3072 sectors
State : clean
Device UUID : 8906c1eb:57063654:0fccb9cd:37a719ca
Internal Bitmap : 8 sectors from superblock
Update Time : Sat Apr 19 16:19:30 2025
Bad Block Log : 512 entries available at offset 24 sectors
Checksum : 48b86b77 - correct
Events : 10245
Layout : left-symmetric
Chunk Size : 512K
Device Role : Active device 0
Array State : A.A. ('A' == active, '.' == missing, 'R' == replacing)
#sde盘
/dev/sde1:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x1
Array UUID : 41b98f7a:d2629480:0d6ba7ae:4f46844a
Name : 1101:0 (local to host 1101)
Creation Time : Fri Mar 14 15:34:45 2025
Raid Level : raid5
Raid Devices : 4
Avail Dev Size : 5860269056 sectors (2.73 TiB 3.00 TB)
Array Size : 8790398976 KiB (8.19 TiB 9.00 TB)
Used Dev Size : 5860265984 sectors (2.73 TiB 3.00 TB)
Data Offset : 261120 sectors
Super Offset : 8 sectors
Unused Space : before=261040 sectors, after=3072 sectors
State : clean
Device UUID : fb0e1ecc:4ab3f961:6aa53f6d:f1b64f5c
Internal Bitmap : 8 sectors from superblock
Update Time : Sat Apr 19 16:19:30 2025
Bad Block Log : 512 entries available at offset 24 sectors
Checksum : 689509f2 - correct
Events : 10245
Layout : left-symmetric
Chunk Size : 512K
Device Role : Active device 2
Array State : A.A. ('A' == active, '.' == missing, 'R' == replacing)每个raid都有一个自己UUID，这个UUID是统一且唯一的，如果这些盘里的所有UUID都是一样，说明他们均来自一个阵列
我们只需要看每个盘的输出Array UUID 值是否全部一样，如果一样说明他们均来自一个阵列。如果出现差异这个差异的盘可能是来自其它阵列，请根据实际情况进行操作。
Events 的值称作为 事件计数 理论来讲所有阵列磁盘中的事件计数值应当是一样的，但是在本情况中您的Events值可能是不一样，因为如果都一样那么飞牛在开机的时候可以自动挂载或者是情况一，就是因为不一样存在了数据差异造成系统无法判断这里的数据是否完整。如果这个值不一样，一般以最大值的盘为准，小于这个值的所有盘数据可能是在写入过程中中断，恢复起来有概率部分文件无法正常读取。
本示例中我们可以看sdc1 和sde1 是一样的，而且在lsblk的指令输出中可以看到系统也识别为raid5。但是sda 和sdb 是不一样，所以lsblk的命令中没有标记阵列。
停用阵列
接下来我们需要强行拉起阵列，首先需要先停掉md0阵列以确保系统释放资源，否则我们无法操作。
mdadm --stop /dev/md0强行以降级模式拉起阵列。
由于我们数据不一致造成阵列无法自动识别，并且在事件数不一致的情况下我们需要让系统不计任何代价尝试拉起阵列（尽管数据有损坏）但是由于4盘raid5阵列至少需要3个硬盘才能拉起来（阵列总盘数减1等于需要拉起来的盘数量）上面我们说到Events 这个值，这个时候我们需要用到，因为示例中sda和sdb的值不一样，我们需要取这两个盘中的Events值最大的一个（表示数据差异最小的）作为raid5阵列的一部分才能拉起阵列读取数据（如果你的raid5盘数更多就依次类推，从大到小选择Events值进行组建）。
mdadm --assemble --force --run /dev/md0 /dev/sdc1 /dev/sde1 /dev/sdb1关键参数：
--force：强制同步事件计数并忽略不一致。
--run：允许以降级模式启动阵列（即使缺少 1 个磁盘）
为何选择这三个磁盘：
sdc1, sde1（事件计数 10245）和 sdb1（更新为 10245）数据最新。
sda1（事件计数 10199）数据较旧，暂时排除以减少数据不一致风险。
这个时候我们回到飞牛重新打开磁盘界面你应该就能看到存储空间回来了，我们只需要点击挂载稍等片刻即可。
挂载后建议您第一时间进行数据备份不要急忙重建阵列！避免再次掉盘造成数据不可逆的损坏。
问题总结
飞牛系统在处理阵列是比较保守，用的都是Linux底层，所以飞牛是不会导致阵列无辜损坏，到目前为止，我处理了多起阵列损坏案例所有案例中的系统内核日志输出均出现ATA 相关控制器报错，这个报错是由于主板控制器或者线缆问题造成数据传输过程中出现异常造成的掉盘。另外Btrfs的文件系统虽然功能很多，但是牺牲了可靠性，所以后续会推出ext4文件系统以主打可靠性。
为什么恢复了阵列之后不要急忙重建？
我遇到有些人不相信我这句话后来在我这里包月，因为无辜掉盘以及重启掉盘到目前为止都是硬件兼容问题，我们无法保证他在下次读写操作过程是否还会损坏，而且重建过程是一个非常消耗磁盘尤其是raid5，一旦重建过程中再次出现传输问题，那么阵列仍然会损坏，需要重新尝试恢复，尝试次数多了就会有更高的概率造成文件损坏甚至不可逆的损坏，所以我们在拉起之后一定要第一时间备份数据，然后再尝试重建
那我拉起阵列后应该怎么做？
ATA的报错一般是控制器，我们可以从网上购买稍微贵一点质量好一点的SATA线，把每个硬盘sata线都换了。然后确保数据已备份完毕然后删除这个存储空间重新做阵列，然后将备份数据写入进阵列正常使用5-7天如果没有突然掉阵列即可删除掉备份盘。
如果换线了仍然不行，那么考虑是主板太老对Linux兼容性较差，可以升级bios或更换主板。