linux-xfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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

  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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).