Joerg Schilling wrote:
Darren J Moffat <darr...@opensolaris.org> wrote:
use star from Jörg Schilling because its dead easy :
star -copy -p -acl -sparse -dump -C old_dir . new_dir
...
star doesn't (and shouldn't) create the destination ZFS filesystem like
the zfs recv would. It also doesn't preserve the dataset level would do.
As star is software that cleany lives above the filesystem layer, this is
what people would expect ;-)
Indeed but that is why the "extra steps" are needed to create the
destination ZFS filesystem. Not a bad thing or a criticism of star just
a fact (and in answer to the question you asked).
One the other hand using star (or rsync which is what I tend to do)
gives more flexibility in that the source and destination filesystem
types can be different or even not a filesystem!
star is highly optimized and it's build in find(1) (using libfind)
gives you many interesting features.
I'm sure the authors of rsync could make a similar statement :-)
zfs send seems to be tied to the zfs version and this is another reason
why zfs send | receive may not even work on a 100% zfs based playground.
Indeed but it isn't, like tar (and variants there of), an archiver but a
means of providing replication of ZFS datasets based on ZFS snapshots
and works at the ZFS DMU layer.
zfs send|recv and [g,s]tar exist for different purposes, but there are
some overlapping use cases either either could do the job.
It would be nice if there was a discussion that does mention features instead
of always proposing zfs send....
In general I completely agree, however this particular thread (given its
title) is about zfs send|recv :-)
--
Darren J Moffat
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
