>>> The way btrfs is designed I'd actually expect shrinking to >>> be fast in most cases. [ ... ]
>> 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. > Isn't that too pessimistic? Maybe, it depends on the workload impacting the volume and how much it churns the free/unallocated situation. > Most of my filesystems have 90+% of free space unallocated, > even those I never run balance on. That seems quite lucky to me, as definitely is not my experience or even my expectation in the general case: in my laptop and desktop with relatively few updates I have to run 'balance' fairly frequently, and "Knorrie" has produced a nice tools that produces a graphical map of free vs. unallocated space and most examples and users find quite a bit of balancing needs to be done > For me it wouldn't just spread the cost, it would reduce it > considerably. In your case the cost of the implicit or explicit 'balance' simply does not arise because 'balance' is not necessary, and then moving whole chunks is indeed cheap. The argument here is in part whether used space (extents) or allocated space (chunks) is more fragmented as well as the amount of metadata to update in either case. -- 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
