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:
ext4punch.sh
Description: Bourne shell script
