Re: [PATCH 8/9] xfs_repair: add -R to replay a dirty log before repairing

[Dave Chinner <dgc@kernel.org>]

On Wed, Aug 26, 2026 at 10:25:44PM -0700, Chris Wedgwood wrote:
> xfs_repair refuses to run on a filesystem with a dirty log, and the only
> way past that has been -L, which destroys the log and every metadata
> update it describes.  The advice is to mount and unmount the filesystem
> first, which is not available when the filesystem cannot be mounted, or
> when the machine that crashed is gone.
> 
> -R replays the log first, using the kernel's own recovery code, and then
> repairs the result.  It is defined to be equivalent to mounting the
> filesystem, unmounting it cleanly, and repairing that - so it retires the
> log afterwards, and refuses to run alongside -L or -n.
....

> +	/*
> +	 * From here on intents are being completed for real.  Userspace writes
> +	 * no done items, so an intent finished before a failure is still
> +	 * described by the log we did not retire, and replaying that log again
> +	 * - here or by a kernel mount - would apply it a second time.  Say so,
> +	 * because the obvious response to a failure is to try again.
> +	 */
> +	error = -xlog_recover_finish(log);
> +	if (error)
> +		do_error(
> +	_("Log recovery completion failed: %s\n"
> +	  "Some intents may already have been applied.  Do not replay this log\n"
> +	  "again, by mount or by -R, as that would apply them twice.  Use -L to\n"
> +	  "discard the log and repair instead.\n"),
> +			 strerror(error));

Urk.  That's a red flag. Log recovery should -always- be retriable,
even if there are failures replaying intents.

The progress that intent processing makes writes new records to the
journal (intents and modified objects), and so running log recovery
a second time will continue where the intent replay failed last
time. i.e. it will recover all the changes up to the last failure,
then attempt to replay the remaining intents that are pending in the
journal.

If the userspace log recovery cannot be run repeatedly on recovery
failure without bad things happening, then the code is buggy. Only
once the recovery gets to the point that no new objects can be
recovered because of persistent failures should the user need to
resort to clearing the log....

Also, why are you copy/pasting and subtly modifying all the kernel
log recovery code here instead of running the kernel code in libxlog
directly?

Cheers,

Dave.
-- 
Dave Chinner
dgc@kernel.org