Łukasz K wrote:
> Hello Matthew,
>
>I have problems with pool fragmentation.
> http://www.opensolaris.org/jive/thread.jspa?threadID=34810
>
> Now I want to speed up zfs send, because our pool space maps are
> huge - after sending space maps will be smaller ( from 1GB -> 50MB ).
>
> As I unde
Łukasz wrote:
>> 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"
>
> When do you think it will be available ?
Perhaps by the end of the calendar year, but perhaps longer. Maybe sooner
if you wo
> > Ł> 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
> 1
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
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.
Ł> I want to parallize zfs
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.
I want to parallize zfs send to make it faster.
dmu_sendbackup could allocate buffer, that will be u
