☰

可用磁盘空间

tag-icon • tag-icon partitioning mount raid disk-usage
可用磁盘空间

根据我的供应商，我的 Linux 服务器上有两个 250G 空间的磁盘

lsblk -o NAME,FSTYPE,SIZE,MOUNTPOINT,LABEL
NAME    FSTYPE              SIZE MOUNTPOINT LABEL
sdb                       238.5G
├─sdb2  linux_raid_member   512M            rescue:1
│ └─md1 ext3              511.4M /boot
├─sdb3  linux_raid_member   222G            rescue:2
│ └─md2 ext4              221.9G /
└─sdb1  linux_raid_member    16G            rescue:0
└─md0 swap                 16G [SWAP]
sda                       238.5G
├─sda2  linux_raid_member   512M            rescue:1
│ └─md1 ext3              511.4M /boot
├─sda3  linux_raid_member   222G            rescue:2
│ └─md2 ext4              221.9G /
└─sda1  linux_raid_member    16G            rescue:0
└─md0 swap                 16G [SWAP]

root@Ubuntu-1604-xenial-64-minimal ~ # df -h
Filesystem      Size  Used Avail Use% Mounted on
udev             16G     0   16G   0% /dev
tmpfs           3.2G  318M  2.9G  10% /run
/dev/md2        219G  208G     0 100% /
tmpfs            16G  4.0K   16G   1% /dev/shm
tmpfs           5.0M     0  5.0M   0% /run/lock
tmpfs            16G     0   16G   0% /sys/fs/cgroup
tmpfs           8.0G  1.4G  6.7G  17% /opt/zammad/tmp
/dev/md1        488M  199M  264M  43% /boot
tmpfs           3.2G     0  3.2G   0% /run/user/0

我删除了一些备份（超过 21GB）/opt/zammad-db-backups

然后我得到了

root@Ubuntu-1604-xenial-64-minimal /opt/zammad-db-backups # df -h
Filesystem      Size  Used Avail Use% Mounted on
udev             16G     0   16G   0% /dev
tmpfs           3.2G  318M  2.9G  10% /run
/dev/md2        219G  207G  715M 100% /
tmpfs            16G  4.0K   16G   1% /dev/shm
tmpfs           5.0M     0  5.0M   0% /run/lock
tmpfs            16G     0   16G   0% /sys/fs/cgroup
tmpfs           8.0G  1.4G  6.7G  17% /opt/zammad/tmp
/dev/md1        488M  199M  264M  43% /boot
tmpfs           3.2G     0  3.2G   0% /run/user/0

为什么 '/' 中只有 715M？其余的 >21GB 在哪里？

为什么我只得到

du / -sh
du: cannot access '/proc/21051/task/21051/fd/4': No such file or directory
du: cannot access '/proc/21051/task/21051/fdinfo/4': No such file or directory
du: cannot access '/proc/21051/fd/3': No such file or directory
du: cannot access '/proc/21051/fdinfo/3': No such file or directory
85G     /

当 df 命令告诉我根挂载点时，使用了 85G，我已经使用了 219G 的 100%

RAID 系统是否使用剩余空间来提供冗余数据？250GB 磁盘，我大约可以使用 85GB（加上其余分区还可以，但还是太多了（？））

df -i 的输出

df -i
Filesystem       Inodes   IUsed    IFree IUse% Mounted on
udev            4092629     461  4092168    1% /dev
tmpfs           4099946    1691  4098255    1% /run
/dev/md2       14540800 3453478 11087322   24% /
tmpfs           4099946       2  4099944    1% /dev/shm
tmpfs           4099946       4  4099942    1% /run/lock
tmpfs           4099946      17  4099929    1% /sys/fs/cgroup
tmpfs           4099946  334275  3765671    9% /opt/zammad/tmp
/dev/md1         131072     308   130764    1% /boot
tmpfs           4099946       4  4099942    1% /run/user/0

答案1

当您拥有一个大小合适的分区时，对其进行格式化可能会 a) 由于文件系统的粒度，在分区末尾丢弃一些不可用的部分，并且 b) 占用一些空间来管理这个新卷的数据，包括日志记录（崩溃故障安全功能）和类似的东西（比如减少磨损的方法）。这是很自然的，并且特定于所选的文件系统。选择（或设计）不同的文件系统可以改变这一点。有时在创建时文件系统有配置选项，这些选项也可以改变这个内存消耗占用。一些文件系统甚至可以重新配置现有的卷。

当您的系统正在运行时，您可能正在运行一些应用程序，这些应用程序占用了一些空间，再次释放了它，但尚未关闭这些文件（通过它们的文件句柄）。在这个范围内可能还有其他方面，例如对硬链接的特殊情况处理。有选择地关闭应用程序可能会释放并从而揭示发起者。下次重新启动机器时应该只清理状态。应该有用于监视文件句柄和应用程序文件使用情况的工具 - 例如“strace”工具显示了一些基本功能。（对于这种监控，有一些更高级的方法，其中一些仍然基于股票“strace”二进制文件。）仅监视系统中的可列出文件可能不太可能揭示这些特定情况的根本原因。

相关内容