Mike, As it stands right now, we use xz for our compression, so if rsync had a similar option for xz that would probably be an improvement. However, I think being able to decompress directly to the remote system would save more; elsewise I don't see how I'm going to be able to avoid untarring and uncompressing the whole xz file on the other end. thanks much, ed On Tue, Dec 6, 2016 at 8:36 PM, Mike Hodson <mystica at gmail.com> wrote:> On Tue, Dec 6, 2016 at 8:07 PM, Ed Peschko <horos22 at gmail.com> wrote: >> >> All, >> >> I'm working in an environment *very* restricted by space, and need to >> sync from that location to another location. >> >> So I'd like to be able to sync from a source that is not a filesystem, >> like a compressed tarball. >> >> Is this possible with the --files-from argument (or some other such >> argument)? >> > > I'm curious if rsyncing the entire compressed tarball might work for you, if > you compress the tarball with the gzip option of --rsyncable and then > rsync with --inplace ? > > Mike
Can you use a fuse mount to pretend that the tarball is a filesystem? Also, there is squashfs. On 12/07/2016 12:59 PM, Ed Peschko wrote:> Mike, > > As it stands right now, we use xz for our compression, so if rsync had > a similar option for xz that would probably be an improvement. > > However, I think being able to decompress directly to the remote > system would save more; elsewise I don't see how I'm going to be able > to avoid untarring and uncompressing the whole xz file on the other > end. > > thanks much, > > ed > > On Tue, Dec 6, 2016 at 8:36 PM, Mike Hodson <mystica at gmail.com> wrote: >> On Tue, Dec 6, 2016 at 8:07 PM, Ed Peschko <horos22 at gmail.com> wrote: >>> >>> All, >>> >>> I'm working in an environment *very* restricted by space, and need to >>> sync from that location to another location. >>> >>> So I'd like to be able to sync from a source that is not a filesystem, >>> like a compressed tarball. >>> >>> Is this possible with the --files-from argument (or some other such >>> argument)? >>> >> >> I'm curious if rsyncing the entire compressed tarball might work for you, if >> you compress the tarball with the gzip option of --rsyncable and then >> rsync with --inplace ? >> >> Mike >-- ~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._., Kevin Korb Phone: (407) 252-6853 Systems Administrator Internet: FutureQuest, Inc. Kevin at FutureQuest.net (work) Orlando, Florida kmk at sanitarium.net (personal) Web page: http://www.sanitarium.net/ PGP public key available on web site. ~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._., -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 191 bytes Desc: OpenPGP digital signature URL: <http://lists.samba.org/pipermail/rsync/attachments/20161207/2bbc7af1/signature.sig>
Ed Peschko <horos22 at gmail.com> wrote:> As it stands right now, we use xz for our compression, so if rsync had > a similar option for xz that would probably be an improvement.Have xz as an option for what ? As others have already pointed out, rsync works with files on filesystems - it does not work with files embedded in other files. In the same way, it doesn't work with a disk partition and work out what files are held within the filesystem on that partition - you are expected to mount that filesystem so rsync can access the files. It would be incredibly wasteful (understanding filesystems construction) to duplicate that functionality into rsync ! I'd concur with others - if there's something like a fuse module to mount the compressed archive as a (read-only) fileystem then use that, otherwise you'll need to re-assess the whole process.
try archivemount or squashfs Am 8. Dezember 2016 11:43:07 MEZ, schrieb Simon Hobson <linux at thehobsons.co.uk>:>Ed Peschko <horos22 at gmail.com> wrote: > >> As it stands right now, we use xz for our compression, so if rsync >had >> a similar option for xz that would probably be an improvement. > >Have xz as an option for what ? >As others have already pointed out, rsync works with files on >filesystems - it does not work with files embedded in other files. In >the same way, it doesn't work with a disk partition and work out what >files are held within the filesystem on that partition - you are >expected to mount that filesystem so rsync can access the files. It >would be incredibly wasteful (understanding filesystems construction) >to duplicate that functionality into rsync ! > >I'd concur with others - if there's something like a fuse module to >mount the compressed archive as a (read-only) fileystem then use that, >otherwise you'll need to re-assess the whole process. > > >-- >Please use reply-all for most replies to avoid omitting the mailing >list. >To unsubscribe or change options: >https://lists.samba.org/mailman/listinfo/rsync >Before posting, read: >http://www.catb.org/~esr/faqs/smart-questions.html-- Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.samba.org/pipermail/rsync/attachments/20161208/3c98cd1c/attachment.html>