在掛載的分區上添加壞塊
我嘗試將一些文件移動到我的 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>
你是在一個不穩定的前提下工作的，因為它
badblocks可以首先解決你的問題。為什麼
badblocks是不可靠的修復方法當您使用硬碟驅動器時，它會不斷地通過將新扇區換成不可靠的扇區來盡力向您隱藏問題。為此目的，硬碟出廠時帶有一個備用扇區池。只要新壞扇區的數量緩慢增長，備用扇區池就會緩慢收縮，以至於硬碟驅動器似乎可以完美執行。
檢測壞扇區的唯一方法
badblocks是在備用扇區池耗盡時，這意味著它已經退化了一段時間。換句話說，可見的壞扇區意味著硬碟已經掩蓋了許多問題，以至於地毯開始看起來很凹凸不平。據我所知，硬碟驅動器幾十年來一直在進行這種無聲修復，可能是從IDE的早期開始。我使用的最後一個系統從一開始就暴露了最初的一組壞扇區，使用的是ESDI和MFM硬碟，可以追溯到 1980 年代後期。
這並不是說現代硬碟驅動器不再附帶一組初始壞扇區。他們是這樣。壞扇區在工廠被映射出來，因此
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- 進行這種後台持續監控。