Kok*_*zzu 2 badblocks fsck nas raid0
我试图将一些文件移动到我的 NAS (ShareCenter DNS-320)，但在使用文件管理器时出现了一些问题：
Input/Output error
或者在挂载的 cifs/smb 共享上使用 rsync 时
rsync: close failed on "/mnt/nas1/_am-unordered/.long-file-name.mkv.PI2rPM": Input/output error (5)
rsync error: error in file IO (code 11) at receiver.c(856) [receiver=3.1.0]
# mount | grep mnt/nas1
//192.168.x.y/backup on /mnt/nas1 type cifs (rw,relatime,vers=1.0,cache=strict,username=admin,domain=BACKUP,uid=1000,forceuid,gid=0,noforcegid,addr=192.168.x.y,file_mode=0755,dir_mode=0755,nounix,serverino,rsize=61440,wsize=65536,actimeo=1)
我假设 NAS 内有坏扇区，我需要运行fsck以检查我的 RAID-0 NAS 内是否有损坏的磁盘。
我已经fun_plug使用本教程进行了安装，现在我可以成功通过 ssh 进入 NAS。通常我会fsck -yvckfC -E fragcheck /dev/sdX用来检查单个卸载磁盘上的坏扇区。
问题是，如何运行坏块并将其插入到已挂载的 RAID0 分区上的坏块列表中？由于 ssh 服务正在 NAS 上的挂载分区上运行：
# umount /mnt/HD/HD_a2/
umount: /mnt/HD/HD_a2: device is busy.
(In some cases useful info about processes that use
the device is found by lsof(8) or fuser(1))
# lsof /mnt/HD/HD_a2/
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
sh 1963 root 1w REG 9,1 5191 12 /mnt/HD/HD_a2/ffp.log
sh 1963 root 2w REG 9,1 5191 12 /mnt/HD/HD_a2/ffp.log
sh 1963 root 10r REG 9,1 1942 246939802 /mnt/HD/HD_a2/fun_plug
rc 1986 root txt REG 9,1 587316 141426950 /mnt/HD/HD_a2/ffp/bin/bash
rc 1986 root mem REG 9,1 28892 139854377 /mnt/HD/HD_a2/ffp/lib/ld-uClibc-0.9.33-git.so
rc 1986 root mem REG 9,1 260898 139853932 /mnt/HD/HD_a2/ffp/lib/libreadline.so.6.2
**snip**
sshd 5519 root mem REG 9,1 60546 139854375 /mnt/HD/HD_a2/ffp/lib/libgcc_s.so.1
sshd 5519 root mem REG 9,1 359940 139854378 /mnt/HD/HD_a2/ffp/lib/libuClibc-0.9.33-git.so
当前 NAS 的 RAID 配置为：
# cat /proc/mdstat
Personalities : [linear] [raid0] [raid1]
md1 : active raid0 sda2[0] sdb2[1]
7808789888 blocks 64k chunks
md0 : active raid1 sdb1[1] sda1[0]
524224 blocks [2/2] [UU]
unused devices: <none>
War*_*ung 11
你在一个不稳定的前提下工作，因为它badblocks可以首先解决你的问题。
badblocks是不可信的修复方法当您使用硬盘驱动器时，它会不断地通过将新扇区替换为可疑扇区来尽最大努力向您隐藏问题。为此，硬盘出厂时带有一个备用扇区池。只要新坏扇区的数量缓慢增长，备用扇区池就会缓慢缩小，以至于硬盘驱动器似乎可以完美运行。
badblocks检测坏扇区的唯一方法是当备用扇区池耗尽时，这意味着它已经降级了一段时间。换句话说，可见的坏扇区意味着硬盘已经解决了很多问题，以至于地毯开始变得粗糙。
据我所知，几十年来，硬盘驱动器已经完成了这种静默修复，可能是从IDE的早期开始。我使用的最后一个系统从一开始就暴露了它们的初始坏扇区集，使用的是 1980 年代后期的ESDI和MFM硬盘。
这并不是说现代硬盘驱动器不再附带一组初始坏扇区。他们是这样。坏道在出厂时就已标出，以便badblocks在新硬盘上进行测试时会发现坏道为零。（来自备用扇区池的扇区被映射以代替坏扇区。）
如果badblocks扫描发现新驱动器上的坏扇区或仍在保修期内的驱动器，这就是立即更换它的充分理由。
有可能在badblocks足够长的时间内返回一致的结果，以使文件系统的坏扇区列表有用。这确实可以让您继续使用保修期外或其他不可替代的硬盘驱动器，直到驱动器自身的自我修复功能停止工作。
但是，也有可能badblocks在间隔很近的测试之间返回不同的结果。（比如说，两次测试相隔一天或一周。）当硬盘进入如此糟糕的状态时，文件系统的坏扇区列表变得毫无意义；硬盘快死了。文件系统的坏扇区列表仅在列表长时间保持稳定时提供好处。
底线：在硬盘仍然可读时更换硬盘。是的，我意识到这可能意味着重建整个 NAS，但这就是 RAID-0 的成本，也就是“可怕的 RAID”。
如果没有通过SMART随时间跟踪备用扇区池的大小，您就无法判断扇区交换已经发生。一些硬盘驱动器不会报告这一点，即使您确实想跟踪它，而那些提供它的硬盘驱动器可能只报告真相的修改版本，而不是字面真相。
也就是说，此命令可能会告诉您需要了解的内容：
# smartctl -x /dev/sda | grep Realloc
5 Reallocated_Sector_Ct PO--CK 200 200 140 - 0
196 Reallocated_Event_Count -O--CK 200 200 000 - 0
虽然smartctl报告的原始值和归一化值可能不完全正确，但这里增加的数字——尤其是在短时间内大幅增加——总是不好的。
请注意，在我运行该命令的机器上，最后一列为零。这就是我所说的报告可能不完全值得信赖的意思。那是“原始”值，而“200”列是“标准化”值。该驱动器声称从来没有重新分配过，这几乎可以肯定不是真的。至于“200”，那是硬盘厂商自己想出来的一个值，有自己的意思。您无法在硬盘驱动器品牌之间进行比较，甚至可能无法将其与同一制造商的其他硬盘驱动器进行比较。
但再一次：如果您监控这些值并且它们突然开始增加，这是一个不好的迹象，即使它实际上并没有告诉您氧化物水平上发生了什么。
smartctl报告有关单个硬盘驱动器的信息，而不是 RAID 设备。它确实知道如何与多种类型的硬件 RAID 控制器通信以提取每个驱动器的信息，但不需要对软件 RAID 提供特定支持，因为底层设备是直接可用的。因此，在您的情况下，您需要同时监控/dev/sda和/dev/sdb单独监控，而不是/dev/md1.
smartd- 一个配套工具smartctl- 进行这种后台持续监控。