2004-Dec-06 14:23 UTC
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-----
Maybe Matching Threads
- Re: 135 GB ext3 on broken drive -- other possibilities than "e2fsck -y"?
- gentoo as dom0 on xen fails...
- Sharing Partitions between Linux and Windows
- Formating and Mounting Partitions giving problems
- Re: [long] major problems on fs; e2fsck running out of memory