Re: [PATCH 2/2 v6] fsck.xfs: allow forced repairs using xfs_repair

[Carlos Maiolino <cem@kernel.org>]

> > +
> > +# 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.
> > +# Invoking xfs_repair via fsck.xfs is only intended to happen via initscripts.
> > +# Normal administrative filesystem repairs should always invoke xfs_repair
> > +# directly.
> > +#
> > +# 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
> > +	XFS_REPAIR=`command -v xfs_repair`
> > +	if [ ! -x "$XFS_REPAIR" ] ; then
> > +		echo "$NAME error: xfs_repair was not found!" 1>&2
> > +		exit 4
> > +	fi
> > +
> > +	$XFS_REPAIR -e $DEV
> > +	repair2fsck_code $?
> 
> Just to reopen years-old discussions --
> 
> Recently, a customer decided to add "fsck.mode=force" to the kernel
> command line to force systemd to fsck the rootfs on boot.  They
> performed a powerfail simulation, and on next boot they were dropped to
> an emergency shell because the log was dirty and xfs_repair returned a
> nonzero error code.  If the system was rebooted cleanly then xfs_repair
> rebuilds the space metadata and exits quietly.
> 
> Earlier in this thread we decided not to do a mount/umount cycle to
> clear a dirty log for fear that the mount could crash the kernel.  Would
> anyone like to entertain the idea of adding that cycle to fsck.xfs if
> the program argv includes '-y' and xfs_repair returns 2?  That would
> only happen if the sysadmin *also* adds "fsck.repair=yes" to the kernel
> command line.
> 

I am not really opposed at it.

Particularly, I don't like the idea of the chance of unnoticed corruptions. And
I'm afraid this will just encourage some users to set fsck.mode=force
'by default', which I don't think is ideal. Not to mention, one of the advantages
of journaling FS'es is exactly avoid forcing a fsck at mount time :)

Anyway, this is just my $0.02, I'm not really opposed to this if people find
this useful somehow to avoid human interaction in case of a corrupted rootfs.

> Omitting a fsck.repair= setting means systemd passes -a to fsck instead
> of -y.
> 
> --D
> 
> > +	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..a51baf7c 100644
> > --- a/man/man8/fsck.xfs.8
> > +++ b/man/man8/fsck.xfs.8
> > @@ -21,6 +21,13 @@ 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, the system administrator can force
> > +.B fsck.xfs
> > +to run
> > +.BR xfs_repair (8)
> > +at boot time by creating a /forcefsck file or booting the system with
> > +"fsck.mode=force" on the kernel command line.
> >  .
> >  .SH FILES
> >  .IR /etc/fstab .
> > --
> > 2.16.2
> >
> > --
> > 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

-- 
Carlos Maiolino