[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Numbers behind "df" and "tune2fs"
From: |
Nicolas Michel |
Subject: |
Re: Numbers behind "df" and "tune2fs" |
Date: |
Mon, 16 Sep 2013 13:24:04 +0200 |
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 <address@hidden>:
> 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