启动驱动器是运行 Ubuntu 18.04 LTS 的 WD 1TB SSD……
我有 2 个阵列运行在 1 张 LSI 卡上... RaidMachine 中的 16 x 8tb IronWolf（Raid 6）[我的主要数据] SuperMicro 中的 11 x 10tb Exos（Raid 5）[备份]
一切都很好，几个月来一直很好。进行了一次小规模的 BIOS 更新（华硕主板运行 Ryzen 1700，OPCACHE 已禁用，一直很稳定）。重新启动后，Raid6 UUID 丢失。因此，我注释掉了启动所需的 raid6 的 FSTAB 条目，然后进入我的系统。Raid6 出现了奇怪的现象。也许有人知道发生了什么？如果知道，如何修复？我有 60TB 的数据，其中大约 50TB 已备份到运行良好的 raid5 阵列上。
我的统计数据如下...（为清晰起见已编辑）
检查 raid 后我得到了以下信息...正如你会注意到的...它显示的是 raid0 而不是 raid6...
/dev/md126:
Version : 1.2
Raid Level : raid0
Total Devices : 1
Persistence : Superblock is persistent
State : inactive
Working Devices : 1
Name : tbserver:0 (local to host tbserver)
UUID : 3d6402fe:8204e7c2:48b87456:8dc2cc39
Events : 650489
Number Major Minor RaidDevice
- 8 32 - /dev/sdc
当我查询唯一工作的驱动器时...我得到以下信息...
Personalities : [linear] [multipath] [raid6] [raid5] [raid10]
md126 : inactive sdc[16](S)
7813894488 blocks super 1.2
unused devices: <none>
这里应该列出了 16 个驱动器。很奇怪。如果我进入 DISKS，我会看到所有 16 个驱动器，但奇怪的是......
其中 15 个驱动器显示了这一点...
并且 1 个工作驱动器显示了这一点...
背景... 两个阵列都是用 mdadm 创建的。我没有使用任何类型的 POOL 或 LVM。每个 raid 的所有驱动器的大小和类型都相同。
我马上注意到的是……15 个丢失的驱动器显示为 Microsoft 分区。怎么回事？这台机器运行的是 Ubuntu 基本安装。
我的 FSTAB
#raid6 2019-10-24
UUID=6db81514-82d6-4e60-8185-94a56ca487fe /raid6 ext4 errors=remount-ro,acl 0 1
这以前有效。奇怪的是... UUID 不再存在，当我获取 sdc 驱动器的详细信息时... 唯一显示的... 它有一个不同的 UUID... 也许那是单个驱动器的 UUID？
我绝对不是专家。我可以做很多事情，在编程、修补等方面有 40 年的计算机背景……但是，在我开始修补它之前……也许会把它弄坏？！？！
以前有人见过这种情况吗？我在这台华硕机器的 BIOS 中做了什么操作，导致 BIOS 写入任何驱动器吗？！？！如果是这样，为什么它没有破坏 Raid5 阵列？！我不知道发生了什么...这是我的错误日志...
如果图像难以辨认...
Jun 27 15:02:35 tbserver udisksd[1573]: Error reading sysfs attr `/sys/devices/virtual/block/md126/md/degraded': Failed to open file “/sys/devices/virtual/block/md126/md/degraded”: No such file or directory (g-file-error-quark, 4)
Jun 27 15:02:35 tbserver udisksd[1573]: Error reading sysfs attr `/sys/devices/virtual/block/md126/md/sync_action': Failed to open file “/sys/devices/virtual/block/md126/md/sync_action”: No such file or directory (g-file-error-quark, 4)
Jun 27 15:02:35 tbserver udisksd[1573]: Error reading sysfs attr `/sys/devices/virtual/block/md126/md/sync_completed': Failed to open file “/sys/devices/virtual/block/md126/md/sync_completed”: No such file or directory (g-file-error-quark, 4)
有什么建议吗？有人见过这种奇怪的事情突然发生吗？15 个驱动器怎么会有第二个分区。这台机器上从来没有启动过 Microsoft 操作系统或任何东西。
BIOS 刷新后我唯一做的事情（在它能够启动之前）就是禁用 OPCACHE 以保证稳定性（旧款 Ryzens 需要这个）。在尝试启动几次后，我确实将 CSM 设置为 AUTO（以防我没有禁用它，但事实并非如此）。打开 CSM 可以将任何东西写入磁盘吗？！？！？
我认为我在 BIOS 中所能做的任何事都不会将一堆数据写入驱动器并创建新的分区!??!!?
非常感谢您抽出时间！David Perry Perry 计算机服务
编辑：我假设数组已被破坏。如果有人见过这种情况，我会非常想知道这是怎么发生的，或者任何相关信息都会很感激。
编辑-更新 shodanshok 提出的问题。 更多信息 - 在安装 Linux 之前，我确实对 Microsoft Storage Spaces 进行了修改，但发现它们很垃圾（很慢）。我在系统上全新安装了 Linux，并于 2019 年 9 月左右使用 MDADM 创建了阵列，从那时起，直到今天，一切都运行良好……所以，我不知道发生了什么……为什么存储空间“突然”出现了，而我已经很久没见过它们了。上面图片中 DISKS 中的所有驱动器看起来都像 sdc……在 raid 失败之前，从来没有任何分区 1 和 2……所以，非常奇怪……
david@tbserver:~$ sudo mdadm -E /dev/sda
/dev/sda:
MBR Magic : aa55
Partition[0] : 4294967295 sectors at 1 (type ee)
david@tbserver:~$ sudo mdadm -E /dev/sdc
/dev/sdc:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x1
Array UUID : 3d6402fe:8204e7c2:48b87456:8dc2cc39
Name : tbserver:0 (local to host tbserver)
Creation Time : Thu Oct 24 18:44:30 2019
Raid Level : raid6
Raid Devices : 16
Avail Dev Size : 15627788976 (7451.91 GiB 8001.43 GB)
Array Size : 109394518016 (104326.74 GiB 112019.99 GB)
Used Dev Size : 15627788288 (7451.91 GiB 8001.43 GB)
Data Offset : 264192 sectors
Super Offset : 8 sectors
Unused Space : before=264112 sectors, after=688 sectors
State : clean
Device UUID : bfe3008d:55deda2b:cc833698:bfac79c3
Internal Bitmap : 8 sectors from superblock
Update Time : Sat Jun 27 11:08:53 2020
Bad Block Log : 512 entries available at offset 40 sectors
Checksum : 631761e6 - correct
Events : 650489
Layout : left-symmetric
Chunk Size : 512K
Device Role : Active device 1
Array State : AAAAAAAAAAAAAAAA ('A' == active, '.' == missing, 'R' == replacing)
david@tbserver:~$ sudo mdadm -D /dev/sdc
mdadm: /dev/sdc does not appear to be an md device
为了提供更多信息 - 我添加了这个...
david@tbserver:~$ sudo gdisk /dev/sda
GPT fdisk (gdisk) version 1.0.3
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: 15628053168 sectors, 7.3 TiB
Model: ST8000VN0022-2EL
Sector size (logical/physical): 512/4096 bytes
Disk identifier (GUID): 42015991-F493-11E9-A163-04D4C45783C8
Partition table holds up to 128 entries
Main partition table begins at sector 2 and ends at sector 33
First usable sector is 34, last usable sector is 15628053134
Partitions will be aligned on 8-sector boundaries
Total free space is 655 sectors (327.5 KiB)
Number Start (sector) End (sector) Size Code Name
1 34 32767 16.0 MiB 0C01 Microsoft reserved ...
2 32768 15628052479 7.3 TiB 4202 MyPool
更新时间：2020-06-27 - 晚上 9:05（美国东部时间）- 我们认为发生的事情是，发生了一些损坏，当 Ubuntu 尝试自动修复阵列时，它发现了一些旧的 Microsoft raid 分区数据，并以某种方式将它们设为活动分区或类似的东西。这破坏了整个真正的 MDADM raid。奇怪的是...为什么 16 个驱动器中有 15 个？此外，为什么它会“自行”执行此操作而不要求确认！？！
我们现在不会擦除这些驱动器。我将从 2020 年 6 月 12 日开始提取备份 - 我丢失了大约 10TB 的数据。我正在使用 R-Studio 从另一台机器上恢复已删除的数据，以帮助减少 10TB 丢失的影响。从现在开始，我将在任何 Ubuntu 软件更新或将来的任何 BIOS 更新之前进行备份。 尽管我们在我第一次购买磁盘时就将其清零，以测试磁盘是否有坏扇区，并“接触”整个表面，但在测试并摆弄 Microsoft Spaces 后，我安装全新 Linux 时并没有将其清零，Microsoft Spaces 具有不错的读取性能，但写入性能却非常糟糕。 此外，我认为 MDADM 更加强大……我感觉这只是偶然发生的，现在我正在将这些磁盘清零，这种情况可能永远不会再发生。否则这些分区怎么会在完美运行 Linux 9 个月后“突然出现”？！？！一定是 Linux 内置了一些“恢复”软件来修复阵列，但它做出了错误的决定，因为它在驱动器上看到了一些旧结构，感到困惑……
这应该不会花很长时间...它的写入速度为 3.5GB/s - 每个驱动器约 207MB。
如果有人可以对此作出解释，我很想知道发生在我身上的事情是否也发生在其他人身上，以及我对此事的理论是否准确。
我想在将来，作为对每个人的一个教训，如果您使用其他 raid 或分区，请确保将驱动器中的旧 raid 数据全部擦除。这是我能想到的对所发生的事情的唯一解释... 我觉得如果 Linux 没有在驱动器上找到旧的 Microsoft Storage Spaces 分区数据，这根本不会成为问题。说实话，我很震惊它还在那里。我认为这是因为 MDADM 不会清除之前放在那里的任何东西。我的错，因为我走了捷径，没有将驱动器清零。将来，在重新创建任何新阵列之前，我将始终将整个阵列清零。
更新：2020-07-05... 我们非常确定我们已经找到了最初问题发生的原因（无论如何是最初的损坏，而不是恢复灾难）。在 BIOS 更新后，是的，我知道，一切都重置了。我确实按照预期关闭了在 Linux 中运行的旧 Ryzen 1700 的 OPCACHE。这是一个已知的错误。重建 raid 后发生的事情是，我可以连续几个小时复制文件，没有任何问题，然后噗……rsync 没有显示任何活动……没有错误消息，什么都没有……我稍微提高了 SOC 电压……并且能够连续几天复制数 TB 的数据而没有任何问题。所以，我发现这块华硕主板中的“默认”设置不稳定，这很麻烦。我更改的设置是……
VDDCR SOC Voltage to OFFSET MODE + 0.02500
VDDCR CPU Load Line Calibration to Level 2
VDDCR SOC Load Line Calibration to Level 2
VDDCR SOC Power Phase Control to Extreme
系统再次稳定运行。我还和一个朋友聊过，他有一台 3950x 运行在 B350 主板上，他必须更改相同的设置才能让他的电脑在 Linux 中通过 Prime 95。
基于这些电压调整，我没有注意到系统产生任何额外的热量。我仍然在运行 Ryzen Wraith Prism 风扇风冷，这对于 1700 来说有点过头了，但它是一款漂亮而安静的风扇。我的内存只有 Crucial DOCP，在 QVL 上以 2666Mhz 运行。
我的数据恢复终于在几天前完成了，但无论如何我认为我应该分享我对损坏的解决方案。我仍然担心将来会在驱动器上留下旧的 raid 数据。如上所述，我们将整个阵列清零，所以我怀疑这种情况不会再发生。
感谢我的老朋友 Doug Gale 帮助我让系统再次变得稳定。如果不知道这些电压调整，我就不得不重建系统，谁知道呢，也许问题会再次出现……如果有人好奇的话，我还使用了 Crucial Gold Rated PSU…… :) 和 Cyperpower Dual 1500VA 备用电源。