On Mon, Feb 03, 2025 at 09:55:13AM +0100, Lukas Herbolt wrote:
> If there is corrutpion on the filesystem andxfs_repair
> fails to repair it. The last resort of getting the data
> is to use norecovery,ro mount. But if the NEEDSREPAIR is
> set the filesystem cannot be mounted. The flag must be
> cleared out manually using xfs_db, to get access to what
> left over of the corrupted fs.
>
> Signed-off-by: Lukas Herbolt <lukas@xxxxxxxxxxx>
> ---
> fs/xfs/xfs_super.c | 8 ++++++--
> 1 file changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/fs/xfs/xfs_super.c b/fs/xfs/xfs_super.c
> index 394fdf3bb535..c2566dcc4f88 100644
> --- a/fs/xfs/xfs_super.c
> +++ b/fs/xfs/xfs_super.c
> @@ -1635,8 +1635,12 @@ xfs_fs_fill_super(
> #endif
> }
>
> - /* Filesystem claims it needs repair, so refuse the mount. */
> - if (xfs_has_needsrepair(mp)) {
> + /*
> + * Filesystem claims it needs repair, so refuse the mount unless
> + * norecovery is also specified, in which case the filesystem can
> + * be mounted with no risk of further damage.
> + */
> + if (xfs_has_needsrepair(mp) && !xfs_has_norecovery(mp)) {
I think a better way to handle badly damaged filesystems is for us to
provide a means to extract directory trees in userspace, rather than
making the user take the risk of mounting a known-bad filesystem.
I've a draft of an xfs_db subcommand for doing exactly that and will
share for xfsprogs 6.14.
--D
> xfs_warn(mp, "Filesystem needs repair. Please run xfs_repair.");
> error = -EFSCORRUPTED;
> goto out_free_sb;
> --
> 2.48.1
>
>
