* XFS: false "torn write" errors (preventing mount) @ 2016-02-29 15:29 Jan Beulich 2016-02-29 15:57 ` Brian Foster 0 siblings, 1 reply; 3+ messages in thread From: Jan Beulich @ 2016-02-29 15:29 UTC (permalink / raw) To: bfoster; +Cc: xfs 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. Thanks, Jan _______________________________________________ xfs mailing list xfs@oss.sgi.com http://oss.sgi.com/mailman/listinfo/xfs ^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: XFS: false "torn write" errors (preventing mount) 2016-02-29 15:29 XFS: false "torn write" errors (preventing mount) Jan Beulich @ 2016-02-29 15:57 ` Brian Foster 2016-02-29 18:08 ` Brian Foster 0 siblings, 1 reply; 3+ messages in thread From: Brian Foster @ 2016-02-29 15:57 UTC (permalink / raw) To: Jan Beulich; +Cc: xfs 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... 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 ^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: XFS: false "torn write" errors (preventing mount) 2016-02-29 15:57 ` Brian Foster @ 2016-02-29 18:08 ` Brian Foster 0 siblings, 0 replies; 3+ messages in thread From: Brian Foster @ 2016-02-29 18:08 UTC (permalink / raw) To: Jan Beulich; +Cc: xfs 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 ^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2016-02-29 18:08 UTC | newest] Thread overview: 3+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2016-02-29 15:29 XFS: false "torn write" errors (preventing mount) Jan Beulich 2016-02-29 15:57 ` Brian Foster 2016-02-29 18:08 ` Brian Foster
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox