Re: btrfs is using 25% more disk than it should

[Zygo Blaxell <ce3g8jdj@umail.furryterror.org>]

[-- Attachment #1: Type: text/plain, Size: 1813 bytes --]

On Sat, Dec 20, 2014 at 06:28:22AM -0500, Josef Bacik wrote:
> We now have two extents
> with the same bytenr but with different lengths.  
>[...]
> Then there is the problem of actually returning the free space.  Now
> if we drop all of the refs for an extent we know the space is free
> and we return it to the allocator.  With the above example we can't
> do that anymore, we have to check the extent tree for any area that
> is left overlapping the area we just freed.  This add's another
> search to every btrfs_free_extent operation, which slows the whole
> system down and again leaves us with weird corner cases and pain for
> the users.  Plus this would be an incompatible format change so
> would require setting a feature flag in the fs and rolled to
> voluntarily.

Ouchie.

> Now I have another solution, but I'm not convinced it's awesome
> either.  Take the same example above, but instead we split the
> original extent in the extent tree so we avoid all the mess of
> having overlapping ranges

Would this work for a read-only snapshot?  For a read-write snapshot
it would be as if we had modified both (or all, if there are multiple
snapshots) versions of the tree with split extents.

> This wouldn't require a format change so everybody would get
> this behaviour as soon as we turned it on

It could be a mount option, like autodefrag, off by default until the
bugs were worked out.

Arguably there could be a 'garbage-collection tool' similar to 'btrfs
fi defrag', that could be used to clean out any large partially-obscured
extents from specific files.  This might be important for deduplication
as well (although the extent-same code looks like it does split extents?).

Definitely something to think about.  Thanks for the detailed
explanations.


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]