On Sun, Jan 22, 2017 at 7:01 AM, Darrick J. Wong <darrick.wong@xxxxxxxxxx> wrote: > On Sat, Jan 21, 2017 at 09:38:23PM +0200, Amir Goldstein wrote: >> On Sat, Jan 21, 2017 at 10:10 AM, Darrick J. Wong >> <darrick.wong@xxxxxxxxxx> wrote: >> > Hi all, >> > >> > This is the fifth revision of a patchset that adds to XFS userland tools >> > support for online metadata scrubbing and repair. >> > >> > The new patches in this series do three things: first, they expand the >> > filesystem populate commands inside xfstests to be able to create all >> > types of XFS metadata. Second, they create a bunch of xfs_db wrapper >> > functions to iterate all fields present in a given metadata object and >> > fuzz them in various ways. Finally, for each metadata object type there >> > is a separate test that iteratively fuzzes all fields of that object and >> > runs it through the mount/scrub/repair loop to see what happens. >> > >> > If you're going to start using this mess, you probably ought to just >> > pull from my github trees for kernel[1], xfsprogs[2], and xfstests[3]. >> > The kernel patches in the git trees should apply to 4.10-rc4; xfsprogs >> > patches to for-next; and xfstest to master. >> > >> > The patches have survived all auto group xfstests both with scrub-only >> > mode and also a special debugging mode to xfs_scrub that forces it to >> > rebuild the metadata structures even if they're not damaged. >> > >> >> Darrick, >> >> xfs/1301 hogs every time at the same point in the test >> after Fuzz dirblklog = middlebit, those are the last words in dmesg: >> Log size 12800 blocks too small, minimum size is 23646 blocks >> XFS (dm-2): AAIEEE! Log failed size checks. Abort! >> XFS (dm-2): log mount failed > > Yeah.... there's some oddball problems in xfs_repair where directory > related corruption causes it to misread directory free space so when it > goes to add "unlinked" inodes to lost+found the process goes totally > nuts and/or deadlocks on buffers. I haven't had a chance to figure out > what's causing /this/ particular problem, though..... :( > So I guess you are able to reproduce this. Is there maybe a mode to run the tests where scrub will fix /this/ problem before running xfs_repair, so xfs_repair won't go off the rails? I had the impressions that this is what the scrub tests are supposed to do? -- To unsubscribe from this list: send the line "unsubscribe linux-xfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
