Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 6 Feb 2001 19:26:56 +0200
From:      Panagiotis Astithas <past@netmode.ntua.gr>
To:        stable@freebsd.org
Subject:   df output incosistency
Message-ID:  <20010206192656.B6939@netmode.ece.ntua.gr>

next in thread | raw e-mail | index | archive | help
Running df on my laptop with softupdates enabled, produces the 
following output:

Filesystem  1K-blocks     Used    Avail Capacity  Mounted on
/dev/ad0s1a     99183    43709    47540    48%    /
/dev/ad0s1e   2750654  2112356   418246    83%    /usr
procfs              4        4        0   100%    /proc

As you can see there is a difference between the total number 
of blocks and the sum of used+available blocks. Particularly
in the case of /usr there are more than 200MB "lost". Now,
this came up while I was building a large port and erasing a
very large file, about the size of the lost space. In the process
the filesystem became full, and I had to stop the rm process,
stop the build, reboot and fsck the disks (which did find errors). 
After that df always reported the mismatch you can see above. At
that time the system was 4.2-STABLE as of early December IIRC, so
I suspected a bug in df or ufs or softupdates and I upgraded the
system, to no avail. I have since used the system as usual, with 
the only remarkable exception that a few times when I exceeded the
available disk space (as indicated by df), the operations continued 
without a problem, although df reported a negative available space.

My question is, can I reclaim the apparently lost space without 
using newfs? Is df lying and I can safely ignore the available 
space reading, or doing so will corrupt my filesystem even worse?

Any help on this would be highly appreciated, since I will not be
able to newfs my drive for a few months.

Regards,

-past


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-stable" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010206192656.B6939>