2

We have an application which stores files and provides a "disk filling level" to the user.

To achieve that we use the disk_total_space and disk_free_space combo, works great on the dev machine (mac os, local hdd around 250Gb).

On the production machine which use a 20Tb SAN bay storage the results are (way) off :

df -h output :

Filesystem                 Size  Used Avail Use% Mounted on
/dev/mapper/VG1-lv_foo01   20T   141M 19T   1%   /foo01

df -hi output (inodes) :

Filesystem                 Size  Used Avail Use% Mounted on
/dev/mapper/VG1-lv_foo01   320M  30   320M  1%   /foo01

disk_total_space("/foo01") returns 21902586179584 which is roughly 19.92Tb, looks about right.

But disk_free_space("/foo01") returns 20802911117312 which is roughly 18.92Tb, that would mean about 1Tb is being used on disk but in reality only about 140Mb is really used !

From where could that difference come from ? Inodes should not amount for a lot of space since only a few are used ...

I'm pretty confused, any idea ?

yent
  • 1,303
  • 1
  • 8
  • 10
  • 1
    @Epodax I can't agree with you here, system tools return the right figures (confirmed by storage bay manager), the one off here seems to be php, that's why I'd like to know if there could be some php drive space computation weirdness in this situation. – yent Aug 03 '15 at 09:29

1 Answers1

4

EXT systems reserve some space for root, by default I believe it is 5%. That must be why you see about 1TB used.

You can reduce that share or disable it with tune2fs:

#Set it to 1%
tune2fs -m 1 /dev/mapper/VG1-lv_foo01
blue112
  • 52,634
  • 3
  • 45
  • 54
  • Thanks for the hint ! I did a `dumpe2fs /dev/mapper/VG1-lv_foo01`, in the output I found `Reserved block count: 268435353`, that amounts the missing 1Tb (blocks size 4096) ! Will see with admin to have him reduce that, many thanks ! – yent Aug 03 '15 at 09:45