Encryptfs / Disk Usage Causing System Crash

[tyler]

The problem resides within DUA (disk usage analyzer) but is being caused by the encryptfs virtual file system.

To my understanding it would be logical that DUA reports the encrypted 'home' directory as a different partition ".Private" directory which actually contains all data within the 'Home' directory.

'Home' also reports the exact same amount of usage of disk space.

Now here is the problem.

I am very aware that my disk space is still there, for the mount is virtual. the problem being is that ubuntu and other applications do not feel this to be the same, and it is causing entire system wide destabilization and crashes.

Again its known that disk usage analyzer will report bad disk usage values when dealing with encryptfs and the virtual mount of the .Private and Home folders, but this is cascading across the system and these bad 'values' are causing system crashes slowdowns, etc.

here is some starting Output from DF and DU

username01@fake:~$ df -h
Filesystem Size Used Avail Use% Mounted on
/dev/sda1 139G 120G 12G 91% /
udev 3.9G 4.0K 3.9G 1% /dev
tmpfs 785M 948K 784M 1% /run
none 5.0M 0 5.0M 0% /run/lock
none 3.9G 212K 3.9G 1% /run/shm
/home/username01/.Private 139G 120G 12G 91% /home/username01

username01@fake:~$ sudo du -h --max-depth=1 /
[sudo] password for username01:
4.0K /lib64
1.2M /run
193M /boot
4.0K /media
4.0K /dev
4.0K /srv
1.2G /lib
15M /etc
4.0K /cdrom
8.8M /sbin
4.0K /selinux
du: cannot access `/proc/17168/task/17168/fd/4': No such file or directory
du: cannot access `/proc/17168/task/17168/fdinfo/4': No such file or directory
du: cannot access `/proc/17168/fd/4': No such file or directory
du: cannot access `/proc/17168/fdinfo/4': No such file or directory
0 /proc
264K /build
2.3G /var
0 /sys
3.4M /lib32
16K /lost+found
1.7M /root
du: cannot access `/home/username01/.gvfs': Permission denied
222G /home
4.0K /mnt
76K /tmp
8.9M /bin
5.1G /usr
231G /

After a 12 gig file removal notice no change in disk usage

username01@fake:~$ df -h
Filesystem Size Used Avail Use% Mounted on
/dev/sda1 139G 120G 12G 91% /
udev 3.9G 4.0K 3.9G 1% /dev
tmpfs 785M 948K 784M 1% /run
none 5.0M 0 5.0M 0% /run/lock
none 3.9G 212K 3.9G 1% /run/shm
/home/username01/.Private 139G 120G 12G 91% /home/username01

Here is some output from DU this will show the virtual double.

username01@fake:~$ sudo du -h --max-depth=1 /home
[sudo] password for username01:
du: cannot access `/home/username01/.gvfs': Permission denied
111G /home/username01
111G /home/.ecryptfs
222G /home

Again lets delete more files and post more output (this time approx 20 gigs from home directory)

DF OUTPUT

username01@fake:~$ df -h
Filesystem Size Used Avail Use% Mounted on
/dev/sda1 139G 120G 12G 91% /
udev 3.9G 4.0K 3.9G 1% /dev
tmpfs 785M 948K 784M 1% /run
none 5.0M 0 5.0M 0% /run/lock
none 3.9G 212K 3.9G 1% /run/shm
/home/username01/.Private 139G 120G 12G 91% /home/username01

username01@fake:~$ sudo du -h --max-depth=1 /home
[sudo] password for username01:
du: cannot access `/home/username01/.gvfs': Permission denied
111G /home/username01
111G /home/.ecryptfs
222G /home

DU OUTPUT of everything lets show the 32 gigs did not move to different location....

username01@fake:~$ sudo du -h --max-depth=1 /
[sudo] password for username01:
4.0K /lib64
1.2M /run
193M /boot
4.0K /media
4.0K /dev
4.0K /srv
1.2G /lib
15M /etc
4.0K /cdrom
8.8M /sbin
4.0K /selinux
du: cannot access `/proc/17168/task/17168/fd/4': No such file or directory
du: cannot access `/proc/17168/task/17168/fdinfo/4': No such file or directory
du: cannot access `/proc/17168/fd/4': No such file or directory
du: cannot access `/proc/17168/fdinfo/4': No such file or directory
0 /proc
264K /build
2.3G /var
0 /sys
3.4M /lib32
16K /lost+found
1.7M /root
du: cannot access `/home/username01/.gvfs': Permission denied
222G /home
4.0K /mnt
76K /tmp
8.9M /bin
5.1G /usr
231G /

Ok so after everything we have removed 32 gigs of data.

All viable methods to show disk usage are not returning values of data which has been deleted from partition. The system actually thinks that its file system is full (applications), when infact its not anywhere close to. I am deleting data, and there is no change in any reporting information. and even the reports say there is 9% system disk space left but the system remains unstable to disk space over usage.

Logic being this of expected results from my actions.

If disk space is reported as 'doubled'
If i remove 32 gigs of data
would that not dictate that 64 gigs of data were removed, why is 0 gain reported back on all utilities?

OR

If i remove 32 gigs of data would that not dictate at MINIMUM 32 gig increase in usable space, even though deleted files are not residing in recycle bin, etc....

Also one might note that why am I getting system crashes due to over usage in disk space when i still have disk space left to utilize even if its reported as 'doubled'...

System Info

Ubuntu 12.04 64bit LTS fully updated
memory 7.7 GiB
ntel® Core™ i5 CPU M 560 @ 2.67GHz × 4
disk 149.0 GB

[tyler (bitstocoins)]

After a reboot, all the disk usage counters reset to as they should have. system now registers the usable disk space. Now why a reboot was required i have no idea. Just figured any information is good information.

[Seth Arnold (seth-arnold)]

I suspect you would have seen 'du' and 'df' give back more reasonable values with just umounting and remounting the ecryptfs filesystem, no reboot needed. If a process still had the files open, killing the process might have been sufficient.

However, 'du' and 'df' are blunt instruments -- with modern filesystems, ten gigabytes of files may take more or less than ten gigabytes of disk space, and before they have been flushed, may not appear to exist at all.

Are you actually getting ENOSPC error returns in your programs because you're full? Most applications handle this poorly.

Thanks

[tyler (bitstocoins)]

Nautilus crashed due to ENOSPC

Mysql, and PHP are having problems no enospc errors for them

(mysql and php only accessible through loopbacks also checked logs nothing strange here)

system is rather slow and slugish, all temps are nominal, all hardware tests out fine, only thing is disk space but again its been cleaned and still experiencing problems.

I am going to move data to some form of external device, and bring the entire doubled disk space below what the system thinks it has to see if this will resolve experienced problems.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Antoine Mahé (antoinemahe)]

I experience similar problem except reboot doesn't help.

$> 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 -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

$> sudo du -h --max-depth=1 /home/
119G /home/username
119G /home/.ecryptfs
237G /home/