e2defrag - Unable to allocate buffer for inode priorities

[Goswin von Brederlow]

Theodore Tso <tytso at mit.edu> writes:

> 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).

It should be doing that (checking for ext3 I can confirm) as of

defrag (0.73pjm1-8) unstable; urgency=low

  * ext3-notwork.dpatch: reverse testcase (Closes: #310800)

It doesn't handle ext3 right and does know so:

# mke2fs -j /dev/ram0 
# e2defrag -r /dev/ram0

e2defrag (/dev/ram0): ext3 filesystems not (yet) supported


It hapily defrags a filesystem with resize_inode. Is it destroying
resize capability or directly destroying data?

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

Yes, please do so and preferably with a script to reproduce this
without resorting to a big image file. Something in the form of

mke2fs <options>
mount
unpack kernel source
umount
defrag
mount fails

would be perfect. (Well not for defrag, but to debug it. :)

> Goswin, I am setting the severity to grave (a release-critical

You should have used debbugs-CC so I get to see the bug number
directly and can reply to the bug. :)

> 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.

There is '#235498: defrag: ext3 support would be nice :-)' for this
issue but I need some serious help there to add all the new
features. Preferably a new active upstream. Maybe some people working
on ext4 would be willing to help?

But that won't happen before etch, I'm certain of that. I'm also
confident that I can patch in any checks to make e2defrag run on a
filesystem with incompatible features (like has_journal from
ext3). Checking those is just an extension of the ext3 check. But
people that still have ext2 or can disable the extra features
(e.g. delete journal, e2defrag, create journal) can still use
e2defrag. I would prefer keeping it in.

> Regards,
>
> 						- Ted

MfG
        Goswin