我inheritance了一个NAS服务器，它由5个RAID1软arrays组成一个XFS卷组。
谁build立了第五个MD设备，没有一个Linux自动RAID分区（看起来他们做了一个mdadm – 创build使用原始磁盘（即/ dev / sdj / dev / sdk）。它一直工作到现在为止，但今天整个/ dev / md5arrays消失了。
The /dev/sdj drive appears to be in the process of failing. Buffer I/O error on /dev/sdj logical block 0 Buffer I/O error on /dev/sdj logical block 1 Buffer I/O error on /dev/sdj logical block 2 Buffer I/O error on /dev/sdj logical block 3 通常情况下，我会预料到RAID会使设备出现故障，但保持arrays与第二个驱动器。 当我cat / proc / mdstat但是，我的MD5设备已经消失。 我怀疑这是因为这两个驱动器没有自动RAID分区，但我不确定。
我试图重新创build使用md5数组
mdadm --create /dev/md5 --level=1 --raid-devices=2 /dev/sdj /dev/sdk
但是它说sdj已经是RAID设备的一部分了
奇怪的是，XFS卷组看起来仍然工作正常 – 没有数据丢失，据我所知，df仍然显示所有可用的空间。 难道是XFS仍然可以看到/ dev / sdk驱动器，并且可以成功写入吗？ sdj和sdk都有一个fdisk -l。
我的问题是：
pvscan的输出：
pvscan /dev/sdj: read failed after 0 of 4096 at 0: Input/output error /dev/sdj: read failed after 0 of 4096 at 2000398843904: Input/output error PV /dev/sdd2 VG VolGroup00 lvm2 [74.41 GB / 0 free] PV /dev/md2 VG dedvol lvm2 [931.51 GB / 0 free] PV /dev/md3 VG dedvol lvm2 [931.51 GB / 0 free] PV /dev/md0 VG dedvol lvm2 [931.51 GB / 0 free] PV /dev/md4 VG dedvol lvm2 [931.51 GB / 0 free] PV /dev/sdj VG dedvol lvm2 [1.82 TB / 63.05 GB free] Total: 6 [5.53 TB] / in use: 6 [5.53 TB] / in no VG: 0 [0 ]
磁盘/ dev / sdj：2000.3 GB，2000398934016字节 255个磁头，63个扇区/磁道，243201个磁道 单位= 16065 * 512 = 8225280字节的柱面 磁盘/ dev / sdj不包含有效的分区表 磁盘/ dev / sdk：2000.3 GB，2000398934016字节 255个磁头，63个扇区/磁道，243201个磁道 单位= 16065 * 512 = 8225280字节的柱面 Disk / dev / sdk不包含有效的分区表
mdadm --misc -Q / dev / sdj / dev / sdj：不是一个md数组 / dev / sdj：找不到md超级块，不是md组件。 mdadm --misc -Q / dev / sdk / dev / sdk：不是一个md数组 / dev / sdk：device 0 in 2 devicedetected raid1 / dev / md5。 使用mdadm - 查看更多细节。
mdadm --examine / dev / sdk
的/ dev / SDK：
魔术：a92b4efc
版本：0.90.00
UUID：25ead1e4：9ab7f998：73875d59：48b17be5
创作时间：周五11月26日21:10:49 2010
团队副本：raid1
二手开发大小：1953514496（1863.02 GiB 2000.40 GB）
数组大小：1953514496（1863.02 GiB 2000.40 GB）
RAID设备：2
设备总数：2
优先轻微：5
更新时间：2011年3月26日星期六07:43:52
状态：干净
有源器件：2
工作设备：2
失败的设备：0
备用设备：0
校验和：35a405cb - 正确
事件：5720270
数量主要次要RaidDevice状态
这个0 8 144 0活动同步/ dev / sdj
0 0 8 144 0活动同步/ dev / sdj
1 1 8 160 1主动同步/ dev / sdk
所以，根据/dev/sdk上的超级块，有一个/dev/md5和sdj在那里，但根据/dev/sdj ，没有raid超级块。 我担心的是/dev/sdj被添加到md5数组中，然后/dev/sdj被添加到卷组（而不是/dev/md5 ），并且在某些时候lvm已经开始覆盖标识为RAID设备的成员。 我担心这一点，因为我真的不能想到任何其他方式/ dev / sdj将最终被专门命名在LVM组，并没有一个RAID超级块了。
最糟糕的情况是：/ dev / sdj和/ dev / md5都被添加到了LVM中。 现在，您的XFS分区是否比LVM中的5.5 TB大？ 如果是这种情况，你应该可以使用mdadm --assemble来获取md5，但是你需要确保它在没有sdj的情况下以降级模式启动，所以它不会覆盖那里的数据。
（…你今天之前曾经看过pvscan吗？）
如果你没有备份，现在是时候开始了。 如果你这样做了，现在是testing他们的时候了（如果他们不工作，你没有备份，见步骤1）。
有没有一个简单的方法摆脱这个混乱，我不知道如果你在这个时候重新启动会发生什么（你可以卸载文件系统？）。 如果我确定实际发生的事情是sdj作为raid驱动器和 lvm物理卷添加了（因为lvm没有使用raid驱动程序写入sdj，所有写入sdj的数据都不是在SDK上…也许这可以通过比较/ dev / sdj和/ dev / sdk的各种块的hex转储和比我聪明的人谁知道很好的地方寻找的东西，会说“这是XFS”与“这是随机的胡言乱语或空白驱动器“？），那么我会做的是这样的：
首先尝试在sdk上获取SMART数据，以确定它是否值得信赖或在出路。
如果SDK是好的，那么我会感谢我的幸运之星为前pipe理员浪费了63GB的/dev/sdj 。
fdisk /dev/sdk
（在返回前双击所有东西）。 有fdisk创build一个分区表和一个md分区（mdadm手册页说使用0xDA，但每个演练和我自己的经验说，为RAID自动检测0xFD），然后
mdadm --create /dev/md6 --level=1 --raid-devices=2 missing /dev/sdk1
（在返回前双击所有东西）。 这将使用我们在sdk上创build的分区创build一个名为md6的降级raid1arrays。 接下来的步骤是为什么浪费空间是很重要的：由于md超级块和分区表，我们已经失去了一些空间，所以我们的/ dev / md6比/ dev / sdj稍小。 我们要将/ dev / md6添加到dedvol卷组，并指示LVM将1.82TB的逻辑卷从/ dev / sdj移动到/ dev / md6。 LVM可以处理正在运行的文件系统。
pvcreate /dev/md6 vgextend dedvol /dev/md6 pvmove -v /dev/sdj
（doublecheck …你得到的图片，我也会在pvcreate之后运行pvscan ，在vgextend之后再运行一次，以确保事情看起来是正确的）。 这将开始将分配给/dev/sdj所有数据移动到/dev/md6 （具体地说，该命令将所有的数据移动到sdj，而md6是唯一的地方）。 几个小时后，这将完成或系统将locking试图读取sdj。 如果系统崩溃，可以重新启动并尝试不带设备名称的pvmove ，以在上一个检查点重新启动，或者放弃并从备份中重新安装。
如果我们成功，则从卷组中删除/ dev / sdj，然后将其作为物理卷删除：
vgreduce dedvol /dev/sdj pvremove /dev/sdj
现在，对于腐败检查部分。 检查和修复xfs的工具是xfs_repair （ fsck将在xfs文件系统上运行，但是它什么都不做）。 坏消息？ 它使用每兆字节的文件系统RAM，所以希望你有一个64位的64位内核服务器和64位xfs_repair二进制文件（可能被命名为xfs_repair64）和至less10GB的RAM +交换（你应该能够使用dedvol中剩下的空白空间来创build交换卷，然后mkswap该卷，然后swapon该卷）。 在运行xfs_repair之前， 必须卸载文件系统。 此外，xfs_repair可以检测并（试图）修复对文件系统本身的损害，但是它可能不会检测到对数据的损害（例如，覆盖目录inode的一部分，而不是覆盖在文本文件的中间）。
最后，我们需要购买一个新的/dev/sdj ，安装它，并将其添加到降级的/dev/md6 ，请记住，如果我们在没有sdj的情况下重新启动计算机，sdk可能会下移到sdj而新的驱动器将是sdk，而不是（但可能不是，但最好是肯定的）：
fdisk /dev/sdj
检查以确保它不是我们已经分区和设置的驱动器，然后为它创build一个md分区
mdadm /dev/md6 -a /dev/sdj1
（这些错误完全可能是由于突袭和lvm在sdj的内容上而非驱动器实际上失败（通常是驱动程序在dmesg产生大量乱码而不是驱动程序的input/输出错误），但我不确定我会冒险。）