> 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, instead of extent-by-extent as it is done now, as long as there is enough free space. There was a discussion about it already: http://www.spinics.net/lists/linux-btrfs/msg38608.html. It just hasn't been implemented yet. -- 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
