Re: [PATCH] ext4: fix indirect punch hole corruption

[Omar Sandoval <osandov@osandov.com>]

[-- Attachment #1: Type: text/plain, Size: 1718 bytes --]

On Thu, Feb 05, 2015 at 12:50:13PM -0800, Omar Sandoval wrote:
> Commit 4f579ae7de56 (ext4: fix punch hole on files with indirect
> mapping) rewrote FALLOC_FL_PUNCH_HOLE for ext4 files with indirect
> mapping. However, the case where the punch happens within one level of
> indirection is incorrect. It assumes that the partial branches returned
> from ext4_find_shared will have the same depth, but this is not
> necessarily the case even when the offsets have the same depth. For
> example, if the last block occurs at the beginning of an indirect group
> (i.e., it has an offset of 0 at the end of the offsets array), then
> ext4_find_shared will return a shallower chain. So, let's handle the
> mismatch and clean up that case. Tested with generic/270, which no
> longer leads to an inconsistent filesystem like before.
> 
Ah, forgot to mention that this applies to v3.19-rc7. Additionally,
I've attached a script which reproduces the issue. You can run
xfs_io -c fiemap "$FILE" (after an umount/mount of the filesystem just
be safe) and see that before the fix, a bunch of blocks get swallowed:

/mnt/scratch/test:
        0: [0..31]: 1026..1057
        1: [32..127]: 930..1025
        2: [128..255]: 2114..2241
        3: [256..511]: 2306..2561
        4: [512..535]: 2818..2841
        5: [536..1559]: hole

... but after the fix, the hole is in the right place:

/mnt/scratch/test:
        0: [0..31]: 1026..1057
        1: [32..127]: 930..1025
        2: [128..255]: 2114..2241
        3: [256..511]: 2306..2561
        4: [512..791]: 2818..3097
        5: [792..1047]: hole
        6: [1048..1559]: 4122..4633

(These examples are from a 1k-block ext3 filesystem with
CONFIG_EXT4_USE_FOR_EXT23=y).

-- 
Omar

[-- Attachment #2: ext4punch.sh --]
[-- Type: application/x-sh, Size: 606 bytes --]