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>