These are great suggestions, thank you everyone.
Matt On Tue, 14 Dec 2004 07:56:16 -0600, Dave Kleikamp <[EMAIL PROTECTED]> 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. > > Shaggy > -- > David Kleikamp > IBM Linux Technology Center > > _______________________________________________ Jfs-discussion mailing list [EMAIL PROTECTED] http://www-124.ibm.com/developerworks/oss/mailman/listinfo/jfs-discussion
