reclaiming /var capacity?

[jamgill]

On Wed, Mar 11, 2009 at 3:57 PM, Jonathan Chen <jonc at chen.org.nz> wrote:

> On Wed, Mar 11, 2009 at 03:23:50PM -0400, jamgill wrote:
> > On Wed, Mar 11, 2009 at 3:04 PM, Yuri Pankov <yuri.pankov at gmail.com>
> wrote:
> >
> > > On Wed, Mar 11, 2009 at 02:30:08PM -0400, j. wrote:
> > > > Where did my capacity go and how can I get it back?
> > > >
> > > > deathray# du -sh /var
> > > >  70M    /var
> > > >
> > > >
> > > > deathray# df -h /var
> > > > Filesystem    Size    Used   Avail Capacity  Mounted on
> > > > /dev/da0d     248M    214M     15M    94%    /var
> > > >
> > > >
> > > > Thanks,
> > > >
> > > > --j.
> > >
> > > http://www.freebsd.org/doc/en/books/faq/disks.html#DU-VS-DF
> > >
> > >
> >
> > Thanks, Yuri.   According to the FAQ you linked, wouldn't a good
> smattering
> > of "sync ; sync ; sync ; sync ; sync" cause the the two to reflect the
> sizes
> > accurately?
>
> This will do nothing if a process has an open file descriptor on a
> deleted file. Use fstat(1) or lsof to help hunt down the offending
> process.


Thanks for the reply.   This helped me solve my problem.

fstat /var didn't show me anything interesting, but fstat -v var did
indicate a bunch of "cant read vnode at 0x0 for pid ..."  so i installed
lsof and saw that httpd and mysqld had a lot more open files than I
expected, and several of those were not open to a specific file but to /var
(/dev/da0d) ... after restarting the services (i cheated, I rebooted) the
space reported by du and df are now much closer.

And, importantly, postfix knows it has some room to do its thing in the /var
partition.

Thanks again.



>
> --
> Jonathan Chen <jonc at chen.org.nz>
> ----------------------------------------------------------------------
>                                             When all else fails, RTFM
>



-- 
"Build a man a fire, he'll be warm for a night... set a man on fire, he will
be warm for the rest of his life"