From: "Darrick J. Wong" <darrick.wong@oracle.com>
To: Jan Tulak <jtulak@redhat.com>
Cc: linux-xfs@vger.kernel.org
Subject: Re: [PATCH 2/2] fsck.xfs: allow forced repairs using xfs_repair
Date: Thu, 15 Mar 2018 11:11:20 -0700 [thread overview]
Message-ID: <20180315181120.GA4865@magnolia> (raw)
In-Reply-To: <20180315175026.34779-1-jtulak@redhat.com>
On Thu, Mar 15, 2018 at 06:50:26PM +0100, Jan Tulak wrote:
> The fsck.xfs script did nothing, because xfs doesn't need a fsck to be
> run on every unclean shutdown. However, sometimes it may happen that the
> root filesystem really requires the usage of xfs_repair and then it is a
> hassle. This patch makes the situation a bit easier by detecting forced
> checks (/forcefsck or fsck.mode=force), so user can require the repair,
> without the repair being run all the time.
>
> Signed-off-by: Jan Tulak <jtulak@redhat.com>
>
> ---
> Changelog:
> v3:
> - too quick with fixing in v2... add line at the end of the file
> v2:
> - return the "exit 0" at the end
>
> v1:
> - test for xfs_repair binary
> - run only in non-interactive session
> - translate xfs_repair return codes to fsck ones
> - run only if the filesystem is not mounted
> - add manpage update
> ---
> fsck/xfs_fsck.sh | 65 ++++++++++++++++++++++++++++++++++++++++++++++++++++-
> man/man8/fsck.xfs.8 | 12 +++++++++-
> 2 files changed, 75 insertions(+), 2 deletions(-)
>
> diff --git a/fsck/xfs_fsck.sh b/fsck/xfs_fsck.sh
> index e52969e4..0ec6b049 100755
> --- a/fsck/xfs_fsck.sh
> +++ b/fsck/xfs_fsck.sh
> @@ -3,11 +3,42 @@
> # Copyright (c) 2006 Silicon Graphics, Inc. All Rights Reserved.
> #
>
> +NAME=$0
> +
> +# get the right return code for fsck
> +function repair2fsck_code() {
> + case $1 in
> + 0) return 0 # everything is ok
> + ;;
> + 1) echo "$NAME error: xfs_repair could not fix the filesystem." 1>&2
> + return 4 # errors left uncorrected
> + ;;
> + 2) echo "$NAME error: The filesystem to be checked must not be mounted." 1>&2
> + return 4 # it should not me mounted during boot, something is wrong
> + ;;
> + 3) return 1 # The fs has been fixed
> + ;;
> + *) echo "$NAME error: An unknown return code from xfs_repair '$1'" 1>&2
> + return 4 # something went wrong with xfs_repair
> + esac
> +}
> +
> +function ensure_not_mounted() {
> + local dev=$1
> + mounted=`grep -c "^$dev " /proc/mounts`
> + if [ $mounted -ne 0 ]; then
> + echo "$NAME error: The filesystem to be checked must not be mounted." 1>&2
> + exit 4
> + fi
> +}
> +
> AUTO=false
> -while getopts ":aApy" c
> +FORCE=false
> +while getopts ":aApyf" c
> do
> case $c in
> a|A|p|y) AUTO=true;;
> + f) FORCE=true;;
> esac
> done
> eval DEV=\${$#}
> @@ -15,6 +46,38 @@ if [ ! -e $DEV ]; then
> echo "$0: $DEV does not exist"
> exit 8
> fi
> +
> +# The flag -f is added by systemd/init scripts when /forcefsck file is present
> +# or fsck.mode=force is used during boot; an unclean shutdown won't trigger
> +# this check, user has to explicitly require a forced fsck.
> +# But first of all, test if it is a non-interactive session. Use multiple
> +# methods to capture most of the cases:
> +# The case for *i* and -n "$PS1" are commonly suggested in bash manual
> +# and the -t 0 test checks stdin
> +case $- in
> + *i*) FORCE=false ;;
> +esac
> +if [ -n "$PS1" -o -t 0 ]; then
> + FORCE=false
> +fi
> +
> +if $FORCE; then
> + if [ -f /sbin/xfs_repair ]; then
> + BIN="/sbin/xfs_repair"
> + elif [ -f /usr/sbin/xfs_repair ]; then
> + BIN="/usr/sbin/xfs_repair"
Can we just run xfs_repair and assume it's in the PATH?
> + else
> + echo "$NAME error: xfs_repair was not found!" 1>&2
> + exit 4
> + fi
> +
> + ensure_not_mounted $DEV
> +
> + $BIN -e $DEV
> + repair2fsck_code $?
> + exit $?
> +fi
> +
> if $AUTO; then
> echo "$0: XFS file system."
> else
> diff --git a/man/man8/fsck.xfs.8 b/man/man8/fsck.xfs.8
> index ace7252d..3eb3ad7f 100644
> --- a/man/man8/fsck.xfs.8
> +++ b/man/man8/fsck.xfs.8
> @@ -1,6 +1,6 @@
> .TH fsck.xfs 8
> .SH NAME
> -fsck.xfs \- do nothing, successfully
> +fsck.xfs \- do nothing, successfuly
successfully has two 'l'.
> .SH SYNOPSIS
> .B fsck.xfs
> [
> @@ -21,6 +21,16 @@ If you wish to check the consistency of an XFS filesystem,
> or repair a damaged or corrupt XFS filesystem,
> see
> .BR xfs_repair (8).
> +.PP
> +However, it may happen that a forced repair is required and in makes sense to start
> +.BR xfs_repair (8)
> +on startup (either using /forcefsck file or fsck.mode=force kernel option). In this case
> +.B fsck.xfs
> +run
> +.B xfs_repair
> +for the user. But if run outside of boot environment or without the
> +.B -f
> +option, it does nothing.
Bleh, I hate manpages. I'll just ... do this without the formatting.
However, the system administrator can force fsck.xfs to run
xfs_repair(8) by creating a /forcefsck file, booting the system with
"fsck.mode=force" on the kernel command line, or by running fsck.xfs -f.
--D
> .
> .SH FILES
> .IR /etc/fstab .
> --
> 2.15.0
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-xfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2018-03-15 18:12 UTC|newest]
Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-03-05 15:05 [PATCH] fsck.xfs: allow forced repairs using xfs_repair Jan Tulak
2018-03-05 21:56 ` Dave Chinner
2018-03-05 22:06 ` Eric Sandeen
2018-03-05 22:20 ` Darrick J. Wong
2018-03-05 22:31 ` Dave Chinner
2018-03-05 23:33 ` Eric Sandeen
2018-03-06 11:51 ` Jan Tulak
2018-03-06 21:39 ` Dave Chinner
2018-03-08 10:57 ` Jan Tulak
2018-03-08 16:28 ` Darrick J. Wong
2018-03-08 22:36 ` Dave Chinner
2018-03-14 13:51 ` Jan Tulak
2018-03-14 15:25 ` Darrick J. Wong
2018-03-14 21:10 ` Dave Chinner
2018-03-15 17:01 ` Jan Tulak
2018-03-08 23:28 ` Eric Sandeen
2018-03-14 13:30 ` Jan Tulak
2018-03-14 15:19 ` Eric Sandeen
2018-03-15 11:16 ` Jan Tulak
2018-03-15 22:19 ` Dave Chinner
2018-03-15 17:45 ` [PATCH 1/2] xfs_repair: add flag -e to detect corrected errors Jan Tulak
2018-03-15 17:45 ` [PATCH 2/2 v1] fsck.xfs: allow forced repairs using xfs_repair Jan Tulak
2018-03-15 17:47 ` [PATCH 2/2 v2] " Jan Tulak
2018-03-15 17:50 ` [PATCH 2/2] " Jan Tulak
2018-03-15 18:11 ` Darrick J. Wong [this message]
2018-03-15 18:22 ` Jan Tulak
2018-03-15 18:28 ` [PATCH 2/2 v4] " Jan Tulak
2018-03-15 18:49 ` Darrick J. Wong
2018-03-16 10:19 ` Jan Tulak
2018-03-16 15:39 ` Darrick J. Wong
2018-03-16 17:07 ` [PATCH 2/2 v5] " Jan Tulak
2018-03-23 2:37 ` Eric Sandeen
2018-03-23 3:25 ` Darrick J. Wong
2018-03-23 3:29 ` Eric Sandeen
2018-03-23 3:42 ` Darrick J. Wong
2018-03-23 14:00 ` Jan Tulak
2018-03-23 14:14 ` Jan Tulak
2018-03-23 14:33 ` [PATCH 2/2 v6] " Jan Tulak
2022-09-28 5:28 ` Darrick J. Wong
2022-09-29 8:31 ` Carlos Maiolino
2018-03-15 18:03 ` [PATCH 1/2] xfs_repair: add flag -e to detect corrected errors Darrick J. Wong
2018-03-15 18:23 ` [PATCH 1/2 v2] " Jan Tulak
2018-03-15 18:44 ` Darrick J. Wong
2018-03-23 1:57 ` Eric Sandeen
2018-03-23 9:24 ` Jan Tulak
2018-03-23 14:32 ` [PATCH 1/2 v3] xfs_repair: add flag -e to modify exit code for " Jan Tulak
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=20180315181120.GA4865@magnolia \
--to=darrick.wong@oracle.com \
--cc=jtulak@redhat.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.