ok. But I still don't understand well (and I don't find documentation about algorithm behind the df numbers). Here is another example:
$ df -B 1 /dev/mapper/rootvg-homelv /dev/mapper/rootvg-homelv 259963904 15350784 231191552 7% /home percent_used = usedbytes / sizebytes * 100 = 15350784 / 259963904 * 100 = 5.9000 percent_used = (sizebytes - freebytes) / sizebytes * 100 = (259963904 - 231191552) / 259963904 * 100 = 11.0600 Both don't equal the 7% as reported by df and both give a different number. If I try on another filesystem which is much more filled: $ df -B 1 my_nfs_server:/data/export my_nfs_server:/data/export 528430923776 493040697344 8552448000 99% /data/src percent_used = usedbytes / sizebytes * 100 = 493040697344 / 528430923776 * 100 = 93.3000 ercent_used = (sizebytes - freebytes) / sizebytes * 100 = (528430923776 - 8552448000) / 528430923776 * 100 = 98.3800 In that case (when the filesystem has less free space, the second method seems closer from the percentage as reported by df. Nicolas 2013/9/12 Pádraig Brady <[email protected]>: > On 09/12/2013 11:04 AM, Nicolas Michel wrote: >> Hello guys, >> >> I have some difficulties to understand what really are the numbers >> behing "df" and tune2fs. You'll find the output of tune2fs and df >> below, on which my maths are based. >> >> Here are my maths: >> >> A tune2fs on an ext3 FS tell me the FS size is 3284992 block large. It >> also tell me that the size of one block is 4096 (bytes if I'm not >> wrong?). So my maths tell me that the disk is 3284992 * 4096 = >> 13455327232 bytes or 13455327232 / 1024 /1024 /1024 = 12.53 GB. >> >> A df --block-size=1 on the same FS tell me the disk is 13243846656 >> which is 211480576 bytes smaller than what tune2fs tell me. >> >> In gigabytes, it means: >> * for df, the disk is 12.33 GB >> * for tune2fs, the disk is 12.53 GB >> >> I thought that maybe df is only taking into account the real blocks >> available for users. So I tried to remove the reserved blocks and the >> GDT blocks: >> (3284992 - 164249 - 801) * 4096 = 12779282432 >> or in GB : 12779282432 / 1024 / 1024 / 1024 = 11.90 Gb ... >> >> My last thought was that "Reserved block" in tune2fs was not only the >> reserved blocks for root (which is 5% per default on my system) but >> take into account all other reserved blocks fo the fs internal usage. >> So: >> (3284992 - 164249) * 4096 = 12782563328 >> In GB : 11.90 Gb (the difference is not significative with a precision of 2. >> >> So I'm lost ... >> >> Is someone have an explanation? I would really really be grateful. >> Nicolas >> >> --------------------------------------- >> >> Here is the output of df and tune2fs : >> >> $ tune2fs -l /dev/mapper/datavg-datalogslv >> tune2fs 1.41.9 (22-Aug-2009) >> Filesystem volume name: <none> >> Last mounted on: <not available> >> Filesystem UUID: 4e5bea3e-3e61-4fc8-9676-e5177522911c >> Filesystem magic number: 0xEF53 >> Filesystem revision #: 1 (dynamic) >> Filesystem features: has_journal ext_attr resize_inode dir_index >> filetype needs_recovery sparse_super large_file >> Filesystem flags: unsigned_directory_hash >> Default mount options: (none) >> Filesystem state: clean >> Errors behavior: Continue >> Filesystem OS type: Linux >> Inode count: 822544 >> Block count: 3284992 >> Reserved block count: 164249 >> Free blocks: 3109325 >> Free inodes: 822348 >> First block: 0 >> Block size: 4096 >> Fragment size: 4096 >> Reserved GDT blocks: 801 >> Blocks per group: 32768 >> Fragments per group: 32768 >> Inodes per group: 8144 >> Inode blocks per group: 509 >> Filesystem created: Wed Aug 28 08:30:10 2013 >> Last mount time: Wed Sep 11 17:16:56 2013 >> Last write time: Thu Sep 12 09:38:02 2013 >> Mount count: 18 >> Maximum mount count: 27 >> Last checked: Wed Aug 28 08:30:10 2013 >> Check interval: 15552000 (6 months) >> Next check after: Mon Feb 24 07:30:10 2014 >> 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 >> Default directory hash: half_md4 >> Directory Hash Seed: ad2251a9-ac33-4e5e-b933-af49cb4f2bb3 >> Journal backup: inode blocks >> >> $ df --block-size=1 /dev/mapper/datavg-datalogslv >> Filesystem 1B-blocks Used Available Use% Mounted >> on >> /dev/mapper/datavg-datalogslv 13243846656 563843072 12007239680 5% /logs >> > > Well just to confirm that with ext3 on a standard partition here, > df (i.e statfs) returns (Block count - Reserve GDT blocks). > > So you've 50830 blocks unaccounted for by my calc. > It seems like your ext3 file system is reserving that > for some reason not reported by tune2fs. > Perhaps it due to journalling mode/size or something > (which can be adjusted with tune2fs). > > Note you can discount the file system overhead in the output of df > (I wouldn't want that TBH) by remounting with minix_df option. > This is described at http://www.disharmony.nl/?p=54 which also > well explains the different paths to get the 2 numbers. > > cheers, > Pádraig. > -- Nicolas MICHEL
