https://bugzilla.kernel.org/show_bug.cgi?id=216486 --- Comment #2 from Zorro Lang (zlang@xxxxxxxxxx) --- (In reply to Darrick J. Wong from comment #1) > On Wed, Sep 14, 2022 at 08:12:56AM +0000, bugzilla-daemon@xxxxxxxxxx wrote: > > https://bugzilla.kernel.org/show_bug.cgi?id=216486 > > > > Bug ID: 216486 > > Summary: [xfstests generic/447] xfs_scrub always complains fs > > corruption > > Product: File System > > Version: 2.5 > > Kernel Version: 6.0.0-rc4+ > > Hardware: All > > OS: Linux > > Tree: Mainline > > Status: NEW > > Severity: normal > > Priority: P1 > > Component: XFS > > Assignee: filesystem_xfs@xxxxxxxxxxxxxxxxxxxxxx > > Reporter: zlang@xxxxxxxxxx > > Regression: No > > > > Recently xfstests generic/447 always fails[1][2][3] on latest xfs kernel > with > > xfsprogs. It's reproducible on 1k blocksize and rmapbt enabled XFS (-b > > size=1024 -m rmapbt=1). Not sure if it's a kernel bug or a xfsprogs issue, > or > > an expected failure. > > It's an expected failure that is one of the many things fixed by the > online fsck patchset. The solution I came up with is described here: > https://djwong.org/docs/xfs-online-fsck-design/#eventual-consistency-vs- > online-fsck > > The TLDR is that scrub is probably racing with a thread that's in the > middle of doing a file mapping change that involves both an rmap and a > refcount update. This is possible because we don't hold the AGF buffer > between work items in a defer ops chain. Thanks Darrick, for your reply and confirmation! -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.
