On Thu, Jun 08, 2017 at 11:42:11AM -0400, Sweet Tea Dorminy wrote: > Greetings; > > When using XFS with a 1k block size atop our device, we regularly get > "log record CRC mismatch"es when mounting XFS after a crash, and we > are attempting to understand why. We are using RHEL7.3 with its kernel > 3.10.0-514.10.2.el7.x86_64, xfsprogs version 4.5.0. > > Tracing indicates the following situation occurs: > Some pair of consecutive locations contains data A1 and B1, respectively. > The XFS journal issues new writes to those locations, > containing data A2 and B2. > The write of B' finishes, but A' is still outstanding at the > time of the crash. > Crash occurs. The data on disk is A1 and B2, respectively. > XFS fails to mount, complaining that the checksum mismatches. > > Does XFS expect sequentially issued journal IO to be committed to disk > in the order of issuance due to the use of FUA? Journal IO is not sequentially issued. It's an async process. At runtime, ordering is handled by journal IO completion processing being queued and run in order, so IOs can both be issued and physically complete out of order. Log recovery is supposed to handle this. It searches and finds the latest contiguous journal entry and does not replay past holes that may arise from out of order journal writes. CRC errors like this in recovery imply that journal writes are being torn or not completed fully, which may mean that your storage does not correctly implement flush/FUA ordering semantics.... Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx -- 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
