Robert Milkowski wrote: > Hello Łukasz, > > Monday, July 23, 2007, 1:19:16 PM, you wrote: > > Ł> ZFS send is very slow. > Ł> dmu_sendbackup function is traversing dataset in one thread and in > Ł> traverse callback function ( backup_cb ) we are waiting for data in > Ł> arc_read called with ARC_WAIT flag.
That's correct. > Ł> I want to parallize zfs send to make it faster. > Ł> dmu_sendbackup could allocate buffer, that will be used for buffering > output. > Ł> Few threads can traverse dataset, few threads would be used for async read > operations. > > Ł> I think it could speed up zfs send operation 10x. > > Ł> What do you think about it ? You're right that we need to issue more i/os in parallel -- see 6333409 "traversal code should be able to issue multiple reads in parallel" However, it may be much more straightforward to just issue prefetches appropriately, rather than attempt to coordinate multiple threads. That said, feel free to experiment. > I guess you should check with Matthew Ahrens as IIRC he's working on > 'zfs send -r' and possibly some other improvements to zfs send. The > question is what code changes Matthew has done so far (it hasn't been > integrated AFAIK) and possibly work from there. Or perhaps Matthew is > already working on it also... Unfortunately I am not working on this bug as part of my "zfs send -r" changes. But I plan to work on it (unless you get to it first!) later this year as part of the pool space reduction changes. > Also I guess you'll have to write all transactions to the other end > (zfs recv) in the same order they were created on disk,or not? Nope, that's (one of) the beauty of zfs send. --matt _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
