2017-09-13 0:13 GMT+03:00 Adam Borowski <kilob...@angband.pl>: > 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 majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html
No, no, no, no... No new ioctl, no change in fallocate. Fisrt: VM can do punch hole, if you use qemu -> qemu know how to do it. Windows Guest also know how to do it. Different Hypervisor? -> google -> Make issue to support, all Linux/Windows/Mac OS support holes in files. No new code, no new strange stuff to fix not broken things. You want replace zeroes? EXTENT_SAME can do that. truncate -s 4M test_hole dd if=/dev/zero of=./test_zero bs=4M duperemove -vhrd ./test_hole ./test_zero ~ du -hs test_* 0 test_hole 0 test_zero -- Have a nice day, Timofey. -- 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
