On Tue, Jul 28, 2015 at 07:51:29AM +1000, Dave Chinner wrote: > The block layout outside the insert range should not be modified at > all, so if inserting 100 holes results in more data extents that the > expected 100, then there's something wrong before we start inserting > holes. e.g. maybe the source file had two extents rather than 1. > Can you confirm that this is occurring? Yes, that's what is going on. If delayed allocation is disabled (as it is in some configuration scenarios), ext4's block allocator doesn't do as well, and in some cases it will pick a starting block number for the file that ends up splitting the initial file across block groups' meta data blocks. > Really, the number of extents or holes at the intermediate stage > doesn't matter. What matters is that after collapsing the holes back > out of the file, then number of extents is identical to the original > file (i.e. that fcollapse() undoes finsert() exactly). Yup. > So changing this code to use _within_tolerance to say that 100 >= > num_extents >= 105 is ok would probably be better: > > _within_tolerance "Extent count" $nextents 100 0 5% > > This will output a standard pass/fail message rather than an exact > count. This allows some wiggle room for filesystem configurations > that have unexpected non-contiguous baseline allocation behaviour to > pass the test. Works for me. Thanks, - Ted -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
