标签: md

在他对“混合突袭类型”问题的回答中，HBruijn 建议使用 LVM 来实现 RAID，而不是更标准的 MDRAID。

经过一番调查，LVM 似乎也支持 RAID 功能。过去，我在 MDRAID 之上使用 LVM，直到现在才知道 LVM 也支持 RAID 功能。这似乎是一个相对较新的发展，但我还没有确切地知道这是什么时候实施的。

因此，这些是在 Linux 上实现软件 RAID 的替代方法。这两种不同方法的优缺点是什么？我正在寻找两种方法之间的功能比较，以便人们可以决定哪种方法更适合他们。如果您在答案中包含您的数据，则基于实验的结论（例如，此功能不如此功能好用，这就是原因）也可以。

要解决的一些具体问题：

1. 假设我想做 sw RAID + LVM（一个常见的场景）。我应该使用 LVM 对 sw RAID 的支持，从而使用一个实用程序而不是两个实用程序吗？这种更集成的方法有什么优势吗？
2. LVMs 对 sw RAID 的支持与更成熟的 MDADM 相比是否有明显的不足？具体来说，LVM 对 sw RAID 的支持有多稳定/无错误？这种支持似乎只能追溯到 2011 年（见下文），而 MDADM 则要老得多。另外，它在功能集方面如何比较？与 MDADM 相比，它是否有明显的功能缺陷？相反，它是否支持 MDADM 没有的任何 sw RAID 功能？

笔记：

1. 在http://www.olearycomputers.com/ll/linux_mirrors.html 上有详细的讨论， 但我不知道它的写作日期。

   Serverfault 上的类似问题：linux LVM mirror vs. MD mirror。不过这个问题是2010年问的，答案可能已经过时了。

2. 2.02.87 版的变更日志条目 - 2011 年 8 月 12 …

在较新的系统上/usr/share/mdadm/mkconf（用于生成的脚本/etc/mdadm/mdadm.conf）倾向于使用设备名称/dev/md/0而不是/dev/md0：

new-system ~ # /usr/share/mdadm/mkconf | grep ARRAY
ARRAY /dev/md/0 metadata=1.2 UUID=a0021927:0e4f10bf:2c47dc72:ca0b352e name=unassigned:0

这可能会给期望/dev/md0在那里的用户带来一些刺激，但显然它运行良好，因为服务器启动时没有问题。

在/proc/mdstat设备中仍称为/dev/md0：

new-system ~ # cat /proc/mdstat
Personalities : [raid1]
md0 : active raid1 sdb2[2] sda2[0]
      1953381184 blocks super 1.2 [2/2] [UU]

unused devices: <none>

ls显示这/dev/md/0是一个符号链接/dev/md0：

new-system ~ # ls -l /dev/md/0 
lrwxrwxrwx 1 root root 6 Nov 20 14:06 /dev/md/0 -> ../md0

在另一个旧系统上mkconf仍然使用/dev/md0，并且 …

TL;DR 摘要：将 md 扇区号转换为/dev/mdX设备内的偏移量，以及如何使用xfs_db. 扇区号来自sh->sectorin linux/drivers/md/raid5.c:handle_parity_checks5()。

我不知道 MD 内部结构，所以我不知道如何处理printk我添加的日志记录的输出。

组件设备的偏移（用于dd或十六进制编辑器/查看器）也很有趣。

我想我应该在 Linux-raid 邮件列表上问这个问题。是仅限订阅者，还是可以不订阅就发帖？

我的桌面（没有 LVM）直接在 4 个磁盘的 MD RAID5 上安装了 xfs。最近的mismatch_cnt清理检测到非零值（实际上是 8，因为 md 一次在 4kiB 页面上运行）。

这是 RAID5，而不是 RAID1/RAID10 ，其中mismatch_cnt!= 0 在正常操作期间可能发生。（此 wiki 页面底部的其他链接可能对某些人有用。）

我可以只是盲目地repair，但是除了失去选择重建方式的任何机会之外，我不知道要检查哪个文件可能损坏。 Frostschutz 对类似问题的回答是我找到的唯一建议，用于追踪文件系统中的差异。它既麻烦又缓慢，我宁愿使用更好的方法先将其缩小到几个文件。

内核补丁添加日志记录

奇怪的是，md 的检查功能没有报告发现错误的位置。 我加入了printk在MD / raid5.c记录sh->sector在if该增量分支mddev->resync_mismatches中handle_parity_checks5()（小片在github上发布，最初基于4.5 RC4从kernel.org。）对于这个是确定用于一般用途，它可能会需要避免在修复中大量不匹配的日志（可能只在新值 …

我最近从硬件 RAID1 机箱转移到使用两个带有 md 的 eSATA 驱动器。一切似乎都运行良好，除了目录遍历/列表有时会爬行（大约 10 秒）。我使用的是 ext3 文件系统，块大小设置为 4K。

以下是一些应该很重要的命令的相关输出：

mdadm --详细信息：

/dev/md127:
        Version : 1.2
  Creation Time : Sat Nov 16 09:46:52 2013
     Raid Level : raid1
     Array Size : 976630336 (931.39 GiB 1000.07 GB)
  Used Dev Size : 976630336 (931.39 GiB 1000.07 GB)
   Raid Devices : 2
  Total Devices : 2
    Persistence : Superblock is persistent

    Update Time : Tue Nov 19 01:07:59 2013
          State : clean
 Active Devices : 2
Working Devices : 2 …

在 Ubuntu 18.04 上，我创建了一个 RAID 1 阵列，如下所示：

mdadm --create /dev/md/myarray --level=1 --run --raid-devices=2 /dev/sdc /dev/sdd

然后我将输出添加mdadm --detail --scan /dev/md/myarray到 /etc/mdadm/mdadm.conf。它看起来像这样：

ARRAY /dev/md/myarray metadata=1.2 name=MYHOSTNAME:myarray UUID=...

设备名称以“MYHOSTNAME:”为前缀。此时符号链接/dev/md/myarray仍然存在，但在我第一次重新启动后，它变成了/dev/md/MYHOSTNAME:myarray，破坏了一切。更糟糕的是，这只发生在某些机器上 - 在其他机器上，符号链接仍然存在/dev/md/myarray。所有人都在运行 Ubuntu 18.04，所以我不知道为什么。

如何为我的 MD 设备获得一致的设备路径，最好是我指定的确切路径（“/dev/md/myarray”）？我尝试编辑 mdadm.conf 以删除主机名，但即使该行说

ARRAY /dev/md/myarray metadata=1.2 name=myarray UUID=...

符号链接在重新启动时仍然会更改 - 在“想要”主机名的机器上。我也尝试过另一种方式并在两个地方添加主机名：

ARRAY /dev/md/HOSTNAME:myarray metadata=1.2 name=HOSTNAME:myarray UUID=...

但是再次在“不想要”主机名的机器上，符号链接在重新启动后变为 /dev/md/myarray ！

我也不能使用数字设备 (/dev/md127)，因为当有多个像这样创建的 MD 设备时，它们也倾向于在 md126 和 md127 之间交替！这太疯狂了！

有2种情况：

• read 命令在内核级别超时（默认为 30 秒），
• 在内核失去耐心之前，驱动器报告它无法读取给定扇区（我感兴趣的情况）。

内核超时

由于驱动器访问通常通过 Linux SCSI 层，我认为超时情况完全由该层处理。根据此文档，它会在重置驱动器、总线、主机等后多次尝试该命令。如果这些都不起作用，SCSI 层将使设备脱机。在这一点上，我认为 md 层只是“发现”一个驱动器不见了，并将其标记为丢失（失败）。这样对吗？

驱动器报告错误

某些驱动器可以配置为在达到特定超时后报告读取错误，从而中止内部恢复尝试。这称为ERC（或 TLER、CCTL）。磁盘超时通常配置为在操作系统超时（或硬件 RAID 控制器）之前触发，以便后者知道真正发生了什么，而不仅仅是“等待和中止”。

我的问题是：Linux（和 md）如何处理驱动器报告的读取错误？

它会再试一次，做一些聪明的事情，还是只是让驱动器脱机而不通过上面“内核超时”中描述的所有尝试？当这种事情发生时，md 甚至知道吗？

有些人认为ERC 在 Linux 上很危险，因为它不会给驱动器足够的时间来尝试恢复。他们还说 ZFS-raid 很好，因为如果发生读取错误，由于 RAID 冗余，它会计算丢失的不可读扇区数据，并将其覆盖回驱动器。然后后者应该停止尝试读取讨厌的扇区，自动将其标记为坏的（不再使用），并将其重新映射到一个良好的扇区。

md 也能做到这一点吗？

我的系统有问题（内部电源线有问题）。当我让系统备份并运行、重建阵列等时，我似乎遇到了这样一种情况：pvs命令（vgs和lvs）报告No device found for PV <UUID>但在据称丢失的物理卷上的逻辑卷可以成功挂载，因为它们的 DM 设备存在并映射到/dev/mapper.

PV 设备是一个 md-raid RAID10 阵列，看起来不错，只是令人困惑的是它没有出现在pvs输出中。

我认为这是一些内部表不同步的问题。我如何正确映射事物（无需重新启动，我认为可以修复它）？

更新：

重新启动并没有解决问题。我认为这个问题是由于将“缺失”PV（/dev/md99）配置为由 750b 磁盘（/dev/sdk）和 RAID0 阵列（/dev/md90）构建的 RAID10 far-2 阵列来自 250GB 磁盘 (/dev/sdh) 和 500GB 磁盘 (/dev/sdl)。从输出看来pvscan -vvv，lvm2 签名是在 /dev/sdh 上找到的，而不是在 /dev/md99 上。

    Asking lvmetad for VG f1bpcw-oavs-1SlJ-0Gxf-4YZI-AiMD-WGAErL (name unknown)
  Setting response to OK
  Setting response to OK
  Setting name to b
  Setting metadata/format to lvm2
    Metadata cache has no info …

我有一个 2 磁盘 CentOS 7 机器构建，我需要数据完整性/位腐烂保护。我怎样才能实现这个目标？

根据我的阅读，btrfs、zfs 和 DM-Integrity 似乎不是选项。

• Btrfs 不是一个选项，因为 RHEL 和 CentOS 将弃用 btrfs。
• RHEL/CentOS 本身不支持 ZFS，并且 RH 将来也不打算支持它。此外，2018 年 4 月 ZFSonLinux 的数据损坏错误对于该实现来说并不是一个好兆头。
• DM-Integrity 不是一个选项，因为内核版本较旧，而且据我所知在 CentOS 上不可用。
• 看来使用 md（在 4 个分区上）的 RAID6 不是选项，因为据我所知它不会计算每次读取的校验和。根据这个答案，磨砂膏可能无法正确修复。

注意 选择 CentOS 是为了稳定性和长期支持。

在 linux mdadm 手册页中，我看到了“--write-journal”选项。

这与 lvmcache 有什么关系，因为 lvmcache 是建立在 dm-cache 之上的？它们是不同的东西，还是 lvmcache 在幕后做了诸如“--write-journal”之类的事情？

谢谢！

我在 KVM（虚拟机管理器 1.3.2）中有 3 个 Ubuntu 17.10 来宾的 Ubuntu 16.04 主机。

我通过util创建的 iSCSI 门户将几个块设备从 2 个来宾导出到另一个来宾（我们称之为前端）targetcli。导入它们后，我大量使用multipath来查找相同的“物理”磁盘并md创建 RAID 10（例如，mdadm --create --quiet --metadata=1.2 /dev/md1 --level=1 --raid-devices=2 /dev/dm-10 /dev/dm-1）。然后我需要清除这些信息。

问题来了：它不会擦拭。我经历了通常的步骤（比如，清洁md1）：

1) mdadm -S /dev/md1

2) mdadm --zero-superblock /dev/md1

3) mdadm --zero-superblock /dev/mapper/md1

一切似乎都很好，直到我删除导入的磁盘并在一段时间后重新导入它们：它们随机出现在 RAID 中。有时 RAID 组名称与最初创建的相差很远（例如 md126 和 md127，而我只创建了 md1、md2、... md12）。这些僵尸 RAID 可以用 掩埋mdadm -S，但它们会在下次导入块设备时再次出现。

为什么--zero-superblock不能完成它的工作？

UPD：正如@roaima 所提到的，命令 2 和 3 等确实返回错误：

Couldn't open /dev/md1 for …