[Bug 83982] Re: Deleting large files corrupts EXT3 file system

[rvjcallanan]

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: bounces at canonical.com [mailto:bounces at canonical.com] On Behalf Of Theodore Ts'o
Sent: 11 February 2007 01:19
To: vincent at callanan.ie
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