Hi, Sorry for late response. I am on vacation. I will check this issue as soon as getting back.
Thanks! > 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 fstests" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
