e2fsck forces reboot when clearing LARGE_FILE flag confusing user
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
e2fsprogs (Ubuntu) |
Fix Released
|
Wishlist
|
Kyle McMartin | ||
linux-source-2.6.15 (Ubuntu) |
Invalid
|
Undecided
|
Unassigned | ||
linux-source-2.6.17 (Ubuntu) |
Invalid
|
Undecided
|
Unassigned |
Bug Description
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.
You didn't include the error messages fsck returned. Please include that.