Filesystem checks (fsck) typically occur based on:

1. Mount count threshold
2. Time interval between checks
3. Filesystem "dirty" state
4. Force flag in /etc/fstab

# Check current settings for /dev/sda1
tune2fs -l /dev/sda1 | grep -E "Maximum mount count|Check interval|Last checked"

To predict whether your next reboot will trigger fsck:

#!/bin/bash
DEVICE="/dev/sda1"
MAX_MOUNTS=$(tune2fs -l $DEVICE | awk '/Maximum mount count/{print $NF}')
MOUNT_COUNT=$(tune2fs -l $DEVICE | awk '/Mount count/{print $NF}')

if [ $MOUNT_COUNT -ge $((MAX_MOUNTS -1)) ]; then
    echo "WARNING: Next reboot will trigger fsck (mount count $MOUNT_COUNT/$MAX_MOUNTS)"
else
    echo "No fsck expected on next boot"
fi

To postpone filesystem checking:

# Reset mount count (safest method)
tune2fs -c 0 /dev/sda1  # Disable mount-count based checking

# OR update last check time
tune2fs -T now /dev/sda1  # Sets last check time to current time

# For ext4 filesystems, you can also use:
fsck.mode=skip fsck.repair=no  # As kernel boot parameters

If you're already in a reboot situation and need to bypass fsck:

1. Edit grub entry at boot (press 'e')
2. Add fastboot to kernel parameters
3. Or add fsck.mode=skip

For production servers where downtime matters:

# Set check interval to 6 months (15552000 seconds)
tune2fs -i 15552000 /dev/sda1

# Disable mount-count checking entirely
tune2fs -c 0 /dev/sda1

# Enable lazy inode table initialization (ext4)
mkfs.ext4 -E lazy_itable_init=1 /dev/sda1

Better than skipping checks is knowing when they're actually needed:

# Check filesystem errors without mounting
fsck -n /dev/sda1

# Check for pending journal commits
dumpe2fs /dev/sda1 | grep "Journal checksum"

# Monitor filesystem errors in real-time
tail -f /var/log/kern.log | grep "EXT4-fs error"

When dealing with production Linux servers, unexpected filesystem checks during reboot can significantly extend downtime. The fsck (filesystem check) process triggers based on several factors:

# Check current mount count and fsck timing
tune2fs -l /dev/sdXN | grep -E "Maximum mount count|Check interval|Last checked"

To predict whether your next reboot will trigger fsck:

# Check if filesystem is marked dirty (needs checking)
dumpe2fs -h /dev/sdXN | grep "Filesystem state"
# Sample output: "Filesystem state: clean" or "Filesystem state: not clean"

Additionally, check mount count thresholds:

tune2fs -l /dev/sdXN | grep -E "Mount count|Maximum mount count"

When you need to postpone fsck to a maintenance window:

# Reset mount count (push fsck to next interval)
tune2fs -C 0 /dev/sdXN

# Mark filesystem as clean (if currently dirty)
tune2fs -c 0 -i 0 /dev/sdXN

# Set maximum mount count to higher value
tune2fs -c 1000 /dev/sdXN

Create a reboot wrapper script to detect pending fsck:

#!/bin/bash
DEVICE="/dev/sdXN"

check_fsck_pending() {
    local state=$(dumpe2fs -h "$DEVICE" | grep "Filesystem state" | awk '{print $NF}')
    [ "$state" = "clean" ] || return 1
    
    local mount_count=$(tune2fs -l "$DEVICE" | grep "Mount count" | awk '{print $3}')
    local max_mount=$(tune2fs -l "$DEVICE" | grep "Maximum mount count" | awk '{print $4}')
    [ $mount_count -lt $max_mount ] || return 1
    
    return 0
}

if ! check_fsck_pending; then
    echo "WARNING: fsck will run on next boot! Consider delaying with:"
    echo "  tune2fs -C 0 $DEVICE"
    echo "Proceed with reboot? (y/N)"
    read answer
    [[ "$answer" =~ ^[Yy]$ ]] || exit 1
fi

/sbin/reboot "$@"

• Never postpone fsck indefinitely on known problematic filesystems
• For XFS, use xfs_repair -n instead of fsck
• Cloud instances often have different fsck behaviors - check provider documentation