On Friday 18 September 2020 9:09:30 PM IST Darrick J. Wong wrote: > On Fri, Sep 18, 2020 at 03:17:59PM +0530, Chandan Babu R wrote: > > This commit adds XFS_ERRTAG_REDUCE_MAX_IEXTENTS error tag which enables > > userspace programs to test "Inode fork extent count overflow detection" > > by reducing maximum possible inode fork extent count to > > 10 (i.e. MAXERRTAGEXTNUM). > > > > This commit makes the following additional changes to enable writing > > deterministic userspace tests for checking inode extent count overflow, > > 1. xfs_bmap_add_extent_hole_real() > > File & disk offsets at which extents are allocated by Directory, > > Xattr and Realtime code cannot be controlled explicitly from > > userspace. When XFS_ERRTAG_REDUCE_MAX_IEXTENTS error tag is enabled, > > xfs_bmap_add_extent_hole_real() prevents extents from being merged > > even though the new extent might be contiguous and have the same > > state as its neighbours. > > That sounds like fs corruption to me, since btree records are supposed > to be maximally sized. > > > 2. xfs_growfs_rt_alloc() > > This function allocates as large an extent as possible to fit in the > > additional bitmap/summary blocks. We now force allocation of block > > sized extents when XFS_ERRTAG_REDUCE_MAX_IEXTENTS error tag is > > enabled. > > Ah, so your goal is to dramatically cut the MAX?EXTNUM and then force > the allocator to fragment the fs, so that it will quickly hit that > maximum. > > /me suspects that "maximally fragment" ought to be a separate error > injector that teaches the alloctor to satisfy the minimum required > allocation, and to look only in the short end of the cntbt. This looks like a perfect fit for my requirements. I will take a shot at implementing this. Thanks for the suggestion. -- chandan
