Path: utzoo!utgpu!watmath!clyde!att!ulysses!andante!alice!debra
From: debra@alice.UUCP (Paul De Bra)
Newsgroups: comp.unix.wizards
Subject: Re: minimal loss of information when deallocating inodes?
Message-ID: <8601@alice.UUCP>
Date: 25 Dec 88 16:59:38 GMT
References: <88Dec24.170417est.38019@neat.ai.toronto.edu>
Reply-To: debra@alice.UUCP ()
Organization: AT&T, Bell Labs
Lines: 30

In article <88Dec24.170417est.38019@neat.ai.toronto.edu> rayan@ai.toronto.edu (Rayan Zachariassen) writes:
]One of the filesystems on an ``unsupported'' machine lost all user files by
](the equivalent of) rm -r done automatically by a script late at night.
]...
]...  Dragging out my
]inode-list walker routine, it turns out that all deallocated inodes have
]null mode, size, nlink, and db[] fields.  The latter is the real killer,
]since without the disk block information, the old inode is useless.  Knowing
]the size would be pretty helpful too, depending on the contents of db[].
]
]I'd think that a zero nlink field should be enough to mark the inode as
]deallocated.  I can imagine robustness (i.e. paranoid) reasons for zeroing
]out the other fields, but is it *really* necessary?  If they aren't zeroed
]out, the information can be used to reconstruct removed files as long as the
]various blocks haven't been stomped on.
]

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.
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.

Paul.
-- 
------------------------------------------------------
|debra@research.att.com   | uunet!research!debra     |
------------------------------------------------------