What's happening is that if e2fsck does a complete scan of the filesystem, which in your case your are forcing by touching /forcefsck, and e2fsck notices that there are no more files > 2GB, and the large_file feature flag is set, e2fsck will clear the large_file feature flag. Currently it doesn't print a message when it does this, which is causing the confusion.
Since it has modified the filesystem, it will return an exit status of 1 (filesystem modified) or 3 (filesystem modified | system should be rebooted) if the filesystem in question is the root filesystem. This is because if parts of the root filesystem were modified, it's not safe to remount the filesystem read-write, since some of the inconsistent parts of the filesystem could have been cached in memory, and so when the filesystem is re-mounted read/write, the broken bits of the filesystem could get written back to disk, undoing e2fsck's work. So it's not that deleting large file corrupts the EXT3 filesystem; it's that e2fsck noticed that the filesystem no longer had any large files, and did you a favor by clearing an RO compat bit which would allow the filesystem to be mounted read/write on really old Linux kernels (which didn't support large files). It probably should have written a message to explain what it was doing, and I could perhaps accept an argument that perhaps there should be a config parameter to suppress clearing the large_file flag, on the argument that very few filesystems are likely to be mounted on a Linux 1.0 or 1.2 systems these days. On the other hand, this happens rarely enough and the time to force reboot isn't that great, so maybe it's not worth the config parameter. In any case that's what's going on. -- Deleting large files corrupts EXT3 file system https://launchpad.net/bugs/83982 -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
