Incorrect df -k output??

Newtunes Support ntstaff at gmail.com
Tue May 8 15:40:42 UTC 2007


Thanks a lot for irrefragable answer, Oliver!

I have resolved the issue on one server (there was a little overdraft) and
I'll try to resolve issue with fsck and /var when PROD will have lower load.

Thanks to all,
Dmitry


2007/5/8, Oliver Fromme <olli at lurza.secnetix.de>:
>
> Newtunes Support <ntstaff at gmail.com> wrote:
> > I have resolved this issue using forsed unmount (umount -f /var)
>
> Not a good idea.  It breaks all sorts of things.
>
> > And after I mounted /var again df -k shows me correct value.
>
> The value was correct before, too.  There probably were
> some files that were removed, but some processes still
> had them open.  du(1) doesn't see those files, so they're
> not included in the sum.  df(1) sees the allocated space,
> of course.
>
> It can happen on the /var file system if an error occurs
> during log file rotation, so the programs writing to the
> log files (e.g. syslogd) are not properly informed about
> the rotation, so they keep the old files open.
>
> A good way to view such files/processes is to use the
> command "lsof +L1" (lsof can be installed from the ports
> collection: /usr/ports/sysutils/lsof).  It lists all
> file descriptors in use that have a link count of zero.
>
> The correct way to resolve the issue is to find those
> processes and tell them to close the files (usually a
> "kill -HUP" will do that).  If everything else fails,
> kill the processes (use "kill -KILL" if necessary).
> Do not use "umount -f".
>
> > But I have new problem.
> > fsck -y does not fix anything.
>
> That only works when the file system is not mounted (or
> only mounted read-only).  It's usually done in single-
> user mode.
>
> (However, I assume that your file system doesn't need
> fsck, but it certainly wouldn't hurt either.)
>
> Best regards
>   Oliver
>
> --
> Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M.
> Handelsregister: Registergericht Muenchen, HRA 74606,  Geschäftsfuehrung:
> secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün-
> chen, HRB 125758,  Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart
>
> FreeBSD-Dienstleistungen, -Produkte und mehr:  http://www.secnetix.de/bsd
>
> "Python tricks" is a tough one, cuz the language is so clean. E.g.,
> C makes an art of confusing pointers with arrays and strings, which
> leads to lotsa neat pointer tricks; APL mistakes everything for an
> array, leading to neat one-liners; and Perl confuses everything
> period, making each line a joyous adventure <wink>.
>        -- Tim Peters
>


More information about the freebsd-stable mailing list