Hi folks, The following are two patches to fix the corruption bug that Zorro recently recently reported on big endian platforms when nrext64 is enabled. It is caused by recovery zeroing a v2 inode field even on v3 inodes. Before nrext64, this wasn't an issue because the field in v3 inodes was just padding (i.e. zeroes) and so writing zero to part of it was never noticed. However, nrext64 uses this field for the 64 bit data fork extent count, so zeroing part of it becomes a problem. The zeroing is done to the xfs_log_dinode, which is held in host format. Because of the layout of this field, on little endian machines the di_flush_iter field overlaps the high 16 bits of di_big_nextents, and so we didn't notice that recovery was overwriting the the high bits of the extent count because it's always going to be zero bytes (needs to go over 2^48 extents before we'd notice) in testing contexts. However, on big endian machines, the di_flushiter field overlays the lower 16 bits of the di_big_extents field, and so zeroing di_flushiter essentially rounds it down to the nearest 64k. For typical testing contexts, that's effectively zeroing the extent count. The fix is two parts. The first patch adds detection of this specific corruption to the xfs_dinode verifier, and adds a call to the verifier after recovery has recovered the inode. This catches corruptions at recovery time, rather than silently writing them back and not noticing them until the inode is re-read from disk at runtime. The second patch fixes the recovery bug. It simply moves the resetting of the di_flushiter field into the v2 inode specific flushiter handling branch. That's always been wrong (i.e. since v3 inodes were introduced) but it hasn't mattered until now, so it marked as fixing the introduction of the nrext64 feature.... -Dave.
