Date: Tue, 27 Apr 1999 09:35:58 +0930 (CST) From: Mark Newton <newton@internode.com.au> To: ayk1@ukc.ac.uk (Alex) Cc: dwhite@resnet.uoregon.edu, freebsd-current@FreeBSD.ORG Subject: Re: file disappeared? Message-ID: <199904270005.JAA01079@gizmo.internode.com.au> In-Reply-To: <Pine.SV4.3.95.990426192609.17876C-100000@ash.ukc.ac.uk> from "Alex" at Apr 26, 99 07:44:17 pm
next in thread | previous in thread | raw e-mail | index | archive | help
Alex wrote: > > > pcayk:~/tmp$ rm bigcdimage.iso > > > pcayk:~/tmp$ df -k . > > > Filesystem 1K-blocks Used Avail Capacity Mounted on > > > /dev/wd0s1f 7621844 6975669 36428 99% /usr > > > How on earth did that happen?!!! > > > > Are you running soft updates? It takes ~30s for changes to take effect if > > you are. I noticed this myself last week. > > I believe not - doesn't that involve adding a "SOFTUPDATES" option to the > kernel? I don't have that in my kernel; therefore, disc access should be > synchronous by default, right? And it had definitely been longer than 30s > before I decided to run fsck (or before the first run completed). Ok, something has the file open then - storage is not freed until the last reference to the file disappears. This is so that you can rm a file on a multitasking system without making processes that might be using the file at the time fall over and die (for a similar effect, try "rm /var/log/messages" -- You'll note that storage for the file isn't freed until you kill syslogd; in fact, if you generage log messages the file will "grow" and consume more space even though it doesn't have a directory entry. An application might have the file open; Alternatively, since it's a disk image which I presume you've been testing, you could have it attached to a vn device; if that's the case, something like "vnconfig -u /dev/vn0" will detach it, close the last reference to the file, and free the associated storage. Finally, it's possible that there was a hard link to the file. Given that fsck bitched about it being an unref'ed file that's probably unlikely, but the fact stil remains that hardlinks are a legitimate reason for storage to remain allocated after you've deleted something: Once again, the file isn't really deleted until the last reference to it disappears. > Perhaps someone with an in-depth knowledge of ufs can tell me what really > happened (and what exactly did fsck do to my drive, just to make things > worse.) No need for an in-depth knowledge of UFS; this is standard UNIX behaviour, regardless of the underlying filesystem. - mark ---- Mark Newton Email: newton@internode.com.au (W) Network Engineer Email: newton@atdot.dotat.org (H) Internode Systems Pty Ltd Desk: +61-8-82232999 "Network Man" - Anagram of "Mark Newton" Mobile: +61-416-202-223 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199904270005.JAA01079>