[Bug 83982] Deleting large files corrupts EXT3 file system

rvjcallanan vincent at callanan.ie
Thu Feb 8 15:39:54 UTC 2007


Public bug reported:

This is a VERY SERIOUS problem somewhere in the EXT3 codebase. I find it
hard to believe that it has not yet been discovered. I have not had a
chance to test it on other distros.

Steps to recreate problem:

Using a reliable system e.g. a Dell PowerEdge 400SC with 512MB RAM/120GB HDD.
Install Ubuntu Server Edition, 6.06 LTS Standard LAMP installation.
All installation options are defaults.
Use apt-get update and apt-get upgrade to get latest releases.

Login and carry out following steps:

1. Create a large file using an arbitrary utility such as DD, CP or TAR
   e.g. # DD if=/dev/zero of=0bits bs=10M count=220
   This example generates a 2.3GB file containing zeros

2. Delete the file immediately
   e.g. # rm 0bits

3. Schedule an fsck on next reboot
   e.g. # touch /forcefsck

4. Reboot immediately
   e.g. # reboot

5. Observe boot process

You will notice that fsck fails on reboot, forces a second reboot and fixes itself.
The file size threshold above which this problem occurs appears to be approx 2.2GB

This problem does NOT occur in a REISER installation (assuming that the
Reiser file system checker is sufficiently thorough). I tested REISER
with file sizes up to 50GB and it worked reliably. I might point out
that, in the case of Reiser, issuing a "touch /forcefsck" does not force
a full check (this is a distro bug). It was therefore necessary to force
an fsck by booting up into recovery mode, unmounting hda1 and issuing an
"fsck -f" manually.

The probem is NOT hard drive or partition size dependent as I have
replicated it with smaller partitions and other hard drive models.

** Affects: linux-source-2.6.15 (Ubuntu)
     Importance: Undecided
     Assignee: Kyle McMartin
         Status: Needs Info

-- 
Deleting large files corrupts EXT3 file system
https://launchpad.net/bugs/83982




More information about the kernel-bugs mailing list