135 GB ext3 on broken drive -- other possibilities than "e2fsck -y"?
Milan Holzäpfel
lists at mjh.name
Fri Jan 7 20:44:32 UTC 2005
-----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-----
More information about the Ext3-users
mailing list