On Tue, May 17, 2016 at 2:27 PM, Goni Zahavy <goni1993@xxxxxxxxx> wrote: > Guys, just remember that this crappy-installer behavior works "as-expected" > on every other filesystem. It also fails as expected on every other file system if the upgrade is interrupted for reasons that have nothing to do with the file system; what's in common is the lack of a fail safe upgrade design. And this is not a ding on Ubuntu, it's a widespread and well recognized risk. All that's happening here is Btrfs has one more vector to expose that deficiency. > I think we need to treat this as a trigger to unwanted/unexpected behavior > on btrfs's part, especially in this "dead-simple" setup, in order for us to > gain a bug/behavior fix in the near future. There are work arounds: use -M when creating the file system, accepting some loss of performance and inline small file packing efficiency; run a preemptive filtered balance on a timer. Fixing it in the kernel is a great idea, but if that were trivial I think it'd have been done by now. It's not like this problem is unknown on this list. > In my opinion, we simply cannot "blame" the user/installer code in the > current state of btrfs especially in the "considered stable enough" feature > sets. OK blame was the wrong word for me to use, but the root cause of the problem is shared. I agree the user is least to blame, but so long as the status of the fs overall is benchmarking and review it's difficult to say the user has no role whatsoever in helping prevent it, as tedious as that is. -- Chris Murphy -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
