On 19.10.2012 13:53, Joerg Schilling wrote: > Arne Jansen <sensi...@gmx.net> wrote: > >> On 19.10.2012 12:17, Joerg Schilling wrote: >>> Arne Jansen <sensi...@gmx.net> wrote: >>> >>>>> Is this an attempt to create a competition for TAR? >>>> >>>> Not really. We'd have preferred tar if it would have been powerful enough. >>>> It's more an alternative to rsync for incremental updates. I really >>>> like the send/receive feature and want to make it available for cross- >>>> platform syncs. >>> >>> TAR with the star extensions that are also implemented by many other recent >>> TAR >>> programs should do, what are you missing? >> >> As said I've not done the research myself, but operations that come to mind >> include >> - partial updates of files > > How do you intend to detect this _after_ the original file was updated?
the patch is a kernel-side patch. It detects it by efficiently comparing zfs snapshots. If you change a block in a file, we'll send only the changed block. > >> - sparse files > > supported in an efficient way by star > >> - punch hole > > As this is a specific case of a sparse file, it could be added While 'sparse file' meant the initial transport of a sparse file, 'punch hole' is meant in the incremental context. Linux supports punching holes in files. > >> - truncate > > see above > >> - rename > > part of the incremental restore architecture from star, but needs a restore > symbol table on the receiving system Here, the sending sides determines renames. > >> - referencing parts of other files as the data to write (reflinks) > > There is no user space interface to detect this, why do you need it? As above, it is detected in kernel. In the case of btrfs, each datablock has backreferences to all its users. In zfs, the problem does not exist in this form, nevertheless a common format has to be able to transport this. > >> - create snapshot > > star supports incrementals. or do you mean that a snapshot should be set up > on > the reeiving site? snapshot on the receiving side. The aim is to exactly replicate a number of snapshots, just as zfs send/receive does. Alexander Block (the author of btrfs send/receive) commented in another subthread and explained the motivation to move away from tar/pax. -Arne > >> Do star support these operation? Are they part of any standard? >> >> Also, are chmod/chown/set atime/mtime possible on existing files? > > star allows to call: > > star -x -xmeta > > to _only_ extract meta data from a normal tar archive and it allows to create > a > specific meta data only archve via star -c -meta > > Jörg > _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
