Linux
乾淨的 ext3 分區的輸入/輸出錯誤 - 如何檢查數據塊有什麼問題
我在使用 HP Raid 控制器的 CentOS 5 伺服器（核心版本 2.6.18-164.15.1.el5）的 ext3 分區中遇到文件問題：
hpacucli ctrl all show detail Smart Array P410 in Slot 1 Bus Interface: PCI ...HP 工具不報告任何問題。
這是正常的分區 ext3，塊大小設置為 2k，很好 - fsck 輸出：
fsck 1.39 (29-May-2006) Pass 1: Checking inodes, blocks, and sizes Pass 2: Checking directory structure Pass 3: Checking directory connectivity Pass 4: Checking reference counts Pass 5: Checking group summary information文件 inode 也可以：
File: `name.xxx' Size: 3126962 Blocks: 6124 IO Block: 4096 regular file Device: 6851h/26705d Inode: 64579729 Links: 1 Access: (0644/-rw-r--r--) Uid: ( 0/ root) Gid: ( 0/ root) Access: 2014-07-28 09:02:59.000000000 -0400 Modify: 2014-07-28 09:02:59.000000000 -0400 Change: 2014-07-28 09:02:59.000000000 -0400我無法執行的操作之一是文件複製：
> cp /long_path/name.xxx . cp: reading `/long_path.name.xxx': Input/output error為了查明問題出在哪裡，我執行 dd 來複製文件：
> dd if=/long_path/name.xxx bs=2048 of=test dd: reading `/long_path/name.xxx': Input/output error 222+0 records in 222+0 records out 454656 bytes (455 kB) copied, 0.042867 seconds, 10.6 MB/s所以我猜這個問題出在 223 文件塊中。
Debugfs 應該有助於在磁碟上定位該塊
debugfs -R "stat name.xxx" /dev/sdf debugfs 1.39 (29-May-2006) Inode: 64579729 Type: regular Mode: 0644 Flags: 0x0 Generation: 2900468317 User: 0 Group: 0 Size: 3126962 File ACL: 0 Directory ACL: 0 Links: 1 Blockcount: 6124 Fragment: Address: 0 Number: 0 Size: 0 ctime: 0x53d64a03 -- Mon Jul 28 09:02:59 2014 atime: 0x53d64a03 -- Mon Jul 28 09:02:59 2014 mtime: 0x53d64a03 -- Mon Jul 28 09:02:59 2014 BLOCKS: (0):130402311, (1-4):130402844-130402847, (5-6):130484033-130484034, (7):130484036, (8-10):130484049-130484051, (11):130484055, (IND):130761221, (12-13):130761222-130761223, (14):130763791, (15):130763942, (16):130765268, (17-23):130838937-130838943, (24-46):130853946-130853968, (47-48):130855126-130855127, (49):130855215, (50-53):130856428-130856431, (54-104):130856533-130856583, (105-341):130856748-130856984, ... [MORE BLOCKS] .... TOTAL: 1531所以我猜有問題的數據在塊 130856866 中。
如何獲得有關該區塊的更多資訊？我執行了壞塊，並有一個壞塊列表。我的猜測是我必須將上面的塊數乘以 2（文件系統塊大小為 2K，預設情況下壞塊使用 1K）。badblocks 也檢查磁碟，而不是分區，所以也許我應該添加一些偏移量（該磁碟上有一個分區，所以可能沒有）。
> fdisk -l /dev/sdf Disk /dev/sdf: 2000.3 GB, 2000365379584 bytes 255 heads, 63 sectors/track, 243197 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Device Boot Start End Blocks Id System /dev/cciss/c0d5p1 * 1 243197 1953479871 83 Linux我也想過使用smartd。我應該尋找什麼？
Error counter log: Errors Corrected by Total Correction Gigabytes Total ECC rereads/ errors algorithm processed uncorrected fast | delayed rewrites corrected invocations [10^9 bytes] errors read: 0 1457 0 2887405961 0 65948.712 18 write: 0 0 0 0 0 15056.493 0 verify: 0 1 0 361901613 0 3591.720 0 Non-medium error count: 226 SMART Self-test log Num Test Status segment LifeTime LBA_first_err [SK ASC ASQ] Description number (hours) # 1 Background long Failed in segment --> - 34479 16845361 [0x3 0x11 0x0] # 2 Background short Completed - 44 - [- - -] # 3 Background short Completed - 39 - [- - -] # 4 Background long Completed - 6 - [- - -] Long (extended) Self Test duration: 18500 seconds [308.3 minutes] Background scan results log Status: scan is active Accumulated power on time, hours:minutes 34541:56 [2072516 minutes] Number of background scans performed: 1139, scan progress: 38.18% Number of background medium scans performed: 1139 # when lba(hex) [sk,asc,ascq] reassign_status 1 19215:06 0000000000014c61 [3,11,0] Recovered via rewrite in-place 2 19215:07 0000000000014c66 [3,11,0] Recovered via rewrite in-place 3 19413:28 0000000001010a31 [3,11,0] Require Write or Reassign Blocks command 4 19943:24 000000000001ea99 [3,11,0] Recovered via rewrite in-place 5 20152:23 00000000000232b8 [3,11,0] Recovered via rewrite in-place 6 31229:34 810000004087f984 [3,11,0] Require Write or Reassign Blocks command 7 33021:51 810000004087ba85 [3,11,0] Require Write or Reassign Blocks command 8 33021:51 000000004087ba9f [3,11,0] Require Write or Reassign Blocks command 9 33021:52 000000004087bad6 [3,11,0] Require Write or Reassign Blocks command 10 33029:43 000000004087baa5 [3,11,0] Require Write or Reassign Blocks command 11 33055:27 000000004087bac3 [3,11,0] Require Write or Reassign Blocks command 12 33244:40 810000004087f9d6 [3,11,0] Require Write or Reassign Blocks command 13 33431:58 990000004087f105 [0,0,0] Reassignment by disk failed 14 33480:17 00000000463d7713 [3,11,0] Require Write or Reassign Blocks command 15 33480:19 00000000463d7723 [3,11,0] Require Write or Reassign Blocks command 16 33480:20 00000000463d7725 [3,11,0] Require Write or Reassign Blocks command 17 33480:28 81000000463d774e [3,11,0] Require Write or Reassign Blocks command 18 33686:17 8100000044e50edc [3,11,0] Require Write or Reassign Blocks command 19 34154:17 81000000432bef27 [3,11,0] Require Write or Reassign Blocks command 20 34463:43 810000001f32decd [3,11,0] Require Write or Reassign Blocks command 21 34463:43 0000000030080000 [3,11,0] Require Write or Reassign Blocks command我應該如何將 smartctl 輸出（或 smartd 執行的任何其他輸出）與我最初的問題結合起來。
HDD軟體也不應該解決這樣的問題嗎？
順便提一句。我發現以下連結有助於理解“調試 -R”輸出。也許該連結對其他人有用。
更新
做進一步的研究，我發現與有問題的 inode 相關的操作（如上面的 cp 命令）會在核心日誌中觸發以下行：
kernel: cciss: cmd ffff810037e00000 has CHECK CONDITION sense key = 0x3
所以，為了弄清楚這一點，我做了以下事情。
取你的區塊號，乘以四並加一
(130856866 * 4) + 1 = 523427465這表示報告為產生 I/O 錯誤的扇區。塊大小為 2k，扇區為 512 字節。額外的一個額外說明了分區的起始扇區偏移量。
為了與 SMART 關聯，我們需要將我們現在擁有的值轉換為十六進制。
$ printf "0x%x\n" 523427465 0x1f32de89現在，當您將其與 SMART 顯示的內容相關聯時，一條線出現了可疑的接近…
20 34463:43 810000001f32decd [3,11,0] Require Write or Reassign Blocks command有多遠？
$ bc -l bc 1.06.95 Copyright 1991-1994, 1997, 1998, 2000, 2004, 2006 Free Software Foundation, Inc. This is free software with ABSOLUTELY NO WARRANTY. For details type `warranty'. obase=16 ibase=16 1F32DECD-1F32DE89 44計算結果僅在 34816 和 32768 字節之間，但我們不能說在組成該塊的四個扇區中哪個扇區被損壞。
如果我不得不冒險猜測，我會說在同一個地址周圍可能有一大堆塊會報告 I/O 錯誤（假設 raid 條帶化大小為 32k 或其他）。
此外，如果 RAID 從不同磁碟獲取塊塊，則讀取可能無法解決問題。無論如何，寫入必須傳播到 RAID1 設置中的所有磁碟，因此這可能會導致寫入失敗但讀取成功。此外，如果我們假設 RAID 卡的塊大小為 32k，我們還可以假設損壞的塊加上 SMART 報告的塊都被該盤上發生的任何事情損壞了。它只是從前 32k 的好磁碟和下一個 32k 的壞磁碟讀取的 SMART 測試。
現代硬碟保留“保留扇區”以用新的扇區位置替換此類損壞的扇區。看到你現在得到這個，以及
Reassign by disk failed來自 smart 的消息，我會說磁碟已經用完了。在做某事方面；這有點棘手。LBA 定址是對底層真實磁碟的抽象。您需要確定導致此問題的磁碟是哪個磁碟，在 RAID 陣列中使其失效並更換它。
無論如何，你的磁碟壞了，你應該盡快更換它。