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:
signature.asc
Description: Digital signature
