Date: Tue, 04 May 2010 01:35:24 -0700 From: perryh@pluto.rain.com To: antoniok.spb@gmail.com Cc: freebsd-questions@freebsd.org Subject: Re: Strange diskspace loss Message-ID: <4bdfdc4c.7uW1NWZG0Ilec22I%perryh@pluto.rain.com> In-Reply-To: <x2z3f1c29e71005032304rf7190596o7dcf0b5dd8be0bc3@mail.gmail.com> References: <x2z3f1c29e71005032304rf7190596o7dcf0b5dd8be0bc3@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
<antoniok.spb@gmail.com> wrote: > And the fsck: > > # fsck ... > ** /dev/aacdu0s1e (NO WRITE) > ** Last Mounted on /var > ** Phase 1 - Check Blocks and Sizes > ** Phase 2 - Check Pathnames > ** Phase 3 - Check Connectivity > ** Phase 4 - Check Reference Counts > UNREF FILE I=23587 OWNER=root > MODE=100644 > SIZE=0 MTIME=Apr 9 13:36 > 2010 > CLEAR? > no > > UNREF FILE I=3156011 OWNER=root MODE=100644 > SIZE=6944766 MTIME=May 4 04:34 2010 > CLEAR? no > > UNREF FILE I=3179521 OWNER=www MODE=100644 > SIZE=30361665474 MTIME=May 4 09:43 2010 ^^^^^^^^^^^^^^^^ > CLEAR? no There's at least part of your problem: 30GB that du can't see because it isn't linked to by any directory entry. Something associated with your web server has created a large scratch file, which it still has open (and thus the space can't be reclaimed), but it unlinked the file after creating it so that it would automatically go away once the process dies. This sort of thing -- though seldom so large as this -- is not at all uncommon in /tmp. It's less common, but (as in this case) not unheard of, in /var/tmp.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4bdfdc4c.7uW1NWZG0Ilec22I%perryh>