Ext3 users - Dec 2004 - 135 GB ext3 on broken drive -- other possibilities than "e2fsck -y"?

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hello,

I got an IDE-drive which decided to get broken.  Part of the extended
partition table was lost, but I was able to recover it, so I could reach
the ext3 filesystem with a size of about 135 GB.  I made a copy of it
(luckily the ISP doesn't seem to need the broken drive urgently hehe) and
ran fsck on that copy.

The first time I ran fsck I had the partition table slightly changed so
I could reach the XFS fs which comes after the ext3 partition on the
disk, which made the ext3 slightly smaller, so fsck complained and I
tried to fiddle around with modding fsck's questions somehow.  This
resultet in about 2.8 GB of data (there were > 10 GB of data before.
Most importantly some tars which are sizes around 4 GB.)

Next time I gave the block device the size which the superblock said the
FS had before, and I used fsck.ext3 with the -y option.  Then I got 3 GB
of data, and not all of it was in lost+found (like it was with the first
attempt.)  Much got into lost+found though, and obviously, much didn't
make it back into the fs.

Since I still have the broken drive (and just as important, enough free
space on another drive) available for the next few days:  Is there
anything more I can try?  (Espacially to find one of the more recent
large tars. They have obviously been at the wrong place in the wrong
time, but that's another story.)

TO these big files of 1+ GB:  If I take an ext3 fs of 130 GB with 100+ GB 
free space, can you estimate the chance of files copied with cp from
another drive getting allocated continously?  Or is this possible with
ext3 at all?  How big is the chance of continous allocation if these
files are read from another drive, but then sent trough bzip2, with the
output being written?  Or if I use tar to create this file with the
contents read from the same filesystem?  (I just though I'd ask these
too in case anyone can tell that searing for the beginning of one of
these files may well be worth the effort.)

Here some more details on the fsck process:  Amongst others, I got a lot of
these messages:

| Deleted inode 8618118 has zero dtime.  Fix<y>?

| Special (device/socket/fifo/symlink) file (inode 14646819) has immutable
| or append-only flag set.  Clear<y>?

| Special (device/socket/fifo) inode 14679587 has non-zero size.  Fix<y>?

| Inode 16187144 was part of the orphaned inode list.  FIXED.

| Inode 16187146 is in use, but has dtime set.  <prompt>

| Inode 16187364 has imagic flag set.  <prompt>

| Inode 16187340 has compression flag set on filesystem without compression
support.  <prompt>

| Inode 16187340 has INDEX_FL flag set but is not a directory.  <prompt>

| Inode 16187340, i_size is 5912753600013104432, should be 0.  <prompt>

| Inode 16187340, i_blocks is 2042526010, should be 0.  <prompt>

| Inode 16187020 has illegal block(s).  <prompt>
| Illegal block #0 (2315255807) in inode 16187020.  CLEARED.
| Illegal block #1 (4094814513) in inode 16187020.  CLEARED.
| Illegal block #2 (3179347967) in inode 16187020.  CLEARED.
| Illegal block #3 (4294967135) in inode 16187020.  CLEARED.
| Illegal block #4 (3218371584) in inode 16187020.  CLEARED.
| Illegal block #6 (4284530057) in inode 16187020.  CLEARED.
| Illegal block #7 (2106327039) in inode 16187020.  CLEARED.
| Illegal block #8 (1962902940) in inode 16187020.  CLEARED.
| Illegal block #9 (1421708237) in inode 16187020.  CLEARED.
| Illegal block #10 (2248146943) in inode 16187020.  CLEARED.
| Illegal block #11 (2344842495) in inode 16187020.  CLEARED.
| Too many illegal blocks in inode 16187020.  <prompt>

And after my second fsck attempt, every further fsck does this:

| linux root # fsck.ext3 /dev/hdc8 -y
| e2fsck 1.35 (28-Feb-2004)
| /dev/hdc8 contains a file system with errors, check forced.
| Pass 1: Checking inodes, blocks, and sizes
| Pass 2: Checking directory structure
| Pass 3: Checking directory connectivity
| '..' in /lost+found/#12713448 (12713448) is <The NULL inode>
(0), should be /lost+found (7208985).
| Fix? yes
| 
| Couldn't fix parent of inode 12713448: Couldn't find parent directory
entry
| 
| Pass 4: Checking reference counts
| Pass 5: Checking group summary information
| 
| /dev/hdc8: ********** WARNING: Filesystem still has errors **********
| 
| /dev/hdc8: 86053/16990208 files (2.7% non-contiguous), 1320442/33975459 blocks
| linux root #

Maybe these details can help you tell me whether there's any hope to
find any further data on the drive.  

TIA for any help
Milan Holz?pfel

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)

iD8DBQFBtGtT2wyvT2WDeWYRAo5BAJ4lG+pYMUyfKm9LMkz+vnPmgpTHmgCfdl4u
aokTS8KDGLsvmQr4C25elDU=r9D4
-----END PGP SIGNATURE-----