主页 / server / 问题 / 1068296
Accepted
jrwren
Asked: 2021-07-01 12:40:37 +0800 CST

e2fsck 清理文件系统，然后几分钟后（经过大量读取）出现错误

  • 772

文件系统位于 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
lvm filesystems raid raid5 ext4

1 个回答

  1. Best Answer

    我遇到过两次这种情况，原因是硬件故障。可能的根本原因：

    • 连接不良的电缆
    • 坏磁盘电缆（发生在我身上一次）
    • 有问题的 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. 如果这失败了，你有一个硬件问题；尝试更换组件以查看问题是否消失
      1. 例如，取出除一个以外的所有 RAM 模块，旋转它们以识别哪个是坏的
      2. 例如，更改您连接的 SATA 端口，以识别损坏的 SATA 接口或适配器
      3. 例如，保留相同的 SATA 端口但更换电缆，以识别损坏的电缆
    11. 其他系统组件中的缺陷（甚至是主板故障或电源不足的 PSU）可能会导致问题
    12. 如果您怀疑 RAM 损坏，您可以使用memtest86它来测试它。您也可以-B从 badblocks 中省略标志以使用直接 I/O，这将减少但不会消除 RAM 的使用。

    确定故障硬件后，更换它。理想情况下，将您最近的备份恢复到新磁盘上（请注意，如果您没有真正隔离并修复问题，新磁盘上的数据也会损坏）。

    编辑：欢迎您投反对票，但如果您决定这样做，如果您发表评论指出为什么这个答案没有用，我将不胜感激。

    • 3

相关问题