Red Hat Bugzilla – Bug 104317
df shows incorrect % full and available values.
Last modified: 2014-03-16 22:38:42 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20021003
Description of problem:
We have a NexSAN ataboy RAID connected to our RH 8 server. One of the partitions
(an EXT3 partition @ 961GB) reached 100% earlier this week. Since that time,
data has been removed from the partition (over 30GB).
when doing a df -k /export/imagery (the partition), df shows:
[root@loki root]# df /export/imagery/
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/Imagery/lvol1 961211736 916595968 0 100% /export/imagery
NOTE that used is not near the 961GB, yet it reads 'Available' at '0', and
'Use%' at '100%'.
I can add and remove files locally as normal, but the df counters don't change.
we are also having problems with NFS since this problem occured, where clients
(in particular Solaris 8) cannot write files larger than a few bites to the
What I've Done::
I have unexported the partition and unmounted it. --- Then remounted it, and
found the problem still there.
I then rebooted the machine, and the problem still exists.
I have attempted multiple times to fsck the partition, but it always tells me
that the partition is clean.
I have looked at tune2fs, and have been unable to find any options that might
help my situation.. Please advise.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. umount partition
2. remount partition
3. problem still exists.
1. reboot machine
2. when partition is mounted, problem still exists.
I have put this bug Severity as High, because I fear that, as this is a
filesystem problem, that it may lead to a partition data loss, or other
extremely bad things.
OUTPUT OF 'tune2fs -l /dev/Imagery/lvol1'
[root@loki root]# tune2fs -l /dev/Imagery/lvol1
tune2fs 1.27 (8-Mar-2002)
Filesystem volume name: <none>
Last mounted on: <not available>
Filesystem UUID: e85c895a-de26-4dc0-81c7-36296f42cc35
Filesystem magic number: 0xEF53
Filesystem revision #: 1 (dynamic)
Filesystem features: has_journal filetype needs_recovery sparse_super
Filesystem state: clean
Errors behavior: Continue
Filesystem OS type: Linux
Inode count: 122077184
Block count: 244133888
Reserved block count: 12206694
Free blocks: 11153942
Free inodes: 121931155
First block: 0
Block size: 4096
Fragment size: 4096
Blocks per group: 32768
Fragments per group: 32768
Inodes per group: 16384
Inode blocks per group: 512
Last mount time: Thu Sep 11 14:49:26 2003
Last write time: Thu Sep 11 14:49:26 2003
Mount count: 17
Maximum mount count: 37
Last checked: Tue Aug 26 09:40:42 2003
Check interval: 15552000 (6 months)
Next check after: Sun Feb 22 08:40:42 2004
Reserved blocks uid: 0 (user root)
Reserved blocks gid: 0 (group root)
First inode: 11
Inode size: 128
Journal UUID: <none>
Journal inode: 8
Journal device: 0x0000
First orphan inode: 0
The % is % available to normal users. Since 5% is reserved for the superuser
only, you still need to remove about 30GB (if I'm reading it right) for it to
show as < 100% full.
You can change the reserved percentage with tune2fs -m .