-----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@xxxxxxxx> 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----- _______________________________________________ Ext3-users@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/ext3-users
