From: Fariya F <fariya.fatima03@gmail.com>
To: linux-ext4@vger.kernel.org, linux-fsdevel@vger.kernel.org
Subject: df returns incorrect size of partition due to huge overhead block count in ext4 partition
Date: Fri, 25 Mar 2022 12:12:30 +0530 [thread overview]
Message-ID: <CACA3K+i8nZRBxeTfdy7Uq5LHAsbZEHTNati7-RRybsj_4ckUyw@mail.gmail.com> (raw)
My eMMC partition is ext4 formatted and has about 100MB size. df -h
command lists the size of the partition and the used percentage as
below.
Filesystem Size Used Avail Use% Mounted on
/dev/mmcblk2p4 16Z 16Z 79M 100% /data
For your reference, the returned values for statfs64( ) are
statfs64("/data", 88, {f_type="EXT2_SUPER_MAGIC", f_bsize=1024,
f_blocks=18446744073659310077, f_bfree=87628, f_bavail=80460,
f_files=25688, f_ffree=25189, f_fsid={-1446355608, 1063639410},
f_namelen=255, f_frsize=1024, f_flags=4128}) = 0
The output dumpe2fs returns the following
Block count: 102400
Reserved block count: 5120
Overhead blocks: 50343939
As per my kernel (4.9.31) code, the f_blocks is block_count - overhead
blocks. Considering the subtraction with the above values results in a
negative value this is interpreted as the huge value of
18446744073659310077.
I have a script which monitors the used percentage of the partition
using df -h command and when the used percentage is greater than 70%,
it deletes files until the used percentage comes down. Considering df
is reporting all the time 100% usage, all my files get deleted.
My questions are:
a) Where does overhead blocks get set?
b) Why is this value huge for my partition and how to correct it
considering fsck is also not correcting this
Please note fsck on this partition doesn't report any issues at all.
I am also able to create files in this partition.
next reply other threads:[~2022-03-25 6:42 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-03-25 6:42 Fariya F [this message]
2022-03-25 22:11 ` df returns incorrect size of partition due to huge overhead block count in ext4 partition Theodore Ts'o
2022-03-28 16:08 ` Fariya F
2022-03-29 13:08 ` Theodore Ts'o
2022-04-12 8:56 ` Fariya F
2022-04-15 2:54 ` [PATCH 1/3] ext4: fix overhead calculation to account for the reserved gdt blocks Theodore Ts'o
2022-04-15 2:54 ` [PATCH 2/3] ext4: force overhead calculation if the s_overhead_cluster makes no sense Theodore Ts'o
2022-04-15 2:54 ` [PATCH 3/3] ext4: update the cached overhead value in the superblock Theodore Ts'o
2022-04-15 14:41 ` df returns incorrect size of partition due to huge overhead block count in ext4 partition Theodore Ts'o
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CACA3K+i8nZRBxeTfdy7Uq5LHAsbZEHTNati7-RRybsj_4ckUyw@mail.gmail.com \
--to=fariya.fatima03@gmail.com \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.