☰

为什么 df 报告外部磁盘空间巨大

tag-icon • tag-icon linux filesystems disk-usage ext4
为什么 df 报告外部磁盘空间巨大

我连接并安装了一个 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

相关内容