我尝试将一些文件移动到我的 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
检查单个未安装磁盘上的坏扇区。
问题是,如何运行badblocks并将其插入到挂载的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>
答案1
你在一个不稳定的前提下工作,因为这badblocks
可以首先解决你的问题。
为什么badblocks
修复方法不可信
当您使用硬盘驱动器时,它会不断地通过将新扇区替换为不可靠的扇区来尽力向您隐藏问题。硬盘在出厂时带有一个用于此目的的备用扇区池。只要新坏扇区的数量增长缓慢,备用扇区池就会缓慢收缩,从而使硬盘驱动器出现完美运行。
检测坏扇区的唯一方法badblocks
是当备用扇区池耗尽时,这意味着它已经退化了一段时间。换句话说,可见的坏扇区意味着硬盘已经将太多问题掩盖起来,以至于地毯开始看起来凹凸不平。
据我所知,硬盘驱动器已经进行这种无声修复数十年了,可能是从早期开始集成开发环境。我使用的最后一个系统从一开始就暴露了它们最初的坏扇区集静电放电指数和磁力显微镜硬盘,可以追溯到 20 世纪 80 年代末。
这并不是说现代硬盘驱动器不再附带一组初始坏扇区。他们是这样。坏扇区在工厂已被映射出来,以便badblocks
在新硬盘上进行测试时会出现零坏扇区。 (备用扇区池中的扇区被映射以取代坏扇区。)
如果badblocks
扫描发现新驱动器或仍在保修期内的驱动器上有坏扇区,则有足够的理由立即更换它。
有可能badblocks
在足够长的时间内返回一致的结果,以使文件系统的坏扇区列表发挥作用。这确实可以让您在驱动器自身的自我修复功能停止工作之后继续使用超出保修期或其他不可替代的硬盘驱动器。
然而,在紧密间隔的测试之间也可能badblocks
返回不同的结果。 (例如,相隔一天或一周进行两次测试。)当硬盘进入如此糟糕的状态时,文件系统的坏扇区列表就变得毫无意义;硬盘快要死了。文件系统的坏扇区列表仅在列表长时间保持稳定时才提供好处。
底线:在硬盘仍可读时更换硬盘。是的,我意识到这可能意味着重建整个 NAS,但这就是 RAID-0 的成本,又名“可怕的RAID”。
更好的解决方案:监控
如果无法通过一段时间跟踪备用扇区池的大小,则无法判断扇区交换已发生聪明的。即使您确实想跟踪它,某些硬盘驱动器也不会报告此情况,而提供此信息的硬盘驱动器可能仅报告真相的修改版而不是字面上的真相。
也就是说,这个命令可能会告诉您需要了解的信息:
# 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
- 进行这种后台连续监控。