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@xxxxxxxxxxx > > http://oss.sgi.com/mailman/listinfo/xfs > > _______________________________________________ > xfs mailing list > xfs@xxxxxxxxxxx > http://oss.sgi.com/mailman/listinfo/xfs _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs