Question

29

Disk slowly filling up but no visible file size changes

rated 0 times [ 29] [ 0] / answers: 1 / hits: 4255 / 3 Years ago, thu, july 15, 2021, 10:30:29

df

 Filesystem     1K-blocks     Used Available Use% Mounted on

/dev/vda1       30830588 22454332   6787120  77% /

none                   4        0         4   0% /sys/fs/cgroup

udev             1014124        4   1014120   1% /dev

tmpfs             204996      336    204660   1% /run

none                5120        0      5120   0% /run/lock

none             1024976        0   1024976   0% /run/shm

none              102400        0    102400   0% /run/user

That 77% was just 60% yesterday and it will fill up to 100% in a few days.

I've been monitoring filessizes for a while now:

sudo du -sch /*





9.6M    /bin

65M     /boot

224K    /build

4.0K    /dev

6.5M    /etc

111M    /home

0       /initrd.img

0       /initrd.img.old

483M    /lib

4.0K    /lib64

16K     /lost+found

8.0K    /media

4.0K    /mnt

4.0K    /opt

du: cannot access ‘/proc/21705/task/21705/fd/4’: No such file or directory

du: cannot access ‘/proc/21705/task/21705/fdinfo/4’: No such file or directory

du: cannot access ‘/proc/21705/fd/4’: No such file or directory

du: cannot access ‘/proc/21705/fdinfo/4’: No such file or directory

0       /proc

21M     /root

336K    /run

12M     /sbin

8.0K    /srv

4.1G    /swapfile

0       /sys

4.0K    /tmp

1.1G    /usr

7.4G    /var

0       /vmlinuz

0       /vmlinuz.old

14G     total

It's been giving me (more or less) the same numbers every day. That 14G total is less than half the disk size. Where is the rest going?

My Linux knowledge does not go a lot deeper.

Is it possible for files to no show up here? Is it possible to have space allocated in any other way?

Answers

Only authorized users can answer the question. Please sign in first, or register a free account.

barted

Add To Favorites

Follow

Total Points: 424

Total Questions: 103

Total Answers: 101

Location: Djibouti

Member since Sun, Feb 27, 2022

2 Years ago

answered 3 Years ago bunsistent · Accepted Answer

If there's an invisible growth in disk space, a likely culprit would be deleted files. In Windows, if you try to delete a file opened by something, you get an error. In Linux, the file will be marked as deleted, but the data will be retained until the application lets go. In some cases, this can be used as a neat way to clean up after yourself - application crashes won't prevent temporary files from being cleaned.

To look at deleted, still-used files:

lsof -b 2>/dev/null | grep deleted

You may have a large number of deleted files - that in itself is not a problem. A single deleted file getting large is a problem.

A reboot should fix this, but if you don't want to reboot, check the applications involved (first column in lsof output) and restart or close reasonable looking ones.

If you ever see something like:

zsh   1724   muru   txt   REG   8,17   771448   1591515  /usr/bin/zsh (deleted)

Where the application and the deleted files are the same, that probably means the application was upgraded. You can ignore those as a source of large disk usage (but you should still restart the program so that bug-fixes apply).

Files in /dev/shm are shared memory objects and don't occupy much space on disk (an inode number at most, I think). They can also be safely ignored. Files named vteXXXXXX are log files from a VTE-based terminal emulator (like GNOME Terminal, Terminator, etc.). These could be large, if you have a terminal window open with lots (and I mean lots) of stuff being output.