Control: severity -1 normal
Control: fixed -1 1.43.5-1

On Thu, Jun 13, 2019 at 04:09:15PM +0200, Florian Zumbiehl wrote:
> Package: e2fsprogs
> Version: 1.43.4-2
> Severity: critical
> 
> e2fsck potentially moves blocks around in sparse files when running with
> -E bmap2extent, in particular when the blocks are physically adjacent on
> the underlying block device, but have a hole in between in the file.
> ...
>
> With version 1.44.5-1~bpo9+1, the test above does not produce corruption on
> my system, but I have not investigated whether that is just coincidence or
> because the bug has been fixed. As this silently corrupts files, I would
> think it should get some fix in stretch, and be it by disabling the
> feature.

The bug was fixed in e2fsprogs 1.43.5, via the fix:

commit 855c2ecb21d1556c26d61df9b014e1c79dbbc956
Author: Darrick J. Wong <darrick.w...@oracle.com>
Date:   Wed May 24 21:56:36 2017 -0400

    e2fsck: fix sparse bmap to extent conversion
    
    When e2fsck is trying to convert a sparse block-mapped file to an extent
    file, we incorrectly merge block mappings that are physically contiguous
    but not logically contiguous because of insufficient checking with the
    extent we're constructing.  Therefore, compare the logical offsets for
    contiguity as well.
    
    Signed-off-by: Darrick J. Wong <darrick.w...@oracle.com>
    Signed-off-by: Theodore Ts'o <ty...@mit.edu>

It's an unfortunate bug, but we've lived with it for about ten years,
and it was only noticed in 2017.  The reality is very few people
actually try to convert an indirect mapped file system the new
extent-mapped system, because you get much more of the benefits of
using a more modern version of ext4 by doing a backup, reformat, and
restore of the file system.

Given that so few people have noticed, I don't believe this qualifies
as even "important", since doing the conversion is not a fundamental
aspect of e2fsck, so it doesn't qualify as a significant impact on the
usability of the package.  For similar reasons, I don't believe the
release team would agree to a new release of e2fsprogs to stretch ---
especially since (a) it's fixed in buster, (b) the fix is also
available in stretch-backports, and (c) in three weeks, Stretch will
become oldstable and Buster will become the new stable release of
Debian.

Feel free to escalate this to the Debain release team but I don't
think this is going to be considered worth their time (or mine) to be
worth a backport of the fix to e2fsprogs 1.43.4-2.

Cheers,

                                                - Ted

Reply via email to