On Mon, Feb 03, 2014 at 11:22:36PM +0800, Wang Shilong wrote: > From: Wang Shilong <wangsl.fnst@xxxxxxxxxxxxxx> > > Btrfs would fail to send if snapshot run concurrently, this test is to make > sure we have fixed the bug. > Couple of comments below. > +_scratch_mkfs > /dev/null 2>&1 > +_scratch_mount > + > + > +touch $SCRATCH_MNT/foo > + > +# get file with fragments by using backwards writes. > +for i in `seq 10240 -1 1`; do > + $XFS_IO_PROG -f -d -c "pwrite $(($i * 4096)) 4096" \ > + $SCRATCH_MNT/foo > /dev/null | _filter_xfs_io Indentation. > +done > + > +$BTRFS_UTIL_PROG subvolume snapshot -r $SCRATCH_MNT \ > + $SCRATCH_MNT/snap_1 >> $seqres.full 2>&1 > + > +$BTRFS_UTIL_PROG send -f $SCRATCH_MNT/send_file \ > + $SCRATCH_MNT/snap_1 >> $seqres.full 2>&1 & > + > +pid=$! > + > +$BTRFS_UTIL_PROG subvolume snapshot -r $SCRATCH_MNT/snap_1 \ > + $SCRATCH_MNT/snap_2 >> $seqres.full 2>&1 > + > +wait $pid || echo "Failed to send, see dmesg" This seems kind of racy. It assumes that the send command doesn't complete before the wait $pid call is made. If $pid doesn't exist at this time because it has completed, wait will return 127 and the test will fail.... Also, why would a failure to send result in meaingful information in dmesg? Shouldn't the userspace command output information to tell you why there was a failure into $seqres.full? Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
