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:

quoted

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

quoted

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