-1

I realize this question has been asked a number of times but none of the solutions have helped me understand my problem.

This is the output I get from df -h:

Filesystem                 Size  Used Avail Use% Mounted on
udev                        16G  4.0K   16G   1% /dev
tmpfs                      3.2G  812K  3.2G   1% /run
/dev/disk/by-label/DOROOT  315G  297G  2.4G 100% /
none                       4.0K     0  4.0K   0% /sys/fs/cgroup
none                       5.0M     0  5.0M   0% /run/lock
none                        16G  220K   16G   1% /run/shm
none                       100M   28K  100M   1% /run/user

I'm not sure why /dev/disk/by-label/DOROOT has about 15G missing. I've checked for zombie files with lsof -n | grep -i deleted and everything looks fine.

This is the output I get from /sbin/tune2fs -l /dev/disk/by-label/DOROOT

tune2fs 1.42.9 (4-Feb-2014)
Filesystem volume name:   DOROOT
Last mounted on:          /
Filesystem UUID:          050e1e34-39e6-4072-a03e-ae0bf90ba13a
Filesystem magic number:  0xEF53
Filesystem revision #:    1 (dynamic)
Filesystem features:      has_journal ext_attr resize_inode dir_index filetype needs_recovery extent flex_bg sparse_super large_file huge_file uninit_bg dir_nlink extra_isize
Filesystem flags:         signed_directory_hash
Default mount options:    user_xattr acl
Filesystem state:         clean
Errors behavior:          Continue
Filesystem OS type:       Linux
Inode count:              20971520
Block count:              83885568
Reserved block count:     4194262
Free blocks:              4737249
Free inodes:              20557856
First block:              0
Block size:               4096
Fragment size:            4096
Reserved GDT blocks:      1004
Blocks per group:         32768
Fragments per group:      32768
Inodes per group:         8192
Inode blocks per group:   512
RAID stride:              32639
Flex block group size:    16
Filesystem created:       Thu Apr 17 11:45:13 2014
Last mount time:          Mon Sep 12 07:58:15 2016
Last write time:          Mon Sep 12 07:58:15 2016
Mount count:              37
Maximum mount count:      -1
Last checked:             Wed Feb 17 11:07:11 2016
Check interval:           0 (<none>)
Lifetime writes:          3729 GB
Reserved blocks uid:      0 (user root)
Reserved blocks gid:      0 (group root)
First inode:              11
Inode size:               256
Required extra isize:     28
Desired extra isize:      28
Journal inode:            8
First orphan inode:       2621902
Default directory hash:   half_md4
Directory Hash Seed:      ef1fcbab-03ff-497a-881b-3d32da9f753f
Journal backup:           inode blocks

It doesn't seem like the Reserved Block Count is taking up much space either.

How can I find where the 15 remaining gigs from /dev/disk/by-label/DOROOT live?

jgozal
  • 1,480
  • 6
  • 22
  • 43

2 Answers2

1
Reserved block count:     4194262
Block size:               4096

4096*4194262 is a bit under 16 GiB. What is the mystery?

rici
  • 234,347
  • 28
  • 237
  • 341
  • so sorry. I am fairly new to this. Did not know I had to multiply the block count by the block size. Now this makes a lot more sense. If I might follow up with a small question. Do you think it would be safe to truncate some of that reserved block space? – jgozal Sep 12 '16 at 13:14
  • "Safe" is relative. The point of the reserve is that it is usually a lot worse for a system process running as root to run out of disk space than for a user process to do so. 5% is not a large overhead. When you are close to running out of disk space, buy a new disk :) otherwise, your life will be dominated by juggling files, which is probably not a good use of your time. (Of course, if you happen to have 200 gigs of obvious garbage stored on that drive, you could find another solution.) – rici Sep 12 '16 at 13:23
  • much obliged @rici – jgozal Sep 12 '16 at 13:48
-1

Did you truncate any file that reserves space?

Try with 'losetup --all' to see if there is any loop device inside your DOROOT...

IoannisK
  • 29
  • 4