minimal loss of information when deallocating inodes?

[Rayan Zachariassen]

In article <8601 at alice.UUCP> debra at 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