On 2018-02-21 10:56, Hans van Kranenburg wrote:
On 02/21/2018 04:19 PM, Ellis H. Wilson III wrote:
$ sudo btrfs fi df /mnt/btrfs
Data, single: total=3.32TiB, used=3.32TiB
System, DUP: total=8.00MiB, used=384.00KiB
Metadata, DUP: total=16.50GiB, used=15.82GiB
GlobalReserve, single: total=512.00MiB, used=0.00B
Ah, so allocated data space is 100% filled with data. That's very good
yes. And it explains why you can't lower the amount of chunks by
balancing. You're just moving around data and replacing full chunks with
new full chunks. :]
Doesn't explain why it blows up the size of the extent tree though. I
have no idea why that is.
This is just a guess, but I think it might have reordered extents within
each chunk. Any given extent can't span across a chunk boundary, so if
the order changed, it may have split extents that had previously been
full extents. I'd be somewhat curious to see if defragmenting might
help here (it should re-combine the split extents, though it will
probably allocate a new chunk).
--
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
