>> As a general consideration, shrinking a large filetree online >> in-place is an amazingly risky, difficult, slow operation and >> should be a last desperate resort (as apparently in this case), >> regardless of the filesystem type, and expecting otherwise is >> "optimistic".
> The way btrfs is designed I'd actually expect shrinking to be > fast in most cases. It could probably be done by moving whole > chunks at near platter speed, [ ... ] It just hasn't been > implemented yet. That seems to me a rather "optimistic" argument, as most of the cost of shrinking is the 'balance' to pack extents into chunks. As that thread implies, the current implementation in effect does a "balance" while shrinking, by moving extents from chunks "above the line" to free space in chunks "below the line". The proposed "move whole chunks" implementation helps only if there are enough unallocated chunks "below the line". If regular 'balance' is done on the filesystem there will be some, but that just spreads the cost of the 'balance' across time, it does not by itself make a «risky, difficult, slow operation» any less so, just spreads the risk, difficulty, slowness across time. More generally one of the downsides of Btrfs is that because of its two-level (allocated/unallocated chunks, used/free nodes or blocks) design it requires more than most other designs to do regular 'balance', which is indeed «risky, difficult, slow». Compare an even more COW design like NILFS2, which requires, but a bit less, to run its garbage collector, which is also «risky, difficult, slow». Just like in Btrfs that is a tradeoff that shrinks the performance envelope in one direction and expands it in another. But in the case of Btrfs it shrinks it perhaps a bit more than it expands it, as the added flexibility of having chunk-based 'profiles' is only very partially taken advantage of. -- 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
