On Thu, Jan 12, 2017 at 10:01:54AM +0200, Amir Goldstein wrote: > On Wed, Jan 11, 2017 at 7:32 PM, Darrick J. Wong > <darrick.wong@xxxxxxxxxx> wrote: > > On Wed, Jan 11, 2017 at 12:01:22PM +0200, Amir Goldstein wrote: > >> On Wed, Jan 11, 2017 at 10:34 AM, Amir Goldstein <amir73il@xxxxxxxxx> wrote: > >> > On Tue, Jan 10, 2017 at 9:42 PM, Darrick J. Wong > >> > <darrick.wong@xxxxxxxxxx> wrote: > >> >> xfs_db doesn't check the filesystem geometry when it's mounting, which > >> >> means that garbage agcount values can cause OOMs when we try to allocate > >> >> all the per-AG incore metadata. If we see geometry that looks > >> >> suspicious, try to derive the actual AG geometry to avoid crashing the > >> >> system. This should help with xfs/1301 fuzzing. > >> >> > >> >> Also fix up xfs_repair to use the min/max dblocks macros. > >> >> > >> >> Signed-off-by: Darrick J. Wong <darrick.wong@xxxxxxxxxx> > >> > > >> > Test machine is back to health with this patch, but some test are failing due > >> > to the new error messages. > >> > I guess its no surprise to you. > >> > > >> > > >> > xfs/1300 5s ... 5s > >> > xfs/1301 - output mismatch (see > >> > /home/amir/src/xfstests-dev/results//xfs/1301.out.bad) > >> > --- tests/xfs/1301.out 2017-01-08 15:35:07.647897359 +0200 > >> > +++ /home/amir/src/xfstests-dev/results//xfs/1301.out.bad > >> > 2017-01-11 09:58:10.981678272 +0200 > >> > @@ -1,4 +1,61 @@ > >> > QA output created by 1301 > >> > Format and populate > >> > Fuzz superblock > >> > +xfs_db: device /dev/mapper/storage-scratch AG geometry is insane. > >> > Using agcount=4. > >> > +SB sanity check failed > >> > +Metadata corruption detected at xfs_sb block 0x0/0x200 > >> > +xfs_db: device /dev/mapper/storage-scratch AG geometry is insane. > >> > Using agcount=4. > >> > ... > >> > (Run 'diff -u tests/xfs/1301.out > >> > /home/amir/src/xfstests-dev/results//xfs/1301.out.bad' to see the > > > > Uh.... this is odd, all that stuff should go into 1301.full. > > > > Darrick, > > I see that you went down the problematic path of redirecting input to > interactive xfs_db shell. > > I say problematic, because I went down that path with xfs_io when > I wrote test overlay/016, because xfs_io -c "open foo" was broken: > http://www.spinics.net/lists/fstests/msg04526.html > > What I found out is that on some systems, the "xfs_io>" echo appears > in output and on some systems it does not. It is not related to xfs_io > itself, but to something else in the environment, presumably, the shell > or the terminal? > I was running the same test with same version of xfs_io on > debian Jessie inside kvm-xfstests and on Ubuntu 16.04 (ssh+tmux) > and got different results. I get the feeling this could be related to readline -- on my systems I build with libreadline6-dev installed and configure picks it up. ISTR if configure doesn't find a libreadline xfs_db'll do things a little differently wrt printing the prompt... and that might be why you see stray "xfs_db>" and I don't. Or maybe you're linking against a different version, or... ugh, what a mess. > Can you rearrange all the fuzzy helpers to use xfs_db -c instead of > redirecting stdin to xfs_db? I changed the tests to dump commands to a file and run: _scratch_xfs_db -c "source $seqres.cmd" but then discovered that the source command is just plain broken when invoked via -c, so I fixed that. Then I noticed that you changed common/fuzzy to use a bash array and sent the patch to me, and now I'm wondering if that's a better solution than making tempfiles everywhere. > Regarding xfs/1301, all output from xfs_db should go to 1301.full, so > the existence of the "xfs_db>" prompt is probably not important, but > perhaps there are other factors in play which cause stderr from xfs_db > to get to 1301.out.bad on my system. > I must say that I looked to see where in xfs/1301 or in common/fuzzy > you redirect stderr to stdout and didn't find it. /me is confused; there should be a bunch of places where stderr gets redirected to stdout. $ grep '2>' common/fuzzy -n 32: find "${SCRATCH_MNT}/" -type f 2> /dev/null | head -n "${nr}" | while read f; do 52: ls -laR "${SCRATCH_MNT}/test.1/" >/dev/null 2>&1 55: (find "${SCRATCH_MNT}/test.1/" -type f -size -1048576k -print0 | xargs -0 cat) >/dev/null 2>&1 180: newval="$(_scratch_xfs_get_metadata_field "${key}" "$@" 2> /dev/null)" 191: while _scratch_unmount 2>/dev/null; do sleep 0.2; done 227: _scratch_mount 2>&1 231: _scratch_scrub -n -a 1 -e continue 2>&1 239: _scratch_scrub -y 2>&1 253: _repair_scratch_fs 2>&1 261: _scratch_xfs_repair -n 2>&1 268: _scratch_mount 2>&1 271: _scratch_scrub -e continue 2>&1 278: _scratch_fuzz_modify 100 2>&1 286: _scratch_xfs_repair -n 2>&1 298: _scratch_mkfs_xfs >/dev/null 2>&1 Sorry this has been such a mess. :/ --D > Please enlighten me. > > Amir. -- 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
