> > + > > +# 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@xxxxxxxxxxxxxxx > > More majordomo info at http://vger.kernel.org/majordomo-info.html -- Carlos Maiolino
