On Tue, Sep 12, 2017 at 04:12:32PM -0400, Austin S. Hemmelgarn wrote: > On 2017-09-12 16:00, Adam Borowski wrote: > > Noted. Both Marat's and my use cases, though, involve VMs that are off most > > of the time, and at least for me, turned on only to test something. > > Touching mtime makes rsync run again, and it's freaking _slow_: worse than > > 40 minutes for a 40GB VM (source:SSD target:deduped HDD). > 40 minutes for 40GB is insanely slow (that's just short of 18 MB/s) if > you're going direct to a hard drive. I get better performance than that on > my somewhat pathetic NUC based storage cluster (I get roughly 20 MB/s there, > but it's for archival storage so I don't really care). I'm actually curious > what the exact rsync command you are using is (you can obviously redact > paths as you see fit), as the only way I can think of that it should be that > slow is if you're using both --checksum (but if you're using this, you can > tell rsync to skip the mtime check, and that issue goes away) and --inplace, > _and_ your HDD is slow to begin with. rsync -axX --delete --inplace --numeric-ids /mnt/btr1/qemu/ mordor:$BASE/qemu The target is single, compress=zlib SAMSUNG HD204UI, 34976 hours old but with nothing notable on SMART, in a Qnap 253a, kernel 4.9. Both source and target are btrfs, but here switching to send|receive wouldn't give much as this particular guest is Win10 Insider Edition -- a thingy that shows what the folks from Redmond have cooked up, with roughly weekly updates to the tune of ~10GB writes 10GB deletions (if they do incremental transfers, installation still rewrites everything system). Lemme look a bit more, rsync performance is indeed really abysmal compared to what it should be. Meow! -- ⢀⣴⠾⠻⢶⣦⠀ I've read an article about how lively happy music boosts ⣾⠁⢰⠒⠀⣿⡁ productivity. You can read it, too, you just need the ⢿⡄⠘⠷⠚⠋⠀ right music while doing so. I recommend Skepticism ⠈⠳⣄⠀⠀⠀⠀ (funeral doom metal). -- 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
