• Brian Foster's avatar
    xfs: validate metadata LSNs against log on v5 superblocks · a45086e2
    Brian Foster authored
    Since the onset of v5 superblocks, the LSN of the last modification has
    been included in a variety of on-disk data structures. This LSN is used
    to provide log recovery ordering guarantees (e.g., to ensure an older
    log recovery item is not replayed over a newer target data structure).
    
    While this works correctly from the point a filesystem is formatted and
    mounted, userspace tools have some problematic behaviors that defeat
    this mechanism. For example, xfs_repair historically zeroes out the log
    unconditionally (regardless of whether corruption is detected). If this
    occurs, the LSN of the filesystem is reset and the log is now in a
    problematic state with respect to on-disk metadata structures that might
    have a larger LSN. Until either the log catches up to the highest
    previously used metadata LSN or each affected data structure is modified
    and written out without incident (which resets the metadata LSN), log
    recovery is susceptible to filesystem corruption.
    
    This problem is ultimately addressed and repaired in the associated
    userspace tools. The kernel is still responsible to detect the problem
    and notify the user that something is wrong. Check the superblock LSN at
    mount time and fail the mount if it is invalid. From that point on,
    trigger verifier failure on any metadata I/O where an invalid LSN is
    detected. This results in a filesystem shutdown and guarantees that we
    do not log metadata changes with invalid LSNs on disk. Since this is a
    known issue with a known recovery path, present a warning to instruct
    the user how to recover.
    Signed-off-by: default avatarBrian Foster <bfoster@redhat.com>
    Reviewed-by: default avatarDave Chinner <dchinner@redhat.com>
    Signed-off-by: default avatarDave Chinner <david@fromorbit.com>
    a45086e2
xfs_da_btree.c 69.9 KB