These are great suggestions, thank you everyone.
On Tue, 14 Dec 2004 07:56:16 -0600, Dave Kleikamp <shaggy@...> wrote:
> On Tue, 2004-12-14 at 00:21 +0100, Knut Eckstein wrote:
> > Hello all,
> > >> 1) use the JFS journal to roll back all transactions past a certain time
> > >> index?
> > >
> > > It would be possible to do this in many cases, since a lot of the
> > > information you need can be reconstructed from the journal. It wouldn't be
> > > reliable in all cases, in that you would be able to reconstruct what disk
> > > blocks were allocated to a file, but I'm not how easily you could determine
> > > the logical file offset of these blocks. That information may still be
> > > available in the inode, but I'm not positive. I don't think there's any
> > > way to recover the size of the file (other than an estimate, based on where
> > > the last extent is).
> > IMHO, the logical offset of a disk block should be visible, since it is
> > part of struct xad_t and as such it should be possible to find it
> > in a journal entry that contains extent allocation changes in an inode.
> > That same entry should also hold the filesize, since it is a member
> > of struct jfs_inode.
> The journal will only contain the parts of the inode that have been
> modified, so it probably won't contain all of the xad entries, but as
> long as the inode was not re-used, this metadata is still intact in the
> inode. I was completely wrong when I stated below that the inode is
> truncated when it is deleted.
> > I'm saying 'should' because I have not examined those types of journal
> > entries yet. I've been focusing on directory entry journal items, see
> > below.
> > >> 2) alter the inodes of deleted files from "deleted" to "not-deleted"? (I
> > >> think this is how undelete utilities for other filesystems (such as ext2)
> > >> work.)
> > >
> > > The files are truncated as they are deleted, so only doing this would give
> > > you empty files (with no path to them). There might still be enough
> > > information in the inodes to reconstruct the xtree, but you'd have to
> > > determine the number of extents to try to recover, and wouldn't really have
> > > an accurate file size.
> > >From what I've seen with my JFS module for sleuthkit, the files are not really
> > truncated, but just marked as deleted, i.e. the file size and the full xtree
> > (including xtree parts not stored inside the inode) can be seen with the istat
> > tool. That means that once you know the inode of the deleted file you are
> > looking for (either by guessing or by looking at journal entries), you can use
> > icat to undelete that file, if the following three conditions are met:
> > 1. The inode you are looking for has not yet been reused
> > 2. "External" xtree blocks (in case they were required to
> > describe the exact allocation of that file on disk) have
> > not yet been overwritten
> > 3. The disk blocks containing the actual file have
> > not yet been
> > reused for another file or metadata.
> Yeah, thanks for correcting me. The "truncation" that is done at
> deletion time only marks the disk blocks as available. It doesn't alter
> the inode (other than di_nlink) or xtree structure.
> Thank you, Knut. I haven't read your paper yet, but I will.
> David Kleikamp
> IBM Linux Technology Center