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 ;-)
> 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.
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.
> 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....
Jörg
--
EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
j...@cs.tu-berlin.de (uni)
joerg.schill...@fokus.fraunhofer.de (work) Blog:
http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
