On Wed, 2006-10-11 at 10:57 +0200, [EMAIL PROTECTED] wrote:
> I have now implemented a simple "extent-extractor". It uses modified
> versions of the functions that display the xads in debugfs_jfs. An inode
> scanner tries to check all 512b-blocks weather they are sane inodes or
> not. It is currently overly simplified, it only checks:
> ((ino_ptr->di_ixpxd.len==4) && (ino_ptr->di_fileset==16))
You should probably verify di_nlink > 0 and (di_mode & IFMT) == IFREG.
> It does seem to work quite well. I have extracted a few very fragmented
> files and their checksums match the originals. As I used this box as a pvr
> backend I have a few hundred Gb in really large files.
>
> It is really slow. It scans and extracts a few Gb an hour. According to
> the profiler it stays around 80% in fwrite, so i might blame it on the
> slow USB-storage I use for the recovered files. The inode scanner might be
> optimized if one stored ranges that were taken up by file extents that one
> had encountered. When the scanner found a range that had been saved as a
> file extent, then it could skip to the end of that range. If one would use
> that technique then the extents have to be validated to assure that an
> illegal extent does not make the scanner skip interesting blocks.
>
> The original routines from debugfs_jfs detected that my superblocks were
> OK, but of course they were not. For instance the aggregate block size
> extracted from the superblock was illegal (178323 or something like that).
> I forced the block size to 4096b. It may or may not be feasable with a
> more robust check in debugfs_jfs that checks that the blocksize is valid
> and 1<<l2bs == blocksize.
For your purposes, you may not want to look at the superblock at all.
Just assume a blocksize of 4096, because that's the only supported block
size anyway.
> The program occasionally encounters invalid XADs or detects invalid inodes
> as valid ones. This causes the program to jump around on invalid XADs,
> which will take a while, and might create very large files. I need a way
> to detect if a xad is valid. The only sanity check i can think of is to
> check that offset and length is less than the aggregate size. Any ideas?
The xad's for a file shouldn't overlap and should be ordered as you
traverse the tree. Verifying that the inode is valid (as I stated
above) should help.
> When I got this inode-scan-and-extent-walk-kind-of-program working I will
> try to also parse directory inodes for filenames. I think I might need to
> do it in two steps. Probably the simples way would be to scan for
> directory inodes and then create a directory structure on the
> 'to'-filesystem. Then you scan for file inodes and place them in the
> directory structure. I see two main problems. The directory inode scan
> will need a fairly advanced data structure, that can rearrange a directory
> tree when new data is found. Another is what to do with items whos path is
> not fully discovered.
struct dir {
struct dir *first_child; /* first member of the directory */
struct dir *next_sibling; /* next directory belonging to the same
parent */
...
}
Create a lost+found directory, just like fsck does, that contains any
inodes that aren't found in the hierarchy. You can name the files by
their inode numbers.
>
> Best regards,
> Simon
>
>
>
>
>
>
>
--
David Kleikamp
IBM Linux Technology Center
-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Jfs-discussion mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/jfs-discussion
