Raid

e2fsck 清理文件系統，然後幾分鐘後（經過大量讀取）出現錯誤

  • July 3, 2021

文件系統位於 LVM RAID5 上。它似乎工作正常：

$ sudo pvs
[sudo] password for jrwren: 
 PV         VG     Fmt  Attr PSize    PFree 
 /dev/sda2  datavg lvm2 a--    <7.28t  2.80t
 /dev/sdb2  datavg lvm2 a--    <3.64t     0 
 /dev/sdc2  datavg lvm2 a--    <7.28t <7.28t
 /dev/sdd2  datavg lvm2 a--    <7.28t     0 
 /dev/sde2  datavg lvm2 a--    <7.28t 73.82g
 /dev/sdf1  datavg lvm2 a--    <3.64t     0 
 /dev/sdg2  datavg lvm2 a--    <7.28t  3.99t
 /dev/sdh2  datavg lvm2 a--  <447.11g  8.00m
 /dev/sdi2  datavg lvm2 a--    <9.10t  2.21t
$ sudo lvs
 LV       VG     Attr       LSize   Pool Origin Data%  Meta%  Move Log Cpy%Sync Convert
 lxd2     datavg -wi-ao---- 147.10g                                                    
 mirrored datavg -wi-ao---- 300.00g                                                    
 m        datavg Rwi-aor---   3.52t                                    100.00          
 m3       datavg Rwi-aor---   4.00t                                    100.00          
 mu       datavg Rwi-aor---   1.00t                                    100.00          
 nomirror datavg -wi-ao----   2.20t                                                    
 photos   datavg Rwi-aor--- 200.00g                                    100.00          
 stor     datavg Rwi-aor--- 300.00g                                    100.00          
 storj    datavg -wi-ao----   1.00t                                                    
 t        datavg Rwi-aor---   6.00t                                    100.00          
 t2       datavg Rwi-aor---   3.90t                                    100.00

我有一個程序對名為 m 的邏輯捲進行多次讀取。這是設備 dm-12。最終，它會隨著以下核心消息而死。

Jun 30 16:02:33 delays kernel: [393661.035286] EXT4-fs error (device dm-12): ext4_find_extent:885: inode #191365192: com[68/1946]t main: pblk 765519712 bad header/extent: invalid magic - magic 0, entries 0, max 0(0), depth 0(0)                               
Jun 30 16:02:33 delays kernel: [393661.039726] EXT4-fs error (device dm-12): ext4_find_extent:885: inode #191365192: comm rtorrent main: pblk 765519712 bad header/extent: invalid magic - magic 0, entries 0, max 0(0), depth 0(0)                               
Jun 30 16:02:33 delays kernel: [393661.044175] EXT4-fs error (device dm-12): ext4_find_extent:885: inode #191365192: comm rtorrent main: pblk 765519712 bad header/extent: invalid magic - magic 0, entries 0, max 0(0), depth 0(0)                               
Jun 30 16:02:33 delays kernel: [393661.048584] EXT4-fs error (device dm-12): ext4_find_extent:885: inode #191365192: comm rtorrent main: pblk 765519712 bad header/extent: invalid magic - magic 0, entries 0, max 0(0), depth 0(0) 
Jun 30 16:02:33 delays kernel: [393661.054717] EXT4-fs error (device dm-12): ext4_find_extent:885: inode #191365192: comm rtorrent main: pblk 765519712 bad header/extent: invalid magic - magic 0, entries 0, max 0(0), depth 0(0) 
Jun 30 16:02:33 delays kernel: [393661.060977] EXT4-fs error (device dm-12): ext4_find_extent:885: inode #191365192: comm rtorrent main: pblk 765519712 bad header/extent: invalid magic - magic 0, entries 0, max 0(0), depth 0(0) 
Jun 30 16:02:33 delays kernel: [393661.063736] EXT4-fs error (device dm-12): ext4_find_extent:885: inode #191365192: comm rtorrent main: pblk 765519712 bad header/extent: invalid magic - magic 0, entries 0, max 0(0), depth 0(0) 
Jun 30 16:02:33 delays kernel: [393661.066283] EXT4-fs error (device dm-12): ext4_find_extent:885: inode #191365192: comm rtorrent main: pblk 765519712 bad header/extent: invalid magic - magic 0, entries 0, max 0(0), depth 0(0) 
Jun 30 16:02:33 delays kernel: [393661.068773] EXT4-fs error (device dm-12): ext4_find_extent:885: inode #191365192: comm rtorrent main: pblk 765519712 bad header/extent: invalid magic - magic 0, entries 0, max 0(0), depth 0(0) 
Jun 30 16:02:33 delays kernel: [393661.071232] EXT4-fs error (device dm-12): ext4_find_extent:885: inode #191365192: comm rtorrent main: pblk 765519712 bad header/extent: invalid magic - magic 0, entries 0, max 0(0), depth 0(0)

我解除安裝文件系統並執行 e2fsck：

$ sudo e2fsck -p /dev/datavg/m
movies contains a file system with errors, check forced.
movies: Inode 118751237 has an invalid extent node (blk 475078659, lblk 0)


movies: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY.
       (i.e., without -a or -p options)
$ sudo e2fsck -y /dev/datavg/movies
e2fsck 1.45.7 (28-Jan-2021)
movies contains a file system with errors, check forced.
Pass 1: Checking inodes, blocks, and sizes
Inode 177471496 has an invalid extent node (blk 709943175, lblk 0)
Clear? yes
...

Pass 1E: Optimizing extent trees
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
Block bitmap differences:  -(709943175--709943176) -(868210688--868212735) -(868214784--868216831) -(868253696--868255743) -(868257792--868259839) -(868886528--868888575) -(868892672--868894719) -(868896768--868898815) -(868900864--868902911) -(868904960--868907007) -(868909056--868911103) -(868913152--868917247) -(868921344--868923391) -(868925440--868927487) -(868929536--868931583) -(868933632--868935679) -(868937728--868939775) -(868941824--868943871) -(868945920--868947967) -(868950016--868954111) -(868958208--868960013) -(869894144--869922573)
Fix? yes

Free blocks count wrong for group #21665 (24561, counted=24563).
Fix? yes

Free blocks count wrong for group #26495 (28672, counted=32768).
Fix? yes

Free blocks count wrong for group #26497 (18432, counted=22528).
Fix? yes

Free blocks count wrong for group #26516 (22528, counted=32768).
Fix? yes

Free blocks count wrong for group #26517 (16384, counted=32768).
Fix? yes

Free blocks count wrong for group #26518 (16626, counted=26624).
Fix? yes

Free blocks count wrong for group #26547 (2290, counted=30720).
Fix? yes

Free blocks count wrong (366951912, counted=367025158).
Fix? yes



movies: ***** FILE SYSTEM WAS MODIFIED *****
movies: 6896/236224512 files (20.8% non-contiguous), 577868794/944893952 blocks
$ sudo e2fsck -p /dev/datavg/movies
movies: clean, 6896/236224512 files, 577868794/944893952 blocks

它說它很乾淨，所以我重新安裝它並重新執行閱讀軟體。

幾分鐘後：

Jun 30 16:34:49 delays kernel: [395595.309814] EXT4-fs error (device dm-12): ext4_find_extent:885: inode #191365190: comm rtorrent main: pblk 765517692 bad header/extent: invalid magic - magic 0, entries 0, max 0(0), depth 0(0) 
Jun 30 16:34:49 delays kernel: [395595.317838] EXT4-fs error (device dm-12): ext4_find_extent:885: inode #191365190: comm rtorrent main: pblk 765517692 bad header/extent: invalid magic - magic 0, entries 0, max 0(0), depth 0(0) 
Jun 30 16:34:49 delays kernel: [395595.320836] EXT4-fs error (device dm-12): ext4_find_extent:885: inode #191365190: comm rtorrent main: pblk 765517692 bad header/extent: invalid magic - magic 0, entries 0, max 0(0), depth 0(0) 
Jun 30 16:34:49 delays kernel: [395595.323418] EXT4-fs error (device dm-12): ext4_find_extent:885: inode #191365190: comm rtorrent main: pblk 765517692 bad header/extent: invalid magic - magic 0, entries 0, max 0(0), depth 0(0) 
Jun 30 16:35:14 delays kernel: [395619.785771] EXT4-fs error (device dm-12): ext4_find_extent:885: inode #191365190: comm rtorrent main: pblk 765517692 bad header/extent: invalid magic - magic 0, entries 0, max 0(0), depth 0(0) 
Jun 30 16:35:14 delays kernel: [395619.793135] EXT4-fs error (device dm-12): ext4_find_extent:885: inode #191365190: comm rtorrent main: pblk 765517692 bad header/extent: invalid magic - magic 0, entries 0, max 0(0), depth 0(0)

這裡發生了什麼？LVM 是否腐敗並在欺騙我？有沒有我可以執行檢查的命令？我應該執行一個壞塊（e2fsck -c）還是什麼？

核心沒有相應的 LVM 消息。如果底層磁碟有問題，我預計會出現 LVM 錯誤。到底是怎麼回事？

更新：有人要求 dmesg 輸出。這正是上面 EXT4-fs 消息的內容。dmesg 輸出中除了標準引導消息之外的唯一其他消息是重複的：

[527724.593062] rptaddrs[3948921]: segfault at 7ffc7a7a50b5 ip 00007fd9f0f86820 sp 00007ffc7a7a3fc8 error 4 in libc-2.28.so[7fd9f0e4c000+148000]                                                                                                                  [527724.593075] Code: 7f 07 c5 fe 7f 4f 20 c5 fe 7f 54 17 e0 c5 fe 7f 5c 17 c0 c5 f8 77 c3 48 39 f7 0f 87 ab 00 00 00 0f 84 e5 fe ff ff c5 fe 6f 26 <c5> fe 6f 6c 16 e0 c5 fe 6f 74 16 c0 c5 fe 6f 7c 16 a0 c5 7e 6f 44

我遇到過兩次這種情況，原因是硬體故障。可能的根本原因：

  • 連接不良的電纜
  • 壞磁碟電纜（發生在我身上一次）
  • 有問題的 SATA 介面（我有一個介面將零字節塊寫入我的磁碟設備，只有一次，但後來我丟棄了卡）
  • 壞 RAM（損壞緩衝數據）
  • 超頻引起的過熱或錯誤
  • 可能不太可能，其他硬體故障

這兩次發生在我身上，我都經歷了數據失去。這些天來，這種可能性要小得多，因為我使用 ZFS 和複製快照，並且還有離線磁帶備份。

您可以 fsck 然後找到它之後立即再次失敗的事實使我確信這是一個硬體問題。我預測，在“修復”問題時，fsck 寫入磁碟的塊可能不會（總是）完好無損地寫入磁碟表面。

首先，確保您現有的電纜正確就位並重新測試。如果這不能解決問題，請繼續閱讀：

您也許可以證明這是測試磁碟的問題：

  1. 獲取實時可啟動系統映像，例如在 USB 驅動器上。不要在有故障的機器上準備它，因為它可能會損壞。使用其他機器，或購買現成的 live-Linux 系統 U 盤。

  2. 關閉系統電源。

  3. 標記每個硬碟與 SATA 介面的連接方式（例如，哪個埠等）

  4. 斷開驅動器並正確存放它們（即在堅固的防靜電容器中）。在您隔離並解決問題之前，不要將它們重新插入系統，因為您解決問題的努力fsck只會讓問題變得更糟。

  5. 插入一個完全不包含任何有價值數據的犧牲磁碟**，您可以安全地覆蓋它**

  6. 仔細檢查您的犧牲磁碟和實時可啟動映像（請參閱下一項）是連接到機器的**唯一儲存設備。**您需要避免意外地將帶有您寶貴數據的磁碟分區，或者badblocks在這樣的磁碟上執行。

  7. 從實時系統映像引導（例如可引導的 USB 實時系統）

  8. 將驅動器劃分為少量分區，第一個分區為幾十 GB

  9. 在一個小分區上執行badblocks -w -B（-B確保我們也使用 RAM）（選擇一個小分區以便測試不需要幾天時間）

  10. 如果這失敗了，你有一個硬體問題；嘗試更換組件以查看問題是否消失

  11. 例如，取出除一個以外的所有 RAM 模組，旋轉它們以辨識哪個是壞的

  12. 例如，更改您連接的 SATA 埠，以辨識損壞的 SATA 介面或適配器

  13. 例如，保留相同的 SATA 埠但更換電纜，以辨識損壞的電纜

  14. 其他系統組件中的缺陷（甚至是主機板故障或電源不足的 PSU）可能會導致問題

  15. 如果您懷疑 RAM 損壞，您可以使用memtest86它來測試它。您也可以-B從 badblocks 中省略標誌以使用直接 I/O，這將減少但不會消除 RAM 的使用。

確定故障硬體後，更換它。理想情況下，將您最近的備份恢復到新磁碟上（請注意，如果您沒有真正隔離並修復問題，新磁碟上的數據也會損壞）。

編輯：歡迎您投反對票，但如果您決定這樣做，如果您發表評論指出為什麼這個答案沒有用，我將不勝感激。

引用自：https://serverfault.com/questions/1068296

相關問答

Raid

與故障轉移相比，為什麼主動-主動配置會降低性能？

  • September 24, 2021
檢視問答
Performance

ext4 RAID5 調整選項在 LVM 下有用嗎？

  • August 19, 2020
檢視問答
Raid

在 2 個 ADAPT（類似 RAID6）卷上確認 XFS 文件系統和 LVM 卷條帶化的參數

  • July 16, 2020
檢視問答
Raid

是否可以在現有的和使用的 ext4 fs 上更新條頻寬度？

  • September 8, 2016
檢視問答
Raid

跨越多個 2TB RAID 虛擬磁碟的 LVM 分區時是否存在性能或可靠性問題？

  • February 17, 2014
檢視問答
Raid

如何從多個驅動器創建一個大卷，但如果失敗僅釋放儲存在一個磁碟上的文件？

  • July 13, 2012
檢視問答