On Tue, Aug 9, 2022 at 8:25 AM Christian Weisgerber <na...@mips.inka.de> wrote:
> Moving 9TB with dump|restore from an old hard disk to a bigger one > reminded me again that dump(8) is, well, slow: > > DUMP: 9104433830 tape blocks > DUMP: Date of this level 0 dump: Sat Aug 6 16:36:52 2022 > ... > DUMP: Date this dump completed: Tue Aug 9 13:51:01 2022 > DUMP: Average transfer rate: 36530 KB/s > In my experience, dump(8) runs up to twice as fast if you use the "-b 64" option, unless you hit a hardware bottleneck first. I haven't tested lately, but two years ago I was getting these results dumping a 1TB volume from a 4-drive hardware RAID10 array to various destinations: 096724 KB/s /dev/null 199562 KB/s /dev/null (-b 64) 046365 KB/s LTO4 SAS 056925 KB/s LTO4 SAS (-b 64) 088129 KB/s LTO4 SAS external (-b 64) 050710 KB/s LTO5 FC 8Gbps 101542 KB/s LTO5 FC 8Gbps (-b 64) Are you certain that dump(8) is the big bottleneck here? My recollection is that restore(8) is significantly slower, so of course if restore(8) is slow reading from the pipe then whatever is writing to the pipe at the other end will stall. -ken
