On Wed, Oct 09, 2024 at 10:04:51AM +0200, Christoph Hellwig wrote: > On Tue, Oct 08, 2024 at 12:28:37PM -0400, Brian Foster wrote: > > FWIW, here's a quick hack at such a test. This is essentially a copy of > > xfs/104, tweaked to remove some of the output noise and whatnot, and > > hacked in some bits from generic/388 to do a shutdown and mount cycle > > per iteration. > > > > I'm not sure if this reproduces your original problem, but this blows up > > pretty quickly on 6.12.0-rc2. I see a stream of warnings that start like > > this (buffer readahead path via log recovery): > > > > [ 2807.764283] XFS (vdb2): xfs_buf_map_verify: daddr 0x3e803 out of range, EOFS 0x3e800 > > [ 2807.768094] ------------[ cut here ]------------ > > [ 2807.770629] WARNING: CPU: 0 PID: 28386 at fs/xfs/xfs_buf.c:553 xfs_buf_get_map+0x184e/0x2670 [xfs] > > > > ... and then end up with an unrecoverable/unmountable fs. From the title > > it sounds like this may be a different issue though.. hm? > > That's at least the same initial message I hit. > > Ok, so then what happened? :) Are there outstanding patches somewhere to fix this problem? If so, I can give it a test with this. I'm also trying to figure out if the stress level of this particular test should be turned up a notch or three, but I can't really dig into that until this initial variant is passing reliably. Brian
