我使用安装程序提供的选项安装我的工作站来加密我的“/home”目录,我希望它在使用时完全透明,但是在系统警告我文件系统已满后,我发现一半空间被报告为已使用“ecrypt”文件,而另一半由“/home/username”目录使用。
我确实读到了这样一个事实,即 /home/user 是 .ecrypt 中真实数据的虚拟挂载,不应在硬盘驱动器上占用更多空间。
但是我的系统(ubuntu 16.04)似乎并没有这样理解它,这让我无法完全使用我的硬盘。
"df" 报告 /home 分区的大小为 226G,"du" 确认一半用 /home/user 填充,一半用 .ecrypt 部分填充。
其他使系统调用检查文件系统的实用程序遇到了同样的问题,例如 python os.statvfs('/home/') 显示的结果与“du”一致。
如果 eCrypt 没有“加倍”用于 /home 文件夹的空间,我该如何帮助系统理解它?如果我的硬盘确实已满,我该如何正确使用 eCrypt,这样它就不会使 /home 数据所需的空间增加一倍?
下面是先前讨论的命令的确切结果:
系统信息 :
$> uname -a
Linux pc-name 4.15.0-43-generic #46~16.04.1-Ubuntu SMP Fri Dec 7 13:31:08 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
df 结果:
$> df -h
udev 3,9G 0 3,9G 0% /dev
tmpfs 787M 9,5M 778M 2% /run
/dev/mapper/ubuntu--vg-root 226G 199G 16G 93% /
tmpfs 3,9G 71M 3,8G 2% /dev/shm
tmpfs 5,0M 4,0K 5,0M 1% /run/lock
tmpfs 3,9G 0 3,9G 0% /sys/fs/cgroup
/dev/nvme0n1p2 473M 121M 328M 27% /boot
/dev/nvme0n1p1 511M 3,5M 508M 1% /boot/efi
tmpfs 787M 36K 787M 1% /run/user/1000
/home/username/.Private 226G 199G 16G 93% /home/username
lsblk 的结果:
$>sudo lsblk -o NAME,FSTYPE,SIZE,MOUNTPOINT,LABEL
NAME FSTYPE SIZE MOUNTPOINT LABEL
nvme0n1 238,5G
├─nvme0n1p3 LVM2_member 237,5G
│ ├─ubuntu--vg-swap_1 swap 7,9G
│ │ └─cryptswap1 swap 7,9G [SWAP]
│ └─ubuntu--vg-root ext4 229,6G /
├─nvme0n1p1 vfat 512M /boot/efi
└─nvme0n1p2 ext2 488M /boot
杜结果:
$> sudo du -h --max-depth=1 /home/
119G /home/username
119G /home/.ecryptfs
237G /home/
蟒蛇观点:
Python 2.7.12 (default, Nov 12 2018, 14:36:49)
[GCC 5.4.0 20160609] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import os
>>> statvfs = os.statvfs('/home/')
>>> statvfs.f_frsize * statvfs.f_blocks
242521694208
#that is 242G of hardrive
>>> statvfs.f_frsize * statvfs.f_bfree
29071433728
>>> statvfs.f_frsize * statvfs.f_bavail
16728436736
#16G of free space
欢迎进一步解决或诊断问题的任何帮助,例如检查实际磁盘使用情况的工具。
-- 编辑在用户未登录时添加 df 信息:
Sys. de fichiers Taille Utilisé Dispo Uti% Monté sur
udev 3,9G 0 3,9G 0% /dev
tmpfs 787M 9,5M 778M 2% /run
/dev/mapper/ubuntu--vg-root 226G 201G 14G 94% /
tmpfs 3,9G 252K 3,9G 1% /dev/shm
tmpfs 5,0M 4,0K 5,0M 1% /run/lock
tmpfs 3,9G 0 3,9G 0% /sys/fs/cgroup
/dev/nvme0n1p2 473M 121M 328M 27% /boot
/dev/nvme0n1p1 511M 3,5M 508M 1% /boot/efi
tmpfs 787M 120K 787M 1% /run/user/1002
在遵循 Xen2050 的建议后,我找到了问题的根源。当错误发生时,“加倍”大小确实超出了磁盘空间,因此由于 eCrypt 虚拟安装(如预期的那样),磁盘未满。经过调查,磁盘似乎一方面被 /home 分区(~120G)有效使用,但也被包含 62G docker libs 的 /var/lib 使用......
最初的误解来自使用 eCrypt 的用户的 df 输出,其中显示:
让我相信所有的空间都被 /home/username 分区吃掉了