centos意外断电的情况下linux挂载磁盘报错（已解决）

问题描述

centos意外断电的情况下linux挂载磁盘报错，这大致是意外断电硬盘相关meta信息还未落盘之类的导致磁盘信息对不上

通过命令 kubectl describe pod minio-5b9765594b-g4bwt得到错误信息

Warning FailedMount 47m (x5 over 47m) kubelet MountVolume.MountDevice failed for volume "pvc-b42e9345-a3df-49b0-a38a-041e6e691599" : kubernetes.io/csi: attacher.MountDevice failed to create newCsiDriverClient: driver name cstor.csi.openebs.io not found in the list of registered CSI drivers
Warning FailedMount 47m kubelet MountVolume.MountDevice failed for volume "pvc-b42e9345-a3df-49b0-a38a-041e6e691599" : rpc error: code = Internal desc = Volume pvc-b42e9345-a3df-49b0-a38a-041e6e691599 Busy, status: RemountUnderProgress
Warning FailedMount 46m kubelet MountVolume.MountDevice failed for volume "pvc-b42e9345-a3df-49b0-a38a-041e6e691599" : rpc error: code = Internal desc = 'fsck' found errors on device /dev/disk/by-path/ip-10.0.0.158:3260-iscsi-iqn.2016-09.com.openebs.cstor
but could not correct them: fsck from util-linux 2.31.1
ext2fs_check_if_mount: Can't check if filesystem is mounted due to missing mtab file while determining whether /dev/sdc is mounted.
/dev/sdc: recovering journal
/dev/sdc contains a file system with errors, check forced.
/dev/sdc: Entry '0122fad8-c8ed-4c9a-a6bd-3559620515ae' in ??? (11796929) has deleted/unused inode 113509727. CLEARED.
/dev/sdc: Entry 'xl.meta' in ??? (11796929) has deleted/unused inode 113509724. CLEARED.
/dev/sdc: Directory inode 11796958, block #0, offset 0: directory has no checksum.
FIXED.
/dev/sdc: Directory inode 11796958, block #0, offset 0: directory corrupted

/dev/sdc: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY.
(i.e., without -a or -p options)
Warning FailedMount 37m (x4 over 45m) kubelet Unable to attach or mount volumes: unmounted volumes=[data], unattached volumes=[empty-dir data timezone]: timed out waiting for the condition
Warning FailedMount 36m (x6 over 45m) kubelet MountVolume.MountDevice failed for volume "pvc-b42e9345-a3df-49b0-a38a-041e6e691599" : rpc error: code = Internal desc = 'fsck' found errors on device /dev/disk/by-path/ip-10.0.0.158:3260-iscsi-iqn.2016-09.com.openebs.cstor
but could not correct them: fsck from util-linux 2.31.1
ext2fs_check_if_mount: Can't check if filesystem is mounted due to missing mtab file while determining whether /dev/sdc is mounted.
/dev/sdc contains a file system with errors, check forced.
/dev/sdc: Directory inode 11796958, block #0, offset 0: directory has no checksum.
FIXED.
/dev/sdc: Directory inode 11796958, block #0, offset 0: directory corrupted

/dev/sdc: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY.
(i.e., without -a or -p options)
Warning FailedMount 35m (x2 over 39m) kubelet Unable to attach or mount volumes: unmounted volumes=[data], unattached volumes=[data timezone empty-dir]: timed out waiting for the condition
Warning FailedMount 31m (x2 over 31m) kubelet MountVolume.MountDevice failed for volume "pvc-b42e9345-a3df-49b0-a38a-041e6e691599" : kubernetes.io/csi: attacher.MountDevice failed to create newCsiDriverClient: driver name cstor.csi.openebs.io not found in the list of registered CSI drivers
Warning FailedMount 12m (x2 over 17m) kubelet Unable to attach or mount volumes: unmounted volumes=[data], unattached volumes=[data timezone empty-dir]: timed out waiting for the condition
Warning FailedMount 10m (x2 over 27m) kubelet Unable to attach or mount volumes: unmounted volumes=[data], unattached volumes=[timezone empty-dir data]: timed out waiting for the condition
Warning FailedMount 8m47s (x7 over 29m) kubelet Unable to attach or mount volumes: unmounted volumes=[data], unattached volumes=[empty-dir data timezone]: timed out waiting for the condition
Warning FailedMount 38s (x20 over 30m) kubelet MountVolume.MountDevice failed for volume "pvc-b42e9345-a3df-49b0-a38a-041e6e691599" : rpc error: code = Internal desc = 'fsck' found errors on device /dev/disk/by-path/ip-10.0.0.158:3260-iscsi-iqn.2016-09.com.openebs.cstor
but could not correct them: fsck from util-linux 2.31.1
ext2fs_check_if_mount: Can't check if filesystem is mounted due to missing mtab file while determining whether /dev/sdc is mounted.
/dev/sdc contains a file system with errors, check forced.
/dev/sdc: Directory inode 11796958, block #0, offset 0: directory has no checksum.
FIXED.
/dev/sdc: Directory inode 11796958, block #0, offset 0: directory corrupted

/dev/sdc: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY.
(i.e., without -a or -p options)

从上面的信息显示/dev/sdc出现了ext2fs_check_if_mount: Can't check if filesystem is mounted due to missing mtab file while determining whether /dev/sdc is mounted.

那么这里需要手动检查修复/dev/sdc的文件信息了

开始解决问题

检查设备

找到出问题的设备：

[root@k8s-master01 ~]# lsblk
NAME                          MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
sda                             8:0    0 465.8G  0 disk 
├─sda1                          8:1    0   200M  0 part /boot/efi
├─sda2                          8:2    0   500M  0 part /boot
└─sda3                          8:3    0 465.1G  0 part 
  ├─centos-root               253:0    0   100G  0 lvm  /
  ├─centos-swap               253:1    0    32G  0 lvm  
  ├─centos-var_lib_containerd 253:2    0   150G  0 lvm  /var/lib/containerd
  └─centos-home               253:3    0 183.1G  0 lvm  /home
sdb                             8:16   0   3.7T  0 disk 
├─sdb1                          8:17   0   3.7T  0 part 
└─sdb9                          8:25   0     8M  0 part 
sdc                             8:32   0     3T  0 disk /var/lib/kubelet/pods/0d56e107-427f-49e4-b120-ea150aab1914/volumes/kubernetes.io~csi/pvc-b42e9345-a3df-49b0-a38a-041e6e691599/mount

卸载设备（如果已挂载）：

我的设备时通过openebs管理的，没执行这部

sudo umount /dev/sdc

e2fsck工具

注意这里e2fsck的版本不能低于1.43.x

不然会报错不支持check

e2fsck 1.42.9 (28-Dec-2013)
/dev/sdc has unsupported feature(s): metadata_csum

如果版本太低就重新下载一个支持的版本，这里我选择的时安装到/usr/local/e2fsck，没有取修改系统自带的工具

# 下载 e2fsprogs 源代码
wget https://www.kernel.org/pub/linux/kernel/people/tytso/e2fsprogs/v1.43.9/e2fsprogs-1.43.9.tar.gz
tar -xzf e2fsprogs-1.43.9.tar.gz
cd e2fsprogs-1.43.9

# 创建构建目录并配置
mkdir build
cd build
../configure --prefix=/usr/local/e2fsck

# 编译和安装
make
sudo make install

记得配置环境配置：

export PATH=/usr/local/e2fsck/sbin:$PATH

前提条件已经准备好了，现在可以开始了

网上有的用的这种方式(注意：不过我是没有成功过)

[root@k8s-master01 ~]# sudo fsck /dev/sdc
fsck，来自 util-linux 2.23.2
e2fsck 1.42.9 (28-Dec-2013)
/dev/sdc has unsupported feature(s): metadata_csum
e2fsck: Get a newer version of e2fsck!

我的最终解决：全程y就行了

[root@k8s-master01 ~]# e2fsck /dev/sdc     
e2fsck 1.43.9 (8-Feb-2018)
/dev/sdc 有一个含有错误的文件系统，强制进行检查。
第 1 步：检查inode、块和大小
第 2 步：检查目录结构
目录inode 11796958，块 #0，偏移量 0：目录缺少校验值。
处理<y>? 是
目录inode 11796958，块 #0，偏移量 0：目录已损坏
修复<y>? 是
目录inode 11796958 中缺少“.”。
处理<y>? 是
将???（11796958）中的项 “.”的文件类型设置为 2。
目录inode 11796958 中缺少“..”。
处理<y>? 是
将???（11796958）中的项 “..”的文件类型设置为 2。
目录inode 11927554，块 #0，偏移量 0：目录缺少校验值。
处理<y>? 是
目录inode 11927554，块 #0，偏移量 0：目录已损坏
修复<y>? 是
目录inode 11927554 中缺少“.”。
处理<y>? 是
将???（11927554）中的项 “.”的文件类型设置为 2。
目录inode 11927554 中缺少“..”。
处理<y>? 是
将???（11927554）中的项 “..”的文件类型设置为 2。
目录inode 11927555，块 #0，偏移量 0：目录缺少校验值。
处理<y>? 是
目录inode 11927555，块 #0，偏移量 0：目录已损坏
修复（“a” 表示全部回答“yes”） <y>? 是
目录inode 11927555 中缺少“.”。
处理（“a” 表示全部回答“yes”） <y>? 是
将???（11927555）中的项 “.”的文件类型设置为 2。
目录inode 11927555 中缺少“..”。
处理（“a” 表示全部回答“yes”） <y>? 是
将???（11927555）中的项 “..”的文件类型设置为 2。
目录inode 11927556，块 #0，偏移量 0：目录缺少校验值。
处理（“a” 表示全部回答“yes”） <y>? 是
目录inode 11927556，块 #0，偏移量 0：目录已损坏
修复<y>? 是
目录inode 11927556 中缺少“.”。
处理<y>? 是
将???（11927556）中的项 “.”的文件类型设置为 2。
目录inode 11927556 中缺少“..”。
处理<y>? 是
将???（11927556）中的项 “..”的文件类型设置为 2。
目录inode 11927557，块 #0，偏移量 0：目录缺少校验值。
处理<y>? 是
目录inode 11927557，块 #0，偏移量 0：目录已损坏
修复<y>? 是
目录inode 11927557 中缺少“.”。
处理<y>? 是
将???（11927557）中的项 “.”的文件类型设置为 2。
目录inode 11927557 中缺少“..”。
处理<y>? 是
将???（11927557）中的项 “..”的文件类型设置为 2。
目录inode 11927558，块 #0，偏移量 0：目录缺少校验值。
处理<y>? 是
目录inode 11927558，块 #0，偏移量 0：目录已损坏
修复<y>? 是
目录inode 11927558 中缺少“.”。
处理<y>? 是
将???（11927558）中的项 “.”的文件类型设置为 2。
目录inode 11927558 中缺少“..”。
处理<y>? 是
将???（11927558）中的项 “..”的文件类型设置为 2。
目录inode 11927559，块 #0，偏移量 0：目录缺少校验值。
处理<y>? 是
目录inode 11927559，块 #0，偏移量 0：目录已损坏
修复<y>? 是
目录inode 11927559 中缺少“.”。
处理<y>? 是
将???（11927559）中的项 “.”的文件类型设置为 2。
目录inode 11927559 中缺少“..”。
处理<y>? 是
将???（11927559）中的项 “..”的文件类型设置为 2。
目录inode 11927560，块 #0，偏移量 0：目录缺少校验值。
处理<y>? 是
目录inode 11927560，块 #0，偏移量 0：目录已损坏
修复<y>? 是
目录inode 11927560 中缺少“.”。
处理<y>? 是
将???（11927560）中的项 “.”的文件类型设置为 2。
目录inode 11927560 中缺少“..”。
处理<y>? 是
将???（11927560）中的项 “..”的文件类型设置为 2。
目录inode 11927562，块 #0，偏移量 0：目录缺少校验值。
处理<y>? 是
目录inode 11927562，块 #0，偏移量 0：目录已损坏
修复<y>? 是
目录inode 11927562 中缺少“.”。
处理<y>? 是
将???（11927562）中的项 “.”的文件类型设置为 2。
目录inode 11927562 中缺少“..”。
处理<y>? 是
将???（11927562）中的项 “..”的文件类型设置为 2。
yyyyyyyy/zhiqu/20240616/195334986/output.m3u8（11927572）中的项 “xl.meta”含有删除或未使用的@ 113639509。  清除<y>? 是
yyyyyyyy目录inode 113639482 中“.”的无效的inode编号无效。
处理<y>? 是
目录inode 113639437，块 #0：目录通过了检验，但校验值错误。
处理<y>? 是
<11796996>/<113639440>（113639440）中的项 “..”含有删除或未使用的@ 11796996。  清除<y>? 是
目录inode 113639455，块 #0：目录通过了检验，但校验值错误。
处理<y>? 是
目录inode 113639530 中“.”的无效的inode编号无效。
处理<y>? 是
目录inode 113639430 中“.”的无效的inode编号无效。
处理<y>? 是
目录inode 113639475 中“.”的无效的inode编号无效。
处理<y>? 是
目录inode 113639584 中“.”的无效的inode编号无效。
处理<y>? 是
目录inode 113639498 中“.”的无效的inode编号无效。
处理<y>? 是
目录inode 113639549 中“.”的无效的inode编号无效。
处理<y>? 是
目录inode 113639487 中“.”的无效的inode编号无效。
处理<y>? 是
目录inode 113639525 中“.”的无效的inode编号无效。
处理<y>? 是
目录inode 113639513 中“.”的无效的inode编号无效。
处理<y>? 是
目录inode 113639615 中“.”的无效的inode编号无效。
处理<y>? 是
目录inode 113639566 中“.”的无效的inode编号无效。
处理<y>? 是
目录inode 113639586 中“.”的无效的inode编号无效。
处理<y>? 是
<11796995>/<113639607>（113639607）中的项 “..”含有删除或未使用的@ 11796995。  清除<y>? 是
<11796994>/<113639605>（113639605）中的项 “..”含有删除或未使用的@ 11796994。  清除<y>? 是
y/zhiqu（10747905）中的项 “20240616194229609.webp”含有删除或未使用的@ 11796997。  清除<y>? 是
/zhiqu/20240616（11141538）中的项 “194228223.mp4”含有删除或未使用的@ 11796996。  清除<y>? 是
/zhiqu/20240616（11141538）中的项 “194221854”含有删除或未使用的@ 11796993。  清除<y>? 是
/.minio.sys/tmp/.trash（112459793）中的项 “1f6b2bbe-3c8a-44b6-ac56-4067f6b26ac2”含有删除或未使用的@ 113509713。  清除<y>? 是
/.minio.sys/tmp/.trash（112459793）中的项 “777e0620-def8-4c3a-95a6-a9d2216dfb86”含有删除或未使用的@ 113509796。  清除<y>? 是
/.minio.sys/tmp/.trash（112459793）中的项 “53a929c8-89bb-4f89-bd2c-9e9c0ae54071”含有删除或未使用的@ 113509809。  清除<y>? 是
第 3 步：检查目录连接性
/zhiqu/20240616194249799.webp（11796929）中的“..”为 /zhiqu/20240616（11141538），应为 /zhiqu（10747905）
处理<y>? 是
/zhiqu/20240616194238947.webp（11796958）中的“..”为 <空的 inode>（0），应为 /zhiqu（10747905）
处理<y>? 是
/zhiqu/20240616/194240203（11927554）中的“..”为 <空的 inode>（0），应为 /zhiqu/20240616（11141538）
处理<y>? 是
未被连接的目录inode 11927555（/???）
连接到 /lost+found<y>? 是
未被连接的目录inode 11927556（/???）
连接到 /lost+found<y>? 是
/zhiqu/20240616/194243888（11927557）中的“..”为 <空的 inode>（0），应为 /zhiqu/20240616（11141538）
处理<y>? 是
未被连接的目录inode 11927558（/???）
连接到 /lost+found<y>? 是
未被连接的目录inode 11927559（/???）
连接到 /lost+found<y>? 是
未被连接的目录inode 11927560（/???）
连接到 /lost+found<y>? 是
/zhiqu/20240616/194259243.mp4（11927562）中的“..”为 <空的 inode>（0），应为 /zhiqu/20240616（11141538）
处理<y>? 是
未被连接的目录inode 113639430（/.minio.sys/tmp/.trash/???）
连接到 /lost+found<y>? 是
未被连接的目录inode 113639437（/.minio.sys/tmp/.trash/???）
连接到 /lost+found<y>? 是
未被连接的目录inode 113639440（...）
连接到 /lost+found<y>? 是
未被连接的目录inode 113639455（/.minio.sys/tmp/.trash/???）
连接到 /lost+found<y>? 是
未被连接的目录inode 113639459（/zhiqu/20240616194238947.webp/???）
连接到 /lost+found<y>? 是
未被连接的目录inode 113639475（/.minio.sys/tmp/.trash/???）
连接到 /lost+found<y>? 是
未被连接的目录inode 113639482（/.minio.sys/tmp/.trash/???）
连接到 /lost+found<y>? 是
未被连接的目录inode 113639487（/.minio.sys/tmp/.trash/???）
连接到 /lost+found<y>? 是
未被连接的目录inode 113639498（/.minio.sys/tmp/.trash/???）
连接到 /lost+found<y>? 是
未被连接的目录inode 113639513（/.minio.sys/tmp/.trash/???）
连接到 /lost+found<y>? 是
未被连接的目录inode 113639525（/.minio.sys/tmp/.trash/???）
连接到 /lost+found<y>? 是
未被连接的目录inode 113639530（/.minio.sys/tmp/.trash/???）
连接到 /lost+found<y>? 是
未被连接的目录inode 113639549（/.minio.sys/tmp/.trash/???）
连接到 /lost+found<y>? 是
未被连接的目录inode 113639566（/.minio.sys/tmp/.trash/???）
连接到 /lost+found<y>? 是
未被连接的目录inode 113639584（/.minio.sys/tmp/.trash/???）
连接到 /lost+found<y>? 是
未被连接的目录inode 113639586（/.minio.sys/tmp/.trash/???）
连接到 /lost+found<y>? 是
未被连接的目录inode 113639597（/zhiqu/20240616194249799.webp/???）
连接到 /lost+found<y>? 是
未被连接的目录inode 113639605（...）
连接到 /lost+found<y>? 是
未被连接的目录inode 113639607（...）
连接到 /lost+found<y>? 是
未被连接的目录inode 113639615（/.minio.sys/tmp/.trash/???）
连接到 /lost+found<y>? 是
第 3A 步：优化目录
yyyyyyyyyyyyyyy第 4 步：检查引用计数
Inode 2 的引用计数为 0，应为 5。  处理<y>? 是
Inode 10747905 的引用计数为 2181，应为 2178。  处理<y>? 是
Inode 11141538 的引用计数为 263，应为 259。  处理<y>? 是
Inode 11927554 的引用计数为 4，应为 2。  处理<y>? 是
Inode 11927555 的引用计数为 4，应为 2。  处理<y>? 是
Inode 11927556 的引用计数为 4，应为 2。  处理<y>? 是
Inode 11927557 的引用计数为 5，应为 2。  处理<y>? 是
Inode 11927558 的引用计数为 4，应为 2。  处理<y>? 是
Inode 11927559 的引用计数为 4，应为 2。  处理<y>? 是
Inode 11927560 的引用计数为 4，应为 2。  处理<y>? 是
Inode 11927562 的引用计数为 3，应为 2。  处理<y>? 是
Inode 112459793 的引用计数为 3，应为 10。  处理<y>? 是
Inode 113639430 的引用计数为 3，应为 2。  处理<y>? 是
独立的inode 113639436。  
连接到 /lost+found<y>? 是
Inode 113639436 的引用计数为 2，应为 1。  处理<y>? 是
Inode 113639437 的引用计数为 3，应为 2。  处理<y>? 是
Inode 113639440 的引用计数为 3，应为 2。  处理<y>? 是
独立的inode 113639452。  
连接到 /lost+found<y>? 是
Inode 113639452 的引用计数为 2，应为 1。  处理<y>? 是
Inode 113639455 的引用计数为 3，应为 2。  处理<y>? 是
Inode 113639459 的引用计数为 3，应为 2。  处理<y>? 是
独立的inode 113639471。  
连接到 /lost+found<y>? 是
Inode 113639471 的引用计数为 2，应为 1。  处理<y>? 是
Inode 113639475 的引用计数为 3，应为 2。  处理<y>? 是
独立的inode 113639480。  
连接到 /lost+found<y>? 是
Inode 113639480 的引用计数为 2，应为 1。  处理<y>? 是
Inode 113639482 的引用计数为 3，应为 2。  处理<y>? 是
独立的inode 113639486。  
连接到 /lost+found<y>? 是
Inode 113639486 的引用计数为 2，应为 1。  处理<y>? 是
Inode 113639487 的引用计数为 3，应为 2。  处理<y>? 是
独立的inode 113639493。  
连接到 /lost+found<y>? 是
Inode 113639493 的引用计数为 2，应为 1。  处理<y>? 是
Inode 113639498 的引用计数为 3，应为 2。  处理<y>? 是
独立的inode 113639500。  
连接到 /lost+found<y>? 是
Inode 113639500 的引用计数为 2，应为 1。  处理<y>? 是
独立的inode 113639504。  
连接到 /lost+found<y>? 是
Inode 113639504 的引用计数为 2，应为 1。  处理<y>? 是
Inode 113639513 的引用计数为 3，应为 2。  处理<y>? 是
独立的inode 113639517。  
连接到 /lost+found<y>? 是
Inode 113639517 的引用计数为 2，应为 1。  处理<y>? 是
Inode 113639525 的引用计数为 3，应为 2。  处理<y>? 是
独立的inode 113639526。  
连接到 /lost+found<y>? 是
Inode 113639526 的引用计数为 2，应为 1。  处理<y>? 是
Inode 113639530 的引用计数为 3，应为 2。  处理<y>? 是
独立的inode 113639531。  
连接到 /lost+found<y>? 是
Inode 113639531 的引用计数为 2，应为 1。  处理<y>? 是
独立的inode 113639539。  
连接到 /lost+found<y>? 是
Inode 113639539 的引用计数为 2，应为 1。  处理<y>? 是
Inode 113639549 的引用计数为 3，应为 2。  处理<y>? 是
独立的inode 113639553。  
连接到 /lost+found<y>? 是
Inode 113639553 的引用计数为 2，应为 1。  处理<y>? 是
Inode 113639566 的引用计数为 3，应为 2。  处理<y>? 是
独立的inode 113639577。  
连接到 /lost+found<y>? 是
Inode 113639577 的引用计数为 2，应为 1。  处理<y>? 是
独立的inode 113639578。  
连接到 /lost+found<y>? 是
Inode 113639578 的引用计数为 2，应为 1。  处理<y>? 是
Inode 113639584 的引用计数为 3，应为 2。  处理<y>? 是
Inode 113639586 的引用计数为 3，应为 2。  处理<y>? 是
Inode 113639597 的引用计数为 3，应为 2。  处理<y>? 是
独立的inode 113639599。  
连接到 /lost+found<y>? 是
Inode 113639599 的引用计数为 2，应为 1。  处理<y>? 是
独立的inode 113639600。  
连接到 /lost+found<y>? 是
Inode 113639600 的引用计数为 2，应为 1。  处理<y>? 是
独立的inode 113639601。  
连接到 /lost+found<y>? 是
Inode 113639601 的引用计数为 2，应为 1。  处理<y>? 是
Inode 113639605 的引用计数为 3，应为 2。  处理<y>? 是
Inode 113639607 的引用计数为 3，应为 2。  处理<y>? 是
独立的inode 113639614。  
连接到 /lost+found<y>? 是
Inode 113639614 的引用计数为 2，应为 1。  处理<y>? 是
Inode 113639615 的引用计数为 3，应为 2。  处理<y>? 是
yyyyyyyyyyyyyy第 5 步：检查组概要信息
块位图的差异：  -(47194656--47194660)
处理<y>? 是
组 #1440的可用块计数错误（0，实际为0）。
处理<y>? 是
可用块数错误（0，实际为0）
处理<y>? 是
Inode位图的差异：  -(11796993--11796997)
处理<y>? 是
组 #1440的可用inode计数错误（7690，实际为7695）。
处理<y>? 是
组 #1440的目录计数错误（502，实际为497）
处理<y>? 是
可用inode数错误（201300521，实际为201300501）
处理<y>? 是

/dev/sdc：***** 文件系统已修改 *****
/dev/sdc：26091/201326592 文件（0.6% 为非连续的）， 16807893/805306368 块

 问题解决后查看

[root@k8s-master01 ~]# kubectl get pod -n newlandp
NAME                           READY   STATUS    RESTARTS       AGE
minio-5b9765594b-tmm2x         0/1     Unknown   0              31h
postgresql-0                   1/1     Running   7 (16m ago)    91d
zhiqu-admin-6d88665f8f-69pmv   1/1     Running   7 (13m ago)    8h
zhiqu-d7c8f644-t98kz           1/1     Running   10 (13m ago)   8h
zhiqu-web-b647c9565-z7drb      1/1     Running   5 (16m ago)    38h
[root@k8s-master01 ~]# kubectl delete pod -n newlandp minio-5b9765594b-tmm2x 
pod "minio-5b9765594b-tmm2x" deleted
[root@k8s-master01 ~]# kubectl get pod -n newlandp                           
NAME                           READY   STATUS    RESTARTS       AGE
minio-5b9765594b-g4bwt         1/1     Running   0              59s
postgresql-0                   1/1     Running   7 (17m ago)    91d
zhiqu-admin-6d88665f8f-69pmv   1/1     Running   7 (14m ago)    8h
zhiqu-d7c8f644-t98kz           1/1     Running   10 (14m ago)   8h
zhiqu-web-b647c9565-z7drb      1/1     Running   5 (17m ago)    38h

minio还是unknown，手动删除pod，k8s会自动重启

解决灵感文章：意外断电的情况下linux挂载磁盘报错_e2fsck: get a newer version of e2fsck!-CSDN博客

解决来源：chatgpt问答+自己理解

最终想说真tm扯淡，这个居然没有自己修复，还要lz手动一点点解决，都以为连希捷硬盘都不可靠了