Newsgroups: comp.unix.wizards
Path: utzoo!utgpu!jarvis.csri.toronto.edu!neat.ai.toronto.edu!rayan
From: rayan@ai.toronto.edu (Rayan Zachariassen)
Subject: Re: minimal loss of information when deallocating inodes?
Message-ID: <88Dec26.142447est.38031@neat.ai.toronto.edu>
Organization: Department of Computer Science, University of Toronto
References: <8601@alice.UUCP> <88Dec24.170417est.38019@neat.ai.toronto.edu>
Date: Mon, 26 Dec 88 14:24:33 EST

In article <8601@alice.UUCP> debra@alice.UUCP writes:
# I don't recall the previous discussion on this, but a zero nlink field only
# means that there are no directory entries pointing to this inode. It is still
# possible that some processes are accessing the file. Should the system
# crash, fsck will then find a linkless file and reconnect it in lost+found.

Should the system crash, the file is no longer needed because the processes
that referred to it aren't around any more.  I thought about this a bit,
perhaps I don't believe in fsck as much as you do.  Lost+found is usually
useless in my experience (of course if you don't have backups you're
grateful for *any* files to show up there, but they're usually not the
ones you care about...).

# The disk blocks occupied by the file are not added to the freelist when
# a file has no more links. All relevant fields of the inode must be zeroed
# for fsck to know that the file is really gone.

Right, what is the minimal set of relevant fields?  Not adding the blocks
to the freelist on 0 link count is ok, it is done at last close.  However
if you run fsck on a filesystem with such inodes, why should it find or
check those files?  The whole point of having a file with no links is that
it will automatically disappear when the process dies (or is  "unfindable"
by curious admins).  It would be acceptable *in this context* to modify fsck
so it doesn't dig out such files.

Thanks.

rayan