On Sun, Oct 29, 2023 at 12:33:33PM +0800, Zorro Lang wrote: > Hi xfs folks, > > Besides https://lore.kernel.org/linux-xfs/20231029041122.bx2k7wwm7otebjd5@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx/T/#u , > > I always hit another failure on s390x too, by running generic/039 or generic/065 [1]: g/039 is a sync + fsync + flakey remount+recovery test. g/065 is a similar by more complex test. So that's 3 fsync + shutdown/recovery tests on s390 that are now failing with ip->i_nblocks not matching the extent tree state after fsync-shutdown-recover. > > XFS: Assertion failed: ip->i_nblocks == 0, file: fs/xfs/xfs_inode.c, line: 2359 > > More details as dmesg output [2] and .full output [3]. > > And ... more other kind of failure likes [3]: > XFS: Assertion failed: error != -ENOENT, file: fs/xfs/xfs_trans.c, line: 1310 ANd that one is from g/509 after a quotacheck is completed and then the fs is shutdown, resulting in dquots not being found after the journal has been recovered and unlinked list recovery is being run. i.e. unlinked list processing is tripping over missing file data extents after recovery. > All these falures are on s390x only... and more xfs corruption failure by running > fstests on s390x. I don't know if it's a s390x issue or a xfs issue on big endian > machine (s390x), so cc s390x list. IOWs, all four of these issues are the same problem - journal recovery is not resulting in a correct and consistent filesystem after the journal has been flushed at runtime, so please discuss and consolidate them all in the initial bug report thread.... Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx
