[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