Thank you for quick diagnosis. Call me a nit-picker, but I would argue that...
No fundamental operation (such as a large file delete) should invalidate the file system "state" (even if this particular state flag is legacy- related and not that critical). Surely, when a large file is deleted, the EXT3 delete primitive should check if this is the last large file and clear the flag accordingly...or more likely, rather than using a flag, it would maintain a large file count which is incremented when a large file is created and decremented when a large file is deleted, etc, etc. In other words, it is a bug. You need to be able to depend on fsck to give you correct information e.g. you might assume an fsck error was due to a large file removal (based on past form) but in fact you may have another problem i.e. "boy who cried wolf" syndrome. I think this bug should at least be notified to the EXT3 project. Rgds, Vincent Callanan -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Theodore Ts'o Sent: 11 February 2007 01:19 To: [EMAIL PROTECTED] Subject: [Bug 83982] Re: Deleting large files corrupts EXT3 file system 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 -- 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
