From owner-freebsd-current Mon Apr 26 17: 7:21 1999 Delivered-To: freebsd-current@freebsd.org Received: from gizmo.internode.com.au (gizmo.internode.com.au [192.83.231.115]) by hub.freebsd.org (Postfix) with ESMTP id B53661539B for ; Mon, 26 Apr 1999 17:07:17 -0700 (PDT) (envelope-from newton@gizmo.internode.com.au) Received: (from newton@localhost) by gizmo.internode.com.au (8.9.3/8.9.3) id JAA01079; Tue, 27 Apr 1999 09:35:58 +0930 (CST) (envelope-from newton) From: Mark Newton Message-Id: <199904270005.JAA01079@gizmo.internode.com.au> Subject: Re: file disappeared? To: ayk1@ukc.ac.uk (Alex) Date: Tue, 27 Apr 1999 09:35:58 +0930 (CST) Cc: dwhite@resnet.uoregon.edu, freebsd-current@FreeBSD.ORG In-Reply-To: from "Alex" at Apr 26, 99 07:44:17 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG 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