On Thu, Mar 17, 2016 at 11:44:29AM +0530, Chandan Rajendra wrote:
> The following scenario can occur when running btrfs/066,
>
> Task A Task B Task C
>
> run_test()
> - Execute _btrfs_stress_subvolume()
> in a background shell.
> _btrfs_stress_subvolme()
> ...
> - fork & exec "mount"
>
> Mount subvolume on directory in $TEST_DIR
> - Wait for fsstress to finish do_mount()
> - kill shell process executing -
> btrfs_mount()
> _btrfs_stress_subvolume()
> i.e. Task B.
> - Init process becomes the parent
> of "subvolume mount" task
> i.e. Task C.
> - In case subvolume is mounted
> (which is not the case),
> unmount it.
> - Complete
> mounting subvolume
>
> Hence on the completion of one iteration of run_test(), the subvolume
> created inside the filesystem on $SCRATCH_DEV continues to be mounted on
> $TEST_DIR/$seq.mnt. Subsequent invocations of run_test() (called for
> remaining Btrfs profile configs) fail during _scratch_pool_mkfs.
>
> Instead of killing the 'subvolume stress' task, This commit uses a named
> pipe to inform the 'subvolume stress' task to break out of the infinite
> loop and exit.
A named pipe seems too heavy and complicated to me. How about breaking
out the loop in _btrfs_stress_subvolume on the existence of some file?
e.g.
_btrfs_stress_subvolume():
...
local stop_file=$5
while [ ! -e $stop_file ]; do
...
done
run_test():
...
local stop_file=$TEST_DIR/$seq.stop.$$
...
# make sure the stop sign is not there
rm -f $stop_file
_btrfs_stress_subvolume $SCRATCH_DEV $SCRATCH_MNT subvol_$$ $subvol_mnt
$stop_file &
...
wait $fsstress_pid
touch $stop_file
kill $scrub_pid
wait
I didn't test it, as I can't reproduce the race, but I guess it should
work :)
Thanks,
Eryu
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
