We changed btrfs device add to check and see if there is an existing fs on the
device we are adding, so you now have to do -f if you want to do this. In order
to get around checking to see if we have this version of btrfs-progs just wipefs
the device we're adding to make sure the device add will pass no matter which
version of btrfs-progs you have. Thanks,
Signed-off-by: Josef Bacik <jbacik@fusionio.com>
Reviewed-by: Eric Sandeen <sandeen@redhat.com>
Signed-off-by: Rich Johnston <rjohnston@sgi.com>
Since common/config is executed twice, if SCRATCH_DEV_POOL is configured
via the environment, the current code removes the first device entry twice
which means that you lose the second device for the test.
The fix is to not remove anything from SCRATCH_DEV_POOL anymore.
That used to be done (I can only guess) to allow to pass the
SCRATCH_DEV_POOL as an argument to _scratch_mkfs. Since _scratch_mkfs adds
the SCRATCH_DEV, the pool mustn't contain that device anymore.
A new function _scratch_pool_mkfs is introduced that does the expected
thing.
Signed-off-by: Stefan Behrens <sbehrens@giantdisaster.de>
Reviewed-by: Josef Bacik <jbacik@fusionio.com>
Signed-off-by: Rich Johnston <rjohnston@sgi.com>
This test failed for me with output from 'btrfs balance':
QA output created by 003
+Done, had to relocate 4 out of 4 chunks
+Done, had to relocate 5 out of 5 chunks
Silence is golden
Signed-off-by: Stefan Behrens <sbehrens@giantdisaster.de>
Reviewed-by: Eric Sandeen <sandeen@redhat.com>
Signed-off-by: Rich Johnston <rjohnston@sgi.com>
Current numbering is inheried from the single testsuite series. There
are only 6 btrfs-specific tests and it makes more sense to start adding
new ones at a more natural place than 300-something. There's no overlap
with the old and new numbers and I hope there' will be no confusion when
referencing them.
Signed-off-by: David Sterba <dsterba@suse.cz>
Reviewed-by: Eric Sandeen <sandeen@redhat.com>
Signed-off-by: Rich Johnston <rjohnston@sgi.com>
Josef Bacik
Stefan Behrens
David Sterba