Re: [PATCH V4 10/10] xfs: Introduce error injection to reduce maximum inode fork extent count

Chandan Babu R
2020-09-19T09:45:47Z

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