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.ahmedka...@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 <rea...@newsguy.com> wrote: >> >> [...] >> >> Harry wrote: >> >> Now I'm wondering if the export/import sub commands might not be a >> >> good bit faster. >> >> >> Ian Collins <i...@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" <fa...@fajar.net> writes: >> >> > On Sat, Mar 28, 2009 at 5:05 AM, Harry Putnam <rea...@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 <mi...@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@opensolaris.org >> http://mail.opensolaris.org/mailman/listinfo/zfs-discuss > > > _______________________________________________ > zfs-discuss mailing list > zfs-discuss@opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/zfs-discuss > > _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
