Slashdot Mirror

← Back to Stories (view on slashdot.org)

Correcting ext3 File Corruption?

Posted by Cliff on from the has-anyone-else-seen-this-before dept.

An anonymous reader asks: "I am looking for ext2/ext3 expert. I have a small file (1395 bytes) that appears HUGE when runing ls -l (70368744179059 bytes [yes, that's 70 terabytes]). This causes a problem because tar wants to back up all those extra bytes. We have back ups of the file else where, but I'm afraid to delete it. When I remove it what is going to happen to the file system (Kernal version is 2.4.18 on i686). This seems to be a pretty bad math error on the part of the file system. This is a really weird error, but could just be the issue of a corrupted sector on the drive. Has anyone else seen this before and have any ideas as to whether such files can be recovered? Is this problem just a small glitch or an omen of an impending filesystem crash?

"Here's what the files look like on the system:

[ root@secure parse]# ls -l HTMLFrameSet.class
-rw-rw-r-- 1 root devel 70368744179059 Mar 20 09:05 HTMLFrameSet.class

[root@secure parse]# wc HTMLFrameSet.class
15 58 1395 HTMLFrameSet.class
...and the error message from tar:
tar: HTMLFrameSet.class: File shrank by 70368744169331 bytes; padding with zeros
No wonder my backups didn't finish! :-)"

9 of 74 comments (clear)

  1. fsck by SpatchMonkey · · Score: 1, Informative

    Does the fsck.ext3 program help at all?

  2. And when you run "fsck"? by Zocalo · · Score: 5, Informative
    Since EXT3 is just EXT2 with a journal tacked on, there is no reason why you can't run the EXT2 fsck utility accross it in the normal way. You are obviously worried about loosing the entire file system, so you probably want to start by running fsck with the verbose (-V) and interactive (-r) options to see exactly what is going on and have the ability to prevent unwanted changes being made.

    Since you appear to use tar for backups, you could also backup the affected filesystem using the exclude (-X [filename]) option first, which might be a *really* good idea. ;)

    --
    UNIX? They're not even circumcised! Savages!
    1. Re: And when you run "fsck"? by Omniscient+Ferret · · Score: 2, Informative

      I'd like to add two things:
      You can backup the drive image too, so if the file is irreplaceable and corrupted, you can try more than one recovery method safely.
      Also, to fsck /, "touch /forcefsck" and reboot.

    2. Re:And when you run "fsck"? by Linux_ho · · Score: 3, Informative

      I'd like to add that fsck is ext3-aware. If the journal looks OK, it might not actually check the filesystem unless you tack on the -f option to force the issue.

      --
      include $sig;
      1;
  3. Before you try to recover.... by bartjan · · Score: 2, Informative

    Make a copy of the /dev device itself, if you have the space for that on another partion.
    Then use that backup-file to try out whatever other posters here suggest.

  4. Sparse file? by Tony-A · · Score: 3, Informative

    from man tar
    -S, --sparse
    handle sparse files efficiently

    I'm not really familiar with them, but haven't seen any other mention here.
    I know it's possible to put a file on a floppy that won't fit on your hard drive.

  5. This is a sparse file.... by weave · · Score: 5, Informative
    It has holes in it. We once ran a medical package 10 years ago that did this on purpose. A 40 gig file took about 4 megs on disk.

    This is easy to simulate by writing a small program that scribbes a few bytes to offset zero, then does an fseek out to some insane high offset, then scribble a few bytes there. Close, do an ls, see the huge file, but then note it only takes the space of two blocks on your file system. Imagine the fun you can have with this trick at parties!

    Every UNIX file system I've ever dealt with handles this the same way.

    tar and other programs should have switches to deal with sparse files correctly.

    If you're concerned about what's in it, cat it to od. I believe od is smart enough to collapse zero blocks in its display. That way you can see if there is any real data at some pointer far into the file.

    If this is a commercial closed-source package where you can't verify what it's doing, I'd strongly suggest leaving it alone and contacting vendor to see if this behavior is normal.

    1. Re:This is a sparse file.... by n9hmg · · Score: 2, Informative

      He demonstrated that it was not a sparse file, by using the wc command on it. A sparse file treats all the empty space as nulls on reading, so he would have gotten the big size if it were sparse. It's a single-bit error, probably bad media that got past the ECC on the drive, but maybe just a plain corruption. I'd suggest copying it somewhere safe and running an fsck, if you can afford the downtime.

  6. Try the mailing list by Outland+Traveller · · Score: 5, Informative

    Why don't you try the ext3 mailing list instead of Ask Slashdot? I lurk on the list and I've seen a number of questions extremely similar to yours, with answers. The list gurus will even help you track down the problem.

    https://listman.redhat.com/pipermail/ext3-users/20 02-July/thread.html#383