Date: Thu, 16 Nov 2000 23:20:17 -0800 (PST) From: Mark Garcia <markg@skritz.go2net.com> To: Mike Meyer <mwm@mired.org> Cc: Chris Jesseman <whacker@sitemajic.net>, questions@freebsd.org Subject: Re: du -df inconsistency - get fsck to fix? Message-ID: <Pine.LNX.3.96.1001116231438.12065D-100000@skritz.go2net.com> In-Reply-To: <14868.55554.177193.778788@guru.mired.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 17 Nov 2000, Mike Meyer wrote: > Chris Jesseman <whacker@sitemajic.net> types: > > I did have an open file but trashing it didn't help. I'm just curious if this > > is on a lower file system level or would restarting the offending logger > > release the space? I really don't want to reboot... > > What do you mean by "trashed"? Files aren't removed from the file > system until the last link to them is broken. Rm on a file just breaks > one link. If a process has an open file descriptor pointing at the > file, *that's* also a link - and the file won't go away until the > process closes the link. > > Stopping a processes closes all open files, so restarting a server > should work. I'd hope it work <snicker> Actually, restarting the server is an arcane way of handling this. Its probably the easiest and most intrusive way of telling the kernel to go stuff yourself and forget about what you were doing. Rather, you should umount the partition, run fsck -p on it, choose 'yes' to the appropriate inode to clear, and then remount. FYI, df is always correct. It asks the kernel what space is left. The kernel thinks that the space is not yet free. Even wiping the inode off, will not cure the problem, but over time, the kernel will be forced to recalculate the space on the machine. At this time, it will clean up some misguided memory allocations associated with the open file handle, and will dualy note that. du, just physically accesses the disk to find out how much physical space is available. Hope this helps. ->MAG > > <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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.LNX.3.96.1001116231438.12065D-100000>