From: Chandan Babu R <chandanrlinux@gmail.com>
To: "Darrick J. Wong" <darrick.wong@oracle.com>
Cc: linux-xfs@vger.kernel.org, david@fromorbit.com
Subject: Re: [PATCH V4 10/10] xfs: Introduce error injection to reduce maximum inode fork extent count
Date: Sat, 19 Sep 2020 15:15:42 +0530 [thread overview]
Message-ID: <3295439.FJLT6Hgy6b@garuda> (raw)
In-Reply-To: <20200918153930.GX7955@magnolia>
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
prev parent reply other threads:[~2020-09-19 9:45 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-09-18 9:47 [PATCH V4 00/10] Bail out if transaction can cause extent count to overflow Chandan Babu R
2020-09-18 9:47 ` [PATCH V4 01/10] xfs: Add helper for checking per-inode extent count overflow Chandan Babu R
2020-09-18 9:47 ` [PATCH V4 02/10] xfs: Check for extent overflow when trivally adding a new extent Chandan Babu R
2020-09-18 9:47 ` [PATCH V4 03/10] xfs: Check for extent overflow when punching a hole Chandan Babu R
2020-09-18 15:54 ` Darrick J. Wong
2020-09-19 9:42 ` Chandan Babu R
2020-09-18 9:47 ` [PATCH V4 04/10] xfs: Check for extent overflow when adding/removing xattrs Chandan Babu R
2020-09-18 15:49 ` Darrick J. Wong
2020-09-18 9:47 ` [PATCH V4 05/10] xfs: Check for extent overflow when adding/removing dir entries Chandan Babu R
2020-09-18 9:47 ` [PATCH V4 06/10] xfs: Check for extent overflow when writing to unwritten extent Chandan Babu R
2020-09-18 9:47 ` [PATCH V4 07/10] xfs: Check for extent overflow when moving extent from cow to data fork Chandan Babu R
2020-09-18 9:47 ` [PATCH V4 08/10] xfs: Check for extent overflow when remapping an extent Chandan Babu R
2020-09-18 9:47 ` [PATCH V4 09/10] xfs: Check for extent overflow when swapping extents Chandan Babu R
2020-09-18 15:44 ` Darrick J. Wong
2020-09-19 9:44 ` Chandan Babu R
2020-09-18 9:47 ` [PATCH V4 10/10] xfs: Introduce error injection to reduce maximum inode fork extent count Chandan Babu R
2020-09-18 15:39 ` Darrick J. Wong
2020-09-19 9:45 ` Chandan Babu R [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3295439.FJLT6Hgy6b@garuda \
--to=chandanrlinux@gmail.com \
--cc=darrick.wong@oracle.com \
--cc=david@fromorbit.com \
--cc=linux-xfs@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.