Home / server / Questions / 611772
In Process
Goro
Asked: 2014-07-11 17:26:35 +0800 CST

df showing 28G of total space, du showing size of '/' as 400+ G

  • 772

I constantly get the unable to write to * error, even though I cleaned up a bunch of space.

df thinks my disk is 28G in size and 100% full after I deleted a lot of unused files:

$ df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/sda1        28G   28G     0 100% /

The total size of / is now:

$ sudo du -hs /
484G    /

And here's my physical system info:

$ mount
/dev/sda1 on / type ext4 (rw,errors=remount-ro)

$ sudo parted -l
Model: ATA ST1000DM003-1CH1 (scsi)
Disk /dev/sda: 1000GB
Sector size (logical/physical): 512B/4096B
Partition Table: msdos

Number  Start   End     Size    Type      File system     Flags
 1      1049kB  30.0GB  30.0GB  primary   ext4            boot
 2      30.0GB  100GB   70.0GB  primary   ext4
 3      100GB   999GB   899GB   extended
 5      100GB   999GB   899GB   logical   ext4
 4      999GB   1000GB  1285MB  primary   linux-swap(v1)

Update:

The issue was a runaway log file that filled up /dev/sda1. I suppose that what caused df to not show stats for anything other than /dev/sda1 is the fact that they weren't mounted (as output of mount shows above. As to why that happened I have no idea, but after freeing some space and restart, the system was able to mount everything properly.

ubuntu

2 Answers

  1. If you're having a hard time visualizing this, and aren't quite sure what's in your directory tree, try downloading and using the ncdu utility using apt-get.

    • 0

  2. can't add comments yet, but as @Matt wrote - the issue is with limited space on / which acts as both / and /boot in single fs.
    The correct way is probably to separate into 2 filesystems, and mount /boot on /, but that ship has sailed (it would be easier to just reinstall the system, for @Goro ).
    without showing us mount and /etc/fstab, hard to tell the mount hierarchy. possibly autofs is involved too...
    if you want to see which dirs hold the most space, do 

    sudo du -sh /* | sort -h

    and ignore /proc /dev /sys as they are all virtual namespaces (they don't take any actual disk space)

    repeat the above du for the largest dir to track down the space hoggers etc.

    • 0