zfs discuss - Mar 2009 - is zpool export/import | faster than rsync or cp

I need to move data from one zpool to another, lock stock and
barrel,

Being from linux background my instinct was to use rsync.  But then I
remembered seeing the `export/import options in man zpool..  And I''ve
seen mention of them here too, but didn''t pay attention since
I''d
noticed no need yet.

Now I''m wondering if the export/import sub commands might not be a
good bit faster.  

I''m not talking about massive amounts of data, about 71 GB, but enough
that rsync will be at it a good while.

I''ve can anyone tell me if the export/import approach would be better?

Harry Putnam wrote:
> I need to move data from one zpool to another, lock stock and
> barrel,
>
> Being from linux background my instinct was to use rsync.  But then I
> remembered seeing the `export/import options in man zpool..  And
I''ve
> seen mention of them here too, but didn''t pay attention since
I''d
> noticed no need yet.
>
> Now I''m wondering if the export/import sub commands might not be a
> good bit faster.  
>
>   
I think you are thinking of zfs send/receive.

I''ve never done a direct comparison, but zfs send/receive would be my 
preferred way to move data between pools.

-- 
Ian.

On Sat, Mar 28, 2009 at 5:05 AM, Harry Putnam <reader at newsguy.com>
wrote:
> Now I''m wondering if the export/import sub commands might not be a
> good bit faster.
I believe the greatest advantage of zfs send/receive over rsync is not
about speed, but rather it''s on "zfs send -R", which would
(from man
page)

             Generate a replication stream  package,  which  will
             replicate  the specified filesystem, and all descen-
             dant file systems, up to the  named  snapshot.  When
             received, all properties, snapshots, descendent file
             systems, and clones are preserved.

pretty much allows you to clone a complete pool preserving its structure.
As usual, compressing the backup stream (whether rsync or zfs) might
help reduce transfer time a lot. My favorite is lzop (since it''s very
fast), but gzip should work as well.

Regards,

Fajar

Hello Harry,

Friday, March 27, 2009, 10:05:50 PM, you wrote:

HP> I need to move data from one zpool to another, lock stock and
HP> barrel,

HP> Being from linux background my instinct was to use rsync.  But then I
HP> remembered seeing the `export/import options in man zpool..  And
I''ve
HP> seen mention of them here too, but didn''t pay attention since
I''d
HP> noticed no need yet.

HP> Now I''m wondering if the export/import sub commands might not be
a
HP> good bit faster.  

HP> I''m not talking about massive amounts of data, about 71 GB, but
enough
HP> that rsync will be at it a good while.

HP> I''ve can anyone tell me if the export/import approach would be
better?

As Ian pointed you want zfs send|receive and not import/export.
For a first full copy zfs send not necessarily will be noticeably
faster than rsync but it depends on data. If for example you have
milions of small files zfs send could be much faster then rsync.
But it shouldn''t be slower in any case.

zfs send|receive really shines when it comes to sending incremental
changes.


-- 
Best regards,
 Robert Milkowski
                                       http://milek.blogspot.com

[...]

Harry wrote:
>> Now I''m wondering if the export/import sub commands might not
be a
>> good bit faster.  
>>
Ian Collins <ian at ianshome.com> answered:   
> I think you are thinking of zfs send/receive.
>
> I''ve never done a direct comparison, but zfs send/receive would be
my
> preferred way to move data between pools.
Why is that?  I''m too new to know what all it encompasses (and a bit
dense to boot)

"Fajar A. Nugraha" <fajar at fajar.net> writes:
> On Sat, Mar 28, 2009 at 5:05 AM, Harry Putnam <reader at newsguy.com>
wrote:
>> Now I''m wondering if the export/import sub commands might not
be a
>> good bit faster.
>
> I believe the greatest advantage of zfs send/receive over rsync is not
> about speed, but rather it''s on "zfs send -R", which
would (from man
> page)
>
>              Generate a replication stream  package,  which  will
>              replicate  the specified filesystem, and all descen-
>              dant file systems, up to the  named  snapshot.  When
>              received, all properties, snapshots, descendent file
>              systems, and clones are preserved.
>
> pretty much allows you to clone a complete pool preserving its structure.
> As usual, compressing the backup stream (whether rsync or zfs) might
> help reduce transfer time a lot. My favorite is lzop (since it''s
very
> fast), but gzip should work as well.
>
Nice... good reasons it appears.


Robert Milkowski <milek at task.gda.pl> writes:
> Hello Harry,
[...]
> As Ian pointed you want zfs send|receive and not import/export.
> For a first full copy zfs send not necessarily will be noticeably
> faster than rsync but it depends on data. If for example you have
> milions of small files zfs send could be much faster then rsync.
> But it shouldn''t be slower in any case.
>
> zfs send|receive really shines when it comes to sending incremental
> changes.
Now that would be something to make it stand out.  Can you tell me a
bit more about that would work..I mean would you just keep receiving
only changes at one end and how do they appear on the filesystem.

There is a backup tool called `rsnapshot'' that uses rsync but creates
hard links to all unchanged files and moves only changes to changed
files.  This is all put in a serial directory system and ends up
taking a tiny fraction of the space that full backups would take, yet
retains a way to get to unchanged files right in the same directory
(the hard link).

Is what your talking about similar in some way.

=====     *     =====     *     =====     *     ==== 
To all posters... many thanks for the input.

ZFS replication basics at http://cuddletech.com/blog/pivot/entry.php?id=984
Regards

On Sat, Mar 28, 2009 at 1:57 AM, Harry Putnam <reader at newsguy.com>
wrote:
>
> [...]
>
> Harry wrote:
> >> Now I''m wondering if the export/import sub commands might
not be a
> >> good bit faster.
> >>
> Ian Collins <ian at ianshome.com> answered:
> > I think you are thinking of zfs send/receive.
> >
> > I''ve never done a direct comparison, but zfs send/receive
would be my
> > preferred way to move data between pools.
>
> Why is that?  I''m too new to know what all it encompasses (and a
bit
> dense to boot)
>
> "Fajar A. Nugraha" <fajar at fajar.net> writes:
>
> > On Sat, Mar 28, 2009 at 5:05 AM, Harry Putnam <reader at
newsguy.com>
> wrote:
> >> Now I''m wondering if the export/import sub commands might
not be a
> >> good bit faster.
> >
> > I believe the greatest advantage of zfs send/receive over rsync is not
> > about speed, but rather it''s on "zfs send -R",
which would (from man
> > page)
> >
> >              Generate a replication stream  package,  which  will
> >              replicate  the specified filesystem, and all descen-
> >              dant file systems, up to the  named  snapshot.  When
> >              received, all properties, snapshots, descendent file
> >              systems, and clones are preserved.
> >
> > pretty much allows you to clone a complete pool preserving its
structure.
> > As usual, compressing the backup stream (whether rsync or zfs) might
> > help reduce transfer time a lot. My favorite is lzop (since
it''s very
> > fast), but gzip should work as well.
> >
>
> Nice... good reasons it appears.
>
>
> Robert Milkowski <milek at task.gda.pl> writes:
>
> > Hello Harry,
>
> [...]
>
> > As Ian pointed you want zfs send|receive and not import/export.
> > For a first full copy zfs send not necessarily will be noticeably
> > faster than rsync but it depends on data. If for example you have
> > milions of small files zfs send could be much faster then rsync.
> > But it shouldn''t be slower in any case.
> >
> > zfs send|receive really shines when it comes to sending incremental
> > changes.
>
> Now that would be something to make it stand out.  Can you tell me a
> bit more about that would work..I mean would you just keep receiving
> only changes at one end and how do they appear on the filesystem.
>
> There is a backup tool called `rsnapshot'' that uses rsync but
creates
> hard links to all unchanged files and moves only changes to changed
> files.  This is all put in a serial directory system and ends up
> taking a tiny fraction of the space that full backups would take, yet
> retains a way to get to unchanged files right in the same directory
> (the hard link).
>
> Is what your talking about similar in some way.
>
> =====     *     =====     *     =====     *     ====>
> To all posters... many thanks for the input.
>
> _______________________________________________
> zfs-discuss mailing list
> zfs-discuss at opensolaris.org
> http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://mail.opensolaris.org/pipermail/zfs-discuss/attachments/20090328/3ac2fc38/attachment.html>

zfs send/recv *is* faster (especially since b105) than rsync,
especially when you are dealing with lots of small files.  rsync has
to check each file, which can take a long time - zfs send/recv just
moves blocks.

2009/3/27 Ahmed Kamal <email.ahmedkamal at
googlemail.com>:
> ZFS replication basics at http://cuddletech.com/blog/pivot/entry.php?id=984
> Regards
>
> On Sat, Mar 28, 2009 at 1:57 AM, Harry Putnam <reader at newsguy.com>
wrote:
>>
>> [...]
>>
>> Harry wrote:
>> >> Now I''m wondering if the export/import sub commands
might not be a
>> >> good bit faster.
>> >>
>> Ian Collins <ian at ianshome.com> answered:
>> > I think you are thinking of zfs send/receive.
>> >
>> > I''ve never done a direct comparison, but zfs send/receive
would be my
>> > preferred way to move data between pools.
>>
>> Why is that? ?I''m too new to know what all it encompasses (and
a bit
>> dense to boot)
>>
>> "Fajar A. Nugraha" <fajar at fajar.net> writes:
>>
>> > On Sat, Mar 28, 2009 at 5:05 AM, Harry Putnam <reader at
newsguy.com>
>> > wrote:
>> >> Now I''m wondering if the export/import sub commands
might not be a
>> >> good bit faster.
>> >
>> > I believe the greatest advantage of zfs send/receive over rsync is
not
>> > about speed, but rather it''s on "zfs send -R",
which would (from man
>> > page)
>> >
>> > ? ? ? ? ? ? ?Generate a replication stream ?package, ?which ?will
>> > ? ? ? ? ? ? ?replicate ?the specified filesystem, and all descen-
>> > ? ? ? ? ? ? ?dant file systems, up to the ?named ?snapshot. ?When
>> > ? ? ? ? ? ? ?received, all properties, snapshots, descendent file
>> > ? ? ? ? ? ? ?systems, and clones are preserved.
>> >
>> > pretty much allows you to clone a complete pool preserving its
>> > structure.
>> > As usual, compressing the backup stream (whether rsync or zfs)
might
>> > help reduce transfer time a lot. My favorite is lzop (since
it''s very
>> > fast), but gzip should work as well.
>> >
>>
>> Nice... good reasons it appears.
>>
>>
>> Robert Milkowski <milek at task.gda.pl> writes:
>>
>> > Hello Harry,
>>
>> [...]
>>
>> > As Ian pointed you want zfs send|receive and not import/export.
>> > For a first full copy zfs send not necessarily will be noticeably
>> > faster than rsync but it depends on data. If for example you have
>> > milions of small files zfs send could be much faster then rsync.
>> > But it shouldn''t be slower in any case.
>> >
>> > zfs send|receive really shines when it comes to sending
incremental
>> > changes.
>>
>> Now that would be something to make it stand out. ?Can you tell me a
>> bit more about that would work..I mean would you just keep receiving
>> only changes at one end and how do they appear on the filesystem.
>>
>> There is a backup tool called `rsnapshot'' that uses rsync but
creates
>> hard links to all unchanged files and moves only changes to changed
>> files. ?This is all put in a serial directory system and ends up
>> taking a tiny fraction of the space that full backups would take, yet
>> retains a way to get to unchanged files right in the same directory
>> (the hard link).
>>
>> Is what your talking about similar in some way.
>>
>> ===== ? ? * ? ? ===== ? ? * ? ? ===== ? ? * ? ? ====>>
>> To all posters... many thanks for the input.
>>
>> _______________________________________________
>> zfs-discuss mailing list
>> zfs-discuss at opensolaris.org
>> http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
>
>
> _______________________________________________
> zfs-discuss mailing list
> zfs-discuss at opensolaris.org
> http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
>
>

Hi Harry,

I was on vacation so am late to this discussion.

For this part of your question:

The zpool export/import feature is a pool-level operation for moving
the pool, disks, and data to another system.

For moving data from one pool to another pool, you would want to use
zfs send/recv, rsync, or tar, and so on.

Cindy

Harry Putnam wrote:
> [...]
> 
> Harry wrote:
> 
>>>Now I''m wondering if the export/import sub commands might
not be a
>>>good bit faster.  
>>>
> 
> Ian Collins <ian at ianshome.com> answered:   
> 
>>I think you are thinking of zfs send/receive.
>>
>>I''ve never done a direct comparison, but zfs send/receive would
be my
>>preferred way to move data between pools.
> 
> 
> Why is that?  I''m too new to know what all it encompasses (and a
bit
> dense to boot)
> 
> "Fajar A. Nugraha" <fajar at fajar.net> writes:
> 
> 
>>On Sat, Mar 28, 2009 at 5:05 AM, Harry Putnam <reader at
newsguy.com> wrote:
>>
>>>Now I''m wondering if the export/import sub commands might
not be a
>>>good bit faster.
>>
>>I believe the greatest advantage of zfs send/receive over rsync is not
>>about speed, but rather it''s on "zfs send -R", which
would (from man
>>page)
>>
>>             Generate a replication stream  package,  which  will
>>             replicate  the specified filesystem, and all descen-
>>             dant file systems, up to the  named  snapshot.  When
>>             received, all properties, snapshots, descendent file
>>             systems, and clones are preserved.
>>
>>pretty much allows you to clone a complete pool preserving its
structure.
>>As usual, compressing the backup stream (whether rsync or zfs) might
>>help reduce transfer time a lot. My favorite is lzop (since
it''s very
>>fast), but gzip should work as well.
>>
> 
> 
> Nice... good reasons it appears.
> 
> 
> Robert Milkowski <milek at task.gda.pl> writes:
> 
> 
>>Hello Harry,
> 
> 
> [...]
> 
> 
>>As Ian pointed you want zfs send|receive and not import/export.
>>For a first full copy zfs send not necessarily will be noticeably
>>faster than rsync but it depends on data. If for example you have
>>milions of small files zfs send could be much faster then rsync.
>>But it shouldn''t be slower in any case.
>>
>>zfs send|receive really shines when it comes to sending incremental
>>changes.
> 
> 
> Now that would be something to make it stand out.  Can you tell me a
> bit more about that would work..I mean would you just keep receiving
> only changes at one end and how do they appear on the filesystem.
> 
> There is a backup tool called `rsnapshot'' that uses rsync but
creates
> hard links to all unchanged files and moves only changes to changed
> files.  This is all put in a serial directory system and ends up
> taking a tiny fraction of the space that full backups would take, yet
> retains a way to get to unchanged files right in the same directory
> (the hard link).
> 
> Is what your talking about similar in some way.
> 
> =====     *     =====     *     =====     *     ====>  
> To all posters... many thanks for the input.
> 
> _______________________________________________
> zfs-discuss mailing list
> zfs-discuss at opensolaris.org
> http://mail.opensolaris.org/mailman/listinfo/zfs-discuss