[CentOS] Re: Ext2/3 fs and defragmentationn

Wed Dec 13 16:12:52 UTC 2006
Tom Diehl <tdiehl at rogueind.com>

You wrote:

> Hi all,
> Fewer days ago a CentOS box server suffered a manual and unexpected
> reset (too large to explain: there are silly people in everywhere).
> The result was the system did not mount de root (/) partition and the
> boot process was stopped. I repair it easily: boot from LiveCD (Knoppix
> in my case), umount root partition and pass the e2fsck utility.
> Because of that I've used several fs tools and my surprise was the
> e2defrag utility. Until the present day I think the ext2/3 fs has not
> defrag problem. But I've used defrag tools in root partition because it
> was really fragmented.
> What do you know about this kind of "trouble"?
> I supose the fragmentation is ext2/3 fs is lesser problem than in Win fs
> (FAT32, NTFS) but I'm not sure.

DO NOT USE IT. Below is a message from Ted Tso to the ext3 mailing list:

Date: Tue, 31 Oct 2006 14:29:48 -0500
From: Theodore Tso <tytso at mit.edu>
To: "Magnus [utf-8] M?nsson" <magnusm at massive.se>, ext3-users at redhat.com
Cc: submit at bugs.debian.org, brederlo at informatik.uni-tuebingen.de
Subject: Re: e2defrag - Unable to allocate buffer for inode priorities

Package: defrag
Version: 0.73pjm1-8
Severity: grave

On Wed, Nov 01, 2006 at 01:10:50AM +0800, Andreas Dilger wrote:
> > So now it was time to defrag, I used this command:
> > thor:~# e2defrag -r /dev/vgraid/data
> This program is dangerous to use and any attempts to use it should be
> stopped.  It hasn't been updated in such a long time that it doesn't
> even KNOW that it is dangerous (i.e. it doesn't check the filesystem
> version number or feature flags).

In fact we need to create a Debian bug report indicating that this
package should *NOT* be included when the Debian etch distribution

Goswin, I am setting the severity to grave (a release-critical
severity) because defrag right now is almost guaranteed to corrupt the
filesystem if used with modern ext3 filesystems leading to data loss,
and this satisfies the definition of grave.  I believe the correct
answer is either to (a) make defrag refuse to run if any filesystem
features are enabled (at the very least, resize_inode, but some of the
other newer ext3 filesystem features make me nervous with respect to
e2defrag, or (b) since (a) would make e2defrag mostly useless
especially since filesystems with resize inodes are created by default
in etch, and as far as I know upstream abandoned defrag a long time
ago, that we should simply remove e2defrag from etch and probably from
Debian altogether.

If you are interested in doing a huge amount of auditing and testing
of e2defrag with modern ext3 (and soon ext4) filesystems, that's
great, but I suspect that will not at all be trivial, and even making
sure e2defrag won't scramble users' data probably can't be achievable
before etch releases.


                                                 - Ted

Ext3-users mailing list
Ext3-users at redhat.com

Tom Diehl		tdiehl at rogueind.com		Spamtrap address mtd123 at rogueind.com