HDD usage 100% but used space is less than total size

rodrifra · 03-25-2012, 03:26 PM

Hello everyone.

I'm having an issue with a hdd and I can't help finding an explanation to it.

I have the next output from df -h

Code:

S.ficheros            Tam.  Usado Disp. % Uso Montado en
/dev/sda1              102G  60G   0  100% /

I thought I could have run out of i-nodes, but df -hi shows the next output

Code:

S.ficheros            Inodos   IUsado   ILibre IUso% Montado en
/dev/sda1               6,5M    192K    6,3M    3% /

I have fsck'd the system and everything seems to be OK. Anybody has any idea about where is the missing space?

By the way, SMART data only shows 1 bad sector.

Thanks.

pan64 · 03-26-2012, 06:49 AM

what is the real size of that partition? Can you check the partition table also?

WSmart · 03-26-2012, 09:43 AM

Greetings,

One instance where the system says you have less available space then you have is when the trash folder hasn't been emptied.

And, not everyone might realize that new hard drives are rated at about 6% over what they hold becuase of a difference in how the data bits are counted, so a 160 GB drive holds about 150 GB.

And I guess you must have rebooted, but if not that's worth a try.

Thanks for posting.

Be real, be sober.

rodrifra · 03-27-2012, 10:31 AM

Thanks for your answers.

Quote:

what is the real size of that partition? Can you check the partition table also?

The real size is what df shows (102G). And partition table is OK.

WSmart, as far as I know, df shows information of the hdd space usage regardless if it is used in hidden files, regular files or whatever kind of files.

I know that formating a drive takes space, but df shows the avalable space once a drive has been formated. It doesn't show the real hdd drive space as fdisk -l does.

anomie · 03-27-2012, 10:37 AM

It might be illuminating to see output from the following:

Code:

# find / -xdev -size +200M -exec du -m {} \; | sort -nr | head

pan64 · 03-27-2012, 01:02 PM

another tip: have you tried to reboot the system?
(sometimes there can be files already deleted but still used by processes.)

rodrifra · 03-27-2012, 03:22 PM

Hi pan64. Yes, I have restarted the system but the problem persists.

Hello anomie. The output of the find comand shows the biggest files on the system, they are video files ranging from 2,2G down to 1G in what the head command shows. How could that be illuminating? Do you think the blocksize used for the filesystem has something to do with the missing space? in that case... wouldn't it be the smallest files (less than block size) the ones that crop that space?

Thanks all for your answers.

anomie · 03-27-2012, 03:58 PM

I was hoping it might identify an unexpected / large file on your filesystem. (Perhaps something that was growing out of control.) That doesn't appear to be the case.

Actually, no, I wasn't suspecting a strange blocksize problem. But now that we're talking about, may as well check "free blocks" et al. with dumpe2fs(8) -- or whatever utility the filesystem you're using provides.

pan64 · 03-28-2012, 12:54 AM

Can you create files on that drive, or it reports now "disk full"?
Can you try other tools (du -sh / for example) to see the amount of free/used space?
You need to find out which one is incorrect (total/used/free ?) and than maybe we can find out why.
Which OS you have?

rodrifra · 03-28-2012, 03:54 PM

Here is the output of both, df and dumpe2fs. As you can see, there are free blocks, although disk space appears full. A curious thing I have realized is that removing files doesn't free space, but the amount of used space is reduced, a df after the removal is also attached.

dumpe2fs

Code:

Filesystem volume name:   <none>
Last mounted on:          /
Filesystem UUID:          317c7184-67ad-4b81-99a7-93752a517faf
Filesystem magic number:  0xEF53
Filesystem revision #:    1 (dynamic)
Filesystem features:      has_journal ext_attr resize_inode dir_index filetype n
eeds_recovery extent flex_bg sparse_super large_file huge_file uninit_bg dir_nli
nk extra_isize
Filesystem flags:         signed_directory_hash 
Default mount options:    (none)
Filesystem state:         clean
Errors behavior:          Continue
Filesystem OS type:       Linux
Inode count:              6758400
Block count:              27024640
Reserved block count:     1351232
Free blocks:              10907942
Free inodes:              6562427
First block:              0
Block size:               4096
Fragment size:            4096
Reserved GDT blocks:      1017
Blocks per group:         32768
Fragments per group:      32768
Inodes per group:         8192
Inode blocks per group:   512
Filesystem created:       Tue Jan 16 02:12:26 2007
Last mount time:          Sat Jan 20 03:18:51 2007
Last write time:          Tue Jan 16 22:09:24 2007
Mount count:              5
Maximum mount count:      27
Last checked:             Tue Jan 16 21:16:53 2007
Check interval:           15552000 (6 months)
Next check after:         Sun Jul 15 22:16:53 2007
Lifetime writes:          7168 PB
Reserved blocks uid:      0 (user root)
Reserved blocks gid:      0 (group root)
First inode:              11
Inode size:	          256
Journal inode:            8
First orphan inode:       3672283
Default directory hash:   half_md4
Directory Hash Seed:      aa21bc15-4e47-44b3-bd4d-a32b2a58ff4b
Journal backup:           inode blocks
Journal features:         journal_incompat_revoke
Tamaño de fichero de transacciones:  128M
Journal length:           32768
Journal sequence:         0x00006e84
Journal start:            1


Grupo 0: (Bloques 0-32767) [ITABLE_ZEROED]
  Checksum 0x089d, unused inodes 8177
  Primario superbloque en 0, descriptores de grupo en 1-7
  Se reservaron los bloques GDT en 8-1024
  Mapa de bits de bloque en 1025 (+1025), mapa de bits de nodo-i en 1041 (+1041)
  tabla de nodos-i en 1057-1568 (+1057)
  15896 free blocks, 8177 free inodes, 2 directories, 8177 unused inodes
  Bloques libres: 9255-10239, 14047-14335, 18146-32767
  Nodos-i libres: 16-8192
Grupo 1: (Bloques 32768-65535) [INODE_UNINIT, ITABLE_ZEROED]
..........
..........
..........
..........

df -h (before file removal)

Code:

S.ficheros            Tamaño Usado  Disp Uso% Montado en
/dev/sda2             102G   60G     0 100% /
none                  940M  304K  939M   1% /dev
none                  944M     0  944M   0% /dev/shm
none                  944M  200K  944M   1% /var/run
none                  944M     0  944M   0% /var/lock
none                  944M     0  944M   0% /lib/init/rw

df -h (after file removal)

Code:

S.ficheros            Tamaño Usado  Disp Uso% Montado en
/dev/sda2             102G   56G     0 100% /
none                  940M  304K  939M   1% /dev
none                  944M     0  944M   0% /dev/shm
none                  944M  200K  944M   1% /var/run
none                  944M     0  944M   0% /var/lock
none                  944M     0  944M   0% /lib/init/rw

Does anyone has an explanation for this behaviour?

anomie · 03-28-2012, 04:07 PM

Quote:

Originally Posted by rodrifa

Code:

Last mount time:          Sat Jan 20 03:18:51 2007
Last write time:          Tue Jan 16 22:09:24 2007
...
Last checked:             Tue Jan 16 21:16:53 2007

What..?!

Can you 'splain that?

I was under the impression you did a fsck(8) on the filesystem. Maybe you will need to force one.

rodrifra · 03-28-2012, 04:40 PM

Its a laptop and bios battery is over.
I did force fsck with -f and tried -p but with no success.

pan64 · 03-29-2012, 12:19 AM

try to boot another OS, maybe from a CD and check it again