From: Dave Chinner <david@fromorbit.com>
To: linux-xfs@vger.kernel.org
Subject: [PATCH 0/5 V2] xfs: various fixes
Date: Tue, 20 Jun 2023 10:20:16 +1000 [thread overview]
Message-ID: <20230620002021.1038067-1-david@fromorbit.com> (raw)
Hi folks,
This is a wrap up of version 2 of all the fixes I have recently
pushed out for review.
The first patch fixes a AIL ordering problem identified when testing
patches 2-4 in this series. This patch only addresses the AIL ordering
problem that was found, it does not address any other corner cases
in intent recovery that may be exposed by patches 2-4.
Patches 2-4 allow partial handling of multi-extent EFIs during
runtime operation and during journal recovery. This is needed as
we attempt to process all the extents in the EFI in a single
transaction and we can deadlock during AGFL fixup if the transaction
context holds the only free space in the AG in a busy extent.
This patchset uncovered a problem where log recovery would run off
the end of the list of intents to recover and into intents that
require deferred processing. This was caused by the ordering issue
fixed in patch 1.
This patchset does not attempt to address the end of intent recovery
detection issues - this raises other issues with the intent recovery
beyond loop termination. Solving those issues requires more thought,
and the problem can largely be avoided by the first patch in the
series. As it is, CUI recovery has been vulnerable to these intent
recovery loop termination issues for several years but we don't have
any evidence that systems have tripped over this so the urgency to
fix the loop termination fully isn't as high as fixing the AIL bulk
insertion ordering problem that exposed it.
Finally, patch 5 addresses journal geometry validation issues. It
makes all geometry mismatches hard failures for V4 and V5
filesystems, except for the log size being too small on V4
filesystems. This addresses the problem on V4 filesystems where we'd
fail to perform ithe remaining validation on the geometry once we'd
detected that the log was too small or too large.
This all passed fstests on v4 and v5 filesystems without
regressions.
-Dave.
---
Version 2:
- patch 1
- rewritten commit message
- patch 2
- uint32_t alloc_flag conversion pushed all the way down into
xfs_extent_busy_flush
- patch 3
- Updated comment for xfs_efd_from_efi()
- fixed whitespace damage
- check error return from xfs_free_extent_later()
- patch 5
- update error message for max LSU size check
- fix whitespace damage
- clean up error handling in xfs_log_mount() changes
next reply other threads:[~2023-06-20 0:20 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-06-20 0:20 Dave Chinner [this message]
2023-06-20 0:20 ` [PATCH 1/5] xfs: don't reverse order of items in bulk AIL insertion Dave Chinner
2023-06-20 0:20 ` [PATCH 2/5] xfs: pass alloc flags through to xfs_extent_busy_flush() Dave Chinner
2023-06-20 0:20 ` [PATCH 3/5] xfs: allow extent free intents to be retried Dave Chinner
2023-06-20 0:20 ` [PATCH 4/5] xfs: don't block in busy flushing when freeing extents Dave Chinner
2023-06-20 14:53 ` Chandan Babu R
2023-06-20 22:18 ` Dave Chinner
2023-06-22 3:59 ` Chandan Babu R
2023-06-22 5:28 ` Dave Chinner
2023-06-22 5:36 ` Chandan Babu R
2023-06-20 0:20 ` [PATCH 5/5] xfs: journal geometry is not properly bounds checked Dave Chinner
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=20230620002021.1038067-1-david@fromorbit.com \
--to=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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox