On Tue, Jun 30, 2015 at 4:14 PM, David Sterba <dste...@suse.cz> wrote: > On Mon, Jun 29, 2015 at 05:15:12PM +0100, Filipe Manana wrote: >> On Mon, Jun 29, 2015 at 4:42 PM, David Sterba <dste...@suse.cz> wrote: >> > On Wed, Jun 17, 2015 at 12:44:55PM +0100, fdman...@kernel.org wrote: >> > The test fails after I do this before unmount: >> > >> > $SUDO_HELPER $TOP/btrfs balance start -mconvert=single -sconvert=single -f >> > $TEST_MNT >> > shrink_test >> >> Where are you doing this exactly? >> >> Just tried the following: https://friendpaste.com/2U7C4gBBLBjo4e2v1ZnJP2 > > Like in the the first part of the diff. > >> > Output: >> > >> > ############### root_helper ../btrfs filesystem resize get_min_size >> > ../tests/mnt >> > 6480199680 bytes (6.04GiB) >> > min size = 6480199680 >> > ############### root_helper ../btrfs filesystem resize 6480199680 >> > ../tests/mnt >> > ERROR: unable to resize '../tests/mnt' - No space left on device >> > Resize '../tests/mnt' of '6480199680' >> > >> > Last successful resize before this was: >> > Resize '../tests/mnt' of '7553941504' >> >> And it didn't fail for me on a 4.1 kernel at least. It produced those >> 2 sizes as well, but it didn't fail for any of them. > > The test was run on 4.0.5, I'm building a clean 4.1 + integration to > verify it there.
Nevermind, I managed to reproduce it but by placing the balance/convert before the loop that tests the shrinking. btrfs_can_relocate() returns 0, meaning relocation should succeed if no other allocations happen in parallel, which is the case here, but btrfs_relocate_block_group() fails with ENOSPC - one of this functions isn't working as it should, I'll check what's going on soon. thanks -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
