xfs: only run torn log write detection on dirty logs
authorBrian Foster <bfoster@redhat.com>
Sun, 6 Mar 2016 21:22:22 +0000 (08:22 +1100)
committerDave Chinner <david@fromorbit.com>
Sun, 6 Mar 2016 21:22:22 +0000 (08:22 +1100)
commit7f6aff3a29b08fc4234c8136eb1ac31b4897522c
tree5f30fdc12151acff05a50dafee1f885cbf425b3a
parent717bc0ebca0bce9cb3edfc31b49b384a1d55db1c
xfs: only run torn log write detection on dirty logs

XFS uses CRC verification over a sub-range of the head of the log to
detect and handle torn writes. This torn log write detection currently
runs unconditionally at mount time, regardless of whether the log is
dirty or clean. This is problematic in cases where a filesystem might
end up being moved across different, incompatible (i.e., opposite
byte-endianness) architectures.

The problem lies in the fact that log data is not necessarily written in
an architecture independent format. For example, certain bits of data
are written in native endian format. Further, the size of certain log
data structures differs (i.e., struct xlog_rec_header) depending on the
word size of the cpu. This leads to false positive crc verification
errors and ultimately failed mounts when a cleanly unmounted filesystem
is mounted on a system with an incompatible architecture from data that
was written near the head of the log.

Update the log head/tail discovery code to run torn write detection only
when the log is not clean. This means something other than an unmount
record resides at the head of the log and log recovery is imminent. It
is a requirement to run log recovery on the same type of host that had
written the content of the dirty log and therefore CRC failures are
legitimate corruptions in that scenario.

Reported-by: Jan Beulich <JBeulich@suse.com>
Tested-by: Jan Beulich <JBeulich@suse.com>
Signed-off-by: Brian Foster <bfoster@redhat.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
fs/xfs/xfs_log_recover.c