On Fri, Nov 10, 2023 at 12:22:30PM -0600, Eric Sandeen wrote:
> We recently had the opportunity to run xfs_repair on a system
> with 2T of memory and over a billion inodes. After phase 7
> had completed, xfs_repair appeared to have hung for over an
> hour as the massive cache was written back.
>
> In the long run it might be nice to see if we can add progress
> reporting to the cache flush if it's sufficiently large, but
> for now at least let the user know what's going on.
>
> Signed-off-by: Eric Sandeen <sandeen@xxxxxxxxxx>
> ---
>
> diff --git a/repair/xfs_repair.c b/repair/xfs_repair.c
> index ff29bea9..5597b9ba 100644
> --- a/repair/xfs_repair.c
> +++ b/repair/xfs_repair.c
> @@ -1388,6 +1388,7 @@
> * verifiers are run (where we discover the max metadata LSN), reformat
> * the log if necessary and unmount.
> */
> + do_log(_("Flushing cache...\n"));
Does this new message affect the golden output of any fstests?
Also, while this /does/ flush the libxfs b(uffer)cache, I worry that
the phrasing will lead people into thinking that *disk* caches are being
flushed. That doesn't happen until libxfs_close_devices. I suggest:
"Writing dirty buffers..." ?
--D
> libxfs_bcache_flush();
> format_log_max_lsn(mp);
>
>
