Clemens Eisserer posted on Sun, 13 Apr 2014 10:16:22 -0400 as excerpted: >> I also found this to be the case as I rebalanced the root filesystem of >> my Debian installation on this ThinkPad T520 on an Intel SSD 320. > > Same here, I ran balance on kernel-3.12 some time ago and after > balancing performance dropped noticeable and stayed there. > When booting natively I can see the HDD activity led lid for 10+ seconds > (Samsung 830 SSD), working with the same system in virtualbox using > direct device access is a real pain. > > Non of the measures I took (re-balance, fstrim, defraging all files on > the volume, ...) had mentionable impact. This one is a real mystery to me, and only recently came up on my radar as an issue people are seeing. It'd be interesting to get to the bottom of it as it's possible it has other bug and correctness implications as well. I've seen nothing like it here, but then my btrfs are all relatively small (under 50 gig each), and I don't tend to do much snapshotting or subvolumes, which might make a difference. Additionally, I don't have a lot of large "internal write" files such as databases and the like (not even the systemd journal file issue that some have reported, as while I recently switched to systemd, I deliberately chose to configure it to do tmpfs logs only to avoid that problem entirely, with all longer term logging going thru syslog-ng, which has more conventional append-only log files). But as I said, I'd sure like to get to the bottom of this one, since I do believe it has other potential implications in terms of bugs, etc. In theory, a balance should either not affect performance or should improve it, so getting to the bottom of why it's having such a bad performance impact for many really is something that needs to be done. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman -- 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