On 3/22/18 3:26 PM, Darrick J. Wong wrote: > >>> parsing error >>> field u not found >>> parsing error >> >> ... >> >> Switch back to the original behavior by turning off crcs, >> and catch such failures if they crop up again by looking >> for xfs_db errors in $seqres.full. >> >> Signed-off-by: Eric Sandeen <sandeen@xxxxxxxxxx> >> --- >> >> (is it horrific to grep $seqres.full? xfs_db doesn't exit >> with failure in this case :( ) >> >> and now this causes repair to fail on a verifier error, but >> I just sent an xfsprogs patch to fix that as well. >> >> diff --git a/tests/xfs/278 b/tests/xfs/278 >> index b94ee9c..c0e09c7 100755 >> --- a/tests/xfs/278 >> +++ b/tests/xfs/278 >> @@ -48,7 +48,7 @@ _supported_os Linux >> _require_scratch >> >> rm -f $seqres.full >> -_scratch_mkfs >$seqres.full 2>&1 >> +_scratch_mkfs -m crc=0 -n ftype=0 >$seqres.full 2>&1 > > This is still a problem on v5 filesystems, isn't it? ... but the above makes it V4, right? > >> _scratch_mount >> >> mkdir -p $SCRATCH_MNT/dir/subdir >> @@ -73,6 +73,8 @@ _scratch_xfs_db -x -c "inode $DIR_INO" -c "write core.nlinkv2 0" >> $seqres.ful >> _scratch_xfs_db -x -c "inode $SUBDIR_INO" -c "write u.sfdir2.hdr.parent.i4 0" >> $seqres.full > > So I think the problem here is that between v4 and v5 the field names > changed slightly? > > u.sfdir2.hdr.parent.i4 vs. u3.sfdir3.hdr.parent.i4? > > So we ought to be able to _scratch_xfs_get_metadata_field to see if the > v4 field name exists, then _scratch_xfs_set_metadata_field with the > appropriate name to set the field? > > ino_loc="inode $SUBDIR_INO" > if [ -n "$(_scratch_xfs_get_metadata_field "u.sfdir2.hdr.parent.i4" "$ino_loc" ]; then > _scratch_xfs_set_metadata_field "u.sfdir2.hdr.parent.i4" 0 "$ino_loc" > else > _scratch_xfs_set_metadata_field "u3.sfdir3.hdr.parent.i4" 0 "$ino_loc" > fi > > Or something like that. > yeah, could do, is it worth it? Trying to exercise repair's lost+found behavior, I'm not sure how valuable it is to add a bunch of code to handle every possible format to get to the same endpoint... My original plan was to just constrain the test to a known quantity to test the target functionality that way ... -Eric -- To unsubscribe from this list: send the line "unsubscribe fstests" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
