我有一个相当普通的 xubuntu 安装，在运行了大约 1.5 年之后，突然出现“磁盘已满”错误。它有一个系统 SSD（约 128GB）、一个包含 samba 共享的“数据”SSD（约 500GB）和一个用于自我备份的 raid（两个约 4TB HDD）。它还运行 subsonic 实例来流式传输音频文件。这是设置：
root@castor:/# lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sda 8:0 0 3.7T 0 disk
└─md0 9:0 0 3.7T 0 raid1
└─md0p1 259:6 0 3.7T 0 md /raid
sdb 8:16 0 3.7T 0 disk
└─md0 9:0 0 3.7T 0 raid1
└─md0p1 259:6 0 3.7T 0 md /raid
nvme0n1 259:0 0 477G 0 disk
└─nvme0n1p1 259:1 0 477G 0 part /data
nvme1n1 259:2 0 111.8G 0 disk
├─nvme1n1p1 259:3 0 512M 0 part /boot/efi
├─nvme1n1p2 259:4 0 732M 0 part /boot
└─nvme1n1p3 259:5 0 110.6G 0 part
└─nvme0n1p3_crypt 253:0 0 110.6G 0 crypt
├─xubuntu--vg-root 253:1 0 109.6G 0 lvm /
└─xubuntu--vg-swap_1 253:2 0 976M 0 lvm [SWAP]
在上面，请注意/data和/raid已打开单独的物理设备从/。系统认为/已满：
root@castor:/# df -h /
Filesystem Size Used Avail Use% Mounted on
/dev/mapper/xubuntu--vg-root 108G 106G 0 100% /
但如果我排除/data，/raid我看到只使用了 9GB，而不是使用了 106GB：
root@castor:/# du -hs --exclude={./data,./raid}
du: cannot access './run/user/110/gvfs': Permission denied
du: cannot access './proc/1747/task/1747/fd/4': No such file or directory
du: cannot access './proc/1747/task/1747/fdinfo/4': No such file or directory
du: cannot access './proc/1747/fd/3': No such file or directory
du: cannot access './proc/1747/fdinfo/3': No such file or directory
9.0G .
这里发生了什么？这与使用加密文件系统安装或使用 LVM 有关吗？ （我承认我并不真正知道 LVM 在幕后是如何工作的，我只是抽象地知道它应该允许多个物理设备构成一个逻辑“驱动器”）。
如果它有用，这里du没有exclude争论；它显然包括以下内容/data和/raid总计：
root@castor:/# du -hs /data
220G /data
root@castor:/# du -hs /raid
220G /raid
root@castor:/# du -hs .
du: cannot access './run/user/110/gvfs': Permission denied
du: cannot access './proc/1762/task/1762/fd/4': No such file or directory
du: cannot access './proc/1762/task/1762/fdinfo/4': No such file or directory
du: cannot access './proc/1762/fd/3': No such file or directory
du: cannot access './proc/1762/fdinfo/3': No such file or directory
448G .
这是完整的输出df
root@castor:/# df -h
Filesystem Size Used Avail Use% Mounted on
udev 7.7G 0 7.7G 0% /dev
tmpfs 1.6G 3.0M 1.6G 1% /run
/dev/mapper/xubuntu--vg-root 108G 106G 0 100% /
tmpfs 7.7G 0 7.7G 0% /dev/shm
tmpfs 5.0M 4.0K 5.0M 1% /run/lock
tmpfs 7.7G 0 7.7G 0% /sys/fs/cgroup
/dev/nvme0n1p1 469G 220G 226G 50% /data
/dev/nvme1n1p2 705M 81M 573M 13% /boot
/dev/nvme1n1p1 511M 6.1M 505M 2% /boot/efi
tmpfs 1.6G 4.0K 1.6G 1% /run/user/110
tmpfs 1.6G 0 1.6G 0% /run/user/1000
/dev/md0p1 3.6T 221G 3.2T 7% /raid
编辑回答“在哪里/proc？”
root@castor:/# du -hs /proc
du: cannot access '/proc/1797/task/1797/fd/4': No such file or directory
du: cannot access '/proc/1797/task/1797/fdinfo/4': No such file or directory
du: cannot access '/proc/1797/fd/3': No such file or directory
du: cannot access '/proc/1797/fdinfo/3': No such file or directory
0 /proc
root@castor:/# ll /proc -S | head
total 4
-r-------- 1 root root 140737477881856 Jun 11 13:53 kcore
drwxr-xr-x+ 27 root root 4096 Jun 11 12:22 ../
lrwxrwxrwx 1 root root 11 Jun 11 13:53 mounts -> self/mounts
lrwxrwxrwx 1 root root 8 Jun 11 13:53 net -> self/net/
dr-xr-xr-x 185 root root 0 Jun 11 12:34 ./
dr-xr-xr-x 9 root root 0 Jun 11 12:34 1/
dr-xr-xr-x 9 root root 0 Jun 11 12:35 10/
dr-xr-xr-x 9 root root 0 Jun 11 12:35 100/
dr-xr-xr-x 9 root root 0 Jun 11 12:35 1016/
答案1
事实证明，/raid在某些时候没有正确重新安装，因此有一段时间自动每日备份没有写入实际的raid /dev/md0（安装在/raid），但被写入/raid上的文件夹/dev/xubuntu-vg/root。我没有注意到这一点，因为在我开始调查时，实际的突袭曾是安装在/raid并有效地屏蔽了底层文件夹的内容。
总而言之，问题解决了
umount /raid
mdadm --stop /dev/md0
rm -rf /raid/*
mdadm --create --assume-clean --level=1 /dev/md0 --raid-devices=2 /dev/sda /dev/sdb
mount /raid