Incorrect df -k output??

[Newtunes Support]

Peter,

I have resolved this issue using forsed unmount (umount -f /var)
And after I mounted /var again df -k shows me correct value.

But I have new problem.
fsck -y does not fix anything.


** Last Mounted on /var
** Phase 1 - Check Blocks and Sizes
INCORRECT BLOCK COUNT I=188426 (162368 should be 160704)
CORRECT? no

INCORRECT BLOCK COUNT I=188434 (226368 should be 226304)
CORRECT? no

INCORRECT BLOCK COUNT I=188454 (29888 should be 29568)
CORRECT? no

INCORRECT BLOCK COUNT I=188474 (20096 should be 20064)
CORRECT? no

** Phase 2 - Check Pathnames
** Phase 3 - Check Connectivity
** Phase 4 - Check Reference Counts
UNREF FILE I=353283  OWNER=mysql MODE=100600
SIZE=0 MTIME=May  8 18:11 2007
CLEAR? no

UNREF FILE I=353284  OWNER=mysql MODE=100600
SIZE=0 MTIME=May  8 18:11 2007
CLEAR? no

UNREF FILE I=353286  OWNER=mysql MODE=100600
SIZE=0 MTIME=May  8 18:11 2007
CLEAR? no

UNREF FILE I=353289  OWNER=mysql MODE=100600
SIZE=0 MTIME=May  8 18:11 2007
CLEAR? no

UNREF FILE I=353290  OWNER=mysql MODE=100600
SIZE=0 MTIME=May  8 18:11 2007
CLEAR? no

** Phase 5 - Check Cyl groups
FREE BLK COUNT(S) WRONG IN SUPERBLK
SALVAGE? no

SUMMARY INFORMATION BAD
SALVAGE? no

BLK(S) MISSING IN BIT MAPS
SALVAGE? no

Any ideas?
2007/5/8, Peter Jeremy <peterjeremy at optushome.com.au>:
>
> On 2007-May-08 13:04:55 +0400, Hanatsu Tori <hanatsu.tori at gmail.com>
> wrote:
> >xxxxx# df -k
> >Filesystem  1K-blocks     Used    Avail Capacity  Mounted on
> >/dev/ad4s1a  76866422 51507978 19209132    73%    /
> >devfs               1        1        0   100%    /dev
> >*/dev/ad6s1d  77879478 75006042 -3356922   105%
> /usr/home/ftp/pub/ARCHIEVE*
> >
> >
> >xxxxx# du -sk /usr/home/ftp/pub/ARCHIEVE
> >*75006042        /usr/home/ftp/pub/ARCHIEVE*
>
> df reports 75006042KB used and du reports 75006042KB used.  Where is
> the problem?
>
> >xxxxx# df -h
> >Filesystem     Size    Used   Avail Capacity  Mounted on
> >/dev/ad0s1a    496M     36M    420M     8%    /
> >devfs          1.0K    1.0K      0B   100%    /dev
> >/dev/ad0s1d    1.9G    425M    1.4G    23%    /tmp
> >/dev/ad0s1f    136G     70G     55G    56%    /usr
> >*/dev/ad0s1e    3.9G    3.6G    -21M   101%    /var
> >*/dev/ad2s1d    144G     25G    108G    19%    /hd2
> >procfs         4.0K    4.0K      0B   100%    /proc
> >
> >xxxxx# du -sh /var
> >*202M    /var*
>
> This is a bit less obvious - there does appear 3.4GB missing.  I'll
> make the assumption that the 'df' output is complete (ie there isn't
> another filesystem mounted over part of /var) and neither figure is
> misleading (ie there isn't whitespace in either name and no chrooting
> or jails are in use).
>
> The remaining possibilities are:
> a) A running process has an unlinked file open.
>   The space will be released when the process closes the file.
> b) Filesystem snapshots exist.
>   Use snapinfo(8) to check and "rm" them if appropriate
> c) A combination of UFS and/or fsck bugs and system crashes have lost
> space.
>   Shutdown or reboot to single user mode and explicity fsck /var.
>
> Since you have already bounced the server, it is unlikely to be option
> a (unless the same process has just grabbed the space again).
>
> --
> Peter Jeremy
>
>