![为什么 df 报告外部磁盘空间巨大](https://linux22.com/image/196474/%E4%B8%BA%E4%BB%80%E4%B9%88%20df%20%E6%8A%A5%E5%91%8A%E5%A4%96%E9%83%A8%E7%A3%81%E7%9B%98%E7%A9%BA%E9%97%B4%E5%B7%A8%E5%A4%A7.png)
我连接并安装了一个 32GB 的外部磁盘。以下命令中提供了所有详细信息。
# lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sdb 8:16 0 32G 0 disk /storage/1
# df -h
Filesystem Size Used Avail Use% Mounted on
/dev/sdb 64Z 64Z 32G 100% /storage/1
# df
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/sdb 73786976294837417744 73786976294804701208 32700152 100% /storage/1
# du -sh /storage/1
4.0K /storage/1
# mount | grep /dev/sdb
/dev/sdb on /storage/1 type ext4 (ro,relatime,errors=continue,data=ordered)
# grep /dev/sdb /etc/fstab
/dev/sdb /storage/1 ext4 rw,noatime,nodiratime 0 0
# findmnt
TARGET SOURCE FSTYPE OPTIONS
/ /dev/sda1 ext4 rw,relatime,errors=remount-ro,stripe=32592,data=ordered
`-/storage/1 /dev/sdb ext4 ro,relatime,errors=continue,data=ordered
问题:
如果我们查看df
输出,就会发现该磁盘的大小非常奇怪且巨大。磁盘根本没有被使用。df
(在 下Avail
)将其报告为 32 GB,这是磁盘的大小。此外,du
报告为 4KB。
因此,我无法理解df
该设备的输出可能出了什么问题。
谷歌搜索之一表明格式化/dev/sdb
而不是创建分区然后格式化/dev/sdb1
可能是问题所在。但是,我有很多服务器都遵循相同的规则,但没有一个出现此问题。
更新:
正如@Stephen 所建议的,文件系统似乎不健康:
# dumpe2fs /dev/sdb
dumpe2fs 1.43.4 (31-Jan-2017)
dumpe2fs: Bad magic number in super-block while trying to open /dev/sdb
Couldn't find valid filesystem superblock.
在此方面失败dumpe2fs
了。另外,我查看dmesg
并发现它确实记录了该磁盘的一些错误:
[Tue Sep 21 15:52:28 2021] EXT4-fs error (device sdb): ext4_map_blocks:567: inode #2: block 9253: comm ls: lblock 0 mapped to illegal pblock 9253 (length 1)
[Tue Sep 21 15:52:28 2021] EXT4-fs error (device sdb) in ext4_reserve_inode_write:5460: Corrupt filesystem
[Tue Sep 21 15:52:30 2021] EXT4-fs error (device sdb): ext4_map_blocks:567: inode #2: block 9253: comm ls: lblock 0 mapped to illegal pblock 9253 (length 1)
[Tue Sep 21 15:52:34 2021] EXT4-fs error (device sdb): ext4_map_blocks:567: inode #8: block 4227126: comm jbd2/sdb-8: lblock 54 mapped to illegal pblock 4227126 (length 1)
[Tue Sep 21 15:52:34 2021] jbd2_journal_bmap: journal block not found at offset 54 on sdb-8
[Tue Sep 21 15:52:34 2021] Aborting journal on device sdb-8.
[Tue Sep 21 15:53:41 2021] systemd[1]: apt-daily-upgrade.timer: Adding 33min 33.126422s random time.
[Tue Sep 21 15:53:41 2021] systemd[1]: apt-daily.timer: Adding 2h 35min 49.981791s random time.
[Tue Sep 21 15:53:55 2021] EXT4-fs error (device sdb): ext4_map_blocks:567: inode #2: block 9253: comm du: lblock 0 mapped to illegal pblock 9253 (length 1)
[Tue Sep 21 15:53:59 2021] EXT4-fs error (device sdb): ext4_map_blocks:567: inode #2: block 9253: comm ls: lblock 0 mapped to illegal pblock 9253 (length 1)
[Tue Sep 21 15:54:01 2021] EXT4-fs error (device sdb): ext4_map_blocks:567: inode #2: block 9253: comm du: lblock 0 mapped to illegal pblock 9253 (length 1)
[Tue Sep 21 16:18:49 2021] systemd[1]: apt-daily-upgrade.timer: Adding 38min 44.297529s random time.
[Tue Sep 21 16:18:49 2021] systemd[1]: apt-daily.timer: Adding 3h 34min 3.596906s random time.
[Wed Sep 22 17:03:22 2021] EXT4-fs (sdb): error count since last fsck: 7
[Wed Sep 29 02:50:32 2021] EXT4-fs (sdb): initial error at time 1632219748: ext4_map_blocks:567: inode 2: block 9253
[Wed Sep 29 02:50:32 2021] EXT4-fs (sdb): last error at time 1632219841: ext4_map_blocks:567: inode 2: block 9253
[Thu Sep 30 04:28:24 2021] EXT4-fs (sdb): error count since last fsck: 7
[Fri Oct 1 06:06:15 2021] EXT4-fs (sdb): initial error at time 1632219748: ext4_map_blocks:567: inode 2: block 9253
[Fri Oct 1 06:06:15 2021] EXT4-fs (sdb): last error at time 1632219841: ext4_map_blocks:567: inode 2: block 9253
[Fri Oct 1 13:11:23 2021] EXT4-fs error (device sdb): ext4_map_blocks:567: inode #2: block 9253: comm du: lblock 0 mapped to illegal pblock 9253 (length 1)
[Fri Oct 1 13:11:23 2021] EXT4-fs error (device sdb): ext4_journal_check_start:56: Detected aborted journal
[Fri Oct 1 13:11:23 2021] EXT4-fs (sdb): Remounting filesystem read-only
[Fri Oct 1 13:17:35 2021] EXT4-fs error (device sdb): ext4_map_blocks:567: inode #2: block 9253: comm du: lblock 0 mapped to illegal pblock 9253 (length 1)
在此框中(如上面的 dmesg 错误所示):
# hostname -i && dmesg -T | grep 'inode 2: block 9253' | wc -l
10.53.242.33
18
所以我查看了该集群中另外 2 个类似的服务器(我们正在运行Clickhouse数据库在此集群上),观察到相同的问题:
# hostname -i && dmesg -T | grep 'inode 2: block 9253' | wc -l
10.52.115.33
610
# hostname -i && dmesg -T | grep 'inode 2: block 9253' | wc -l
10.53.98.72
171
所以我想知道所有 3 台服务器如何抱怨完全相同的 inode 和块,同时它们都连接了自己的单独 32GB 设备。
我可以忽略这个问题,说我的磁盘在这个盒子上坏了,这是足够公平的结论,但是在其他服务器上具有相同 inode 和块的完全相同的错误对我来说有点困惑。此外,这两台服务器也无法报告dumpe2fs
相同的“坏幻数”错误。
答案1
您的分区表已损坏。如果您不关心数据,请卸载分区并重新分区磁盘。它也可能受到物理损坏,在这种情况下您应该将其丢弃。
我会这样做:
umount /storage/1
cat /dev/zero > /dev/sdb
fdisk /dev/sdb (or any other tool, including parted, gparted, gdisk, etc.)
mkfs.[whatever] /dev/sdbX