Re: XFS: false "torn write" errors (preventing mount)

[Brian Foster <bfoster@redhat.com>]

On Mon, Feb 29, 2016 at 10:57:52AM -0500, Brian Foster wrote:
> On Mon, Feb 29, 2016 at 08:29:20AM -0700, Jan Beulich wrote:
> > Brian,
> > 
> > on a system where I routinely run both a 32-bit and a 64-bit x86
> > kernel (underneath the same 32-bit distro) I'm observing the
> > newly added message being issued, along with the mounts
> > subsequently failing when running the 32-bit kernel. Without
> > doing anything to the FS, running an older 32-bit kernel or a
> > 4.5-rc6 64-bit one have everything work fine (and silently), so
> > I can only assume the detection logic doesn't work right in a
> > 32-bit kernel. I've looked over commits 6528250b71 and
> > 7088c4136f without being able to spot any obvious word size
> > dependency, but then again I know nothing about the inner
> > workings of the XFS code.
> > 
> > I'm now hoping that you have an idea what's going on here.
> > 
> 
> There was one follow on fix related to byte order: 8e0bd4925bf6 ("xfs:
> fix endianness error when checking log block crc on big endian
> platforms"), but I don't think that would have any effect on an x86
> kernel.
> 
> Is the 32-bit kernel problematic on its own, or must the 64-bit kernel
> be involved somehow before the 32-bit kernel reproduces a problem? For
> example, can you mkfs, mount and remount (perhaps multiple times) on the
> 32-bit kernel without a problem? If so, what happens if you transition
> to the 64-bit kernel, remount a few times, and then go back to 32-bit?
> In general, anything that narrows down the reproducer is helpful.
> 
> I don't appear to have a 32-bit env. handy so I'll kick off an install
> in the meantime and take a closer look from there...
> 

Just a heads up that I've been able to reproduce. What I think might be
going on is that the log is clean, but the log recovery pass looks back
behind the latest unmount record, runs into some records/data written by
the alternate architecture from that which is running, and then fails
due to crc mismatch. The problem doesn't seem to manifest right away,
however, so I could still be missing something here.

Anyways, I'll dig into it and try to come up with a fix. Thanks for the
report!

Brian

> Brian
> 
> > Thanks, Jan
> > 
> > _______________________________________________
> > xfs mailing list
> > xfs@oss.sgi.com
> > http://oss.sgi.com/mailman/listinfo/xfs
> 
> _______________________________________________
> xfs mailing list
> xfs@oss.sgi.com
> http://oss.sgi.com/mailman/listinfo/xfs

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs