Date: Fri, 17 Nov 2000 02:02:27 -0600 (CST) From: Mike Meyer <mwm@mired.org> To: Mark Garcia <markg@go2net.com> Cc: questions@freebsd.org, Chris Jesseman <whacker@sitemajic.net> Subject: Re: du -df inconsistency - get fsck to fix? Message-ID: <14868.58899.725688.621883@guru.mired.org> In-Reply-To: <Pine.LNX.3.96.1001116233208.12295A-100000@skritz.go2net.com> References: <14868.56914.94548.607710@guru.mired.org> <Pine.LNX.3.96.1001116233208.12295A-100000@skritz.go2net.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Mark Garcia <markg@go2net.com> types: > On Fri, 17 Nov 2000, Mike Meyer wrote: > > Mark Garcia <markg@skritz.go2net.com> types: > > > On Fri, 17 Nov 2000, Mike Meyer wrote: > > No, restarting a server that has an open log file filling a partition > > isn't an arcane way of handling this, it's SOP. The kernel isn't > > involved at all, except that once the file closes, it will notice > > there are no longer any links to it, and free the disk space. > > The problem with your solution is that - if I've diagnosed the problem > > correctly - you won't be able to unmount the disk until the file is > True in most cases. But, you can still have a kernel pointer to a memory > allocation associated with what _was_ the space taken by the pre-existing > filehandle. The unmounting of a file system will be stopped if there is a > _link_ from a process to a file. By him removing that link, the kernel > has lost the pointer of the process to that allocated space. The process > can no longer communicate to the kernel to tell it to clear the pointer. > And the kernel will hold in memory that reference to the space. The disk > can be unmounted in this case. Sounds like you've just described what happens if he manages to clear the inode with the file system mounted - which his log doesn't show happening. > > closed anyway. At which time, the problem is fixed, so why bother > > going through all that extra work? > I've experienced this alot. Usually from a program ie. qmail, which is > trying to handle some 50mb file that someone sent, and it tries to > deliver it, but qmail-remote barfs a horrible death, and the kernel still > thinks there is a 50mb file... this happens a couple of times and the disk > runs out of space... when a 'du' reflects that there is only 2% used. > There is no link anymore of a process with a filehandle open, but the > allocated space was never cleaned up from the crashing qmail process. I > guess you can say a memory leak. But this is the case... an umount met > with success, fscking smacked the fs in shape, and the kernel cleared > itself (some garbage collecting) and the space came back in a blink of an > eye... Actually, that sounds like a kernel bug. Have you pr'ed it? <mike > > <mike > > > > > Thanks much you guys help! > > > > > Chris Jesseman > > > > > > > > > > > > Well, "optimal" depends on your goals. Looks like you've got a server > > > > > > log file you rm'ed from the file system, but the server is still > > > > > > logging to it. You need to convince the server to close the log file, > > > > > > which will cause it to be removed from the disk. If worst comes to > > > > > > worst, doing a shutdown and reboot will solve the problem. > > > > > > > > > > > > <mike > > > > > > > > > > > > > > > > > > > > > > > > Thank you, > > > > > > > Chris Jesseman > > > > > > > > > > > > > > [0] /var#fsck /dev/da0s1e > > > > > > > ** /dev/da0s1e (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=94 OWNER=root MODE=100644 > > > > > > > SIZE=18173952 MTIME=Nov 15 22:09 2000 > > > > > > > CLEAR? no > > > > > > > > > > > > > > ** Phase 5 - Check Cyl groups > > > > > > > 55 files, 17867 used, 1948 free (108 frags, 230 blocks, 0.5% > > > > > > fragmentation) > > > > > > > > > > > > > > > > > > > > > Misc. info from my 4.1.1 Stable box: > > > > > > > > > > > > > > [0] /var#fsck -p /dev/da0s1e > > > > > > > /dev/da0s1e: NO WRITE ACCESS > > > > > > > /dev/da0s1e: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY. > > > > > > > > > > > > > > [8] /var#cat /etc/fstab > > > > > > > # Device Mountpoint FStype Options Dump > > > > > > Pass# > > > > > > > /dev/da0s1e /var ufs rw 2 > > > > > > 2 > > > > > > > > > > > > > > [0] /var#mount > > > > > > > /dev/da0s1e on /var (ufs, local, writes: sync 1486005 async 715463, > > > > > > reads: sync > > > > > > > 20046 async 6527) > > > > > > > > > > > > > > [0] /var#du -h /var > > > > > > > 1.0K /var/at/jobs > > > > > > > 1.0K /var/at/spool > > > > > > > 3.0K /var/at > > > > > > > 2.0K /var/crash > > > > > > > 4.0K /var/cron/tabs > > > > > > > 5.0K /var/cron > > > > > > > 2.0K /var/msgs > > > > > > > 1.0K /var/preserve > > > > > > > 52K /var/run > > > > > > > 1.0K /var/rwho > > > > > > > 1.0K /var/tmp/vi.recover > > > > > > > 3.0K /var/tmp > > > > > > > 20K /var/yp > > > > > > > 1.0K /var/pwcheck > > > > > > > 91K /var > > > > > > > [0] /var#df -H > > > > > > > Filesystem Size Used Avail Capacity Mounted on > > > > > > > /dev/da0s1e 20M 18M 372K 98% /var > > > > > > > > > > > > > > > > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > > > > > > with "unsubscribe freebsd-questions" in the body of the message > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > > > with "unsubscribe freebsd-questions" in the body of the message > > > > > > > > > > > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > with "unsubscribe freebsd-questions" in the body of the message > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-questions" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?14868.58899.725688.621883>