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

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



No-one out there who can give me any tips for this? 

(Then the space to do experiments will finally be used in other ways.
And I hope this mail won't be consired to impolite...)


On Mon, 6 Dec 2004 15:23:15 +0100
Milan Holz?pfel <lists at mjh.name> wrote:
> 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)

iD8DBQFB3vSw2wyvT2WDeWYRAjP3AJ9wfozwRdvaVznkCJSYluJ1V3rjaQCdEv2B
dom+NWb23om5l0lXh8n6250=rGlQ
-----END PGP SIGNATURE-----

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

Milan Holz?pfel schrieb:
>>>
>>>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
so, you did "fsck -y" and after this the fs still had unfixable
errors?
is there anything useful in the kernel logs, maybe hardware errors? (disk,
cables, controller, memory, power)

- --
BOFH excuse #299:

The data on your hard drive is out of balance.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFB3zs3C/PVm5+NVoYRAgLRAKDLhT79uzvhX3EP6aEGn6twAZaZ8wCgvgYR
Lz6ypMFGGr6IIjQ9UdpUDgo=YgAc
-----END PGP SIGNATURE-----