similar to: [Bug 14338] New: ZSTD support

https://bugzilla.samba.org/show_bug.cgi?id=14390 Bug ID: 14390 Summary: Feature request: don't fail if using "-z" transferring to rsync complied with --with-included-zlib=no Product: rsync Version: 3.1.3 Hardware: All OS: All Status: NEW Severity: enhancement

I added ZSTD support to OpenSSH roughly three years ago and I've been playing with it ever since. The nice part is that ZSTD achieves reasonable compression (like zlib) but consumes little CPU so it is unlikely that compression becomes the bottle neck of a transfer. The compression overhead (CPU) is negligible even when uncompressed data is tunneled over the SSH connection (SOCKS proxy, port

From: Sebastian Andrzej Siewior <sebastian at breakpoint.cc> The "zstd at breakpoint.cc" compression algorithm enables ZSTD based compression as defined in RFC8478. The compression is delayed until the server sends the SSH_MSG_USERAUTH_SUCCESS which is the same time as with the "zlib at openssh.com" method. Signed-off-by: Sebastian Andrzej Siewior <sebastian at

I hacked zstd support into OpenSSH a while ago and just started to clean it up in the recent days. The cleanup includes configuration support among other things that I did not have. During testing I noticed the following differences compared to zlib: - highly interactive shell output (as in refreshed at a _very_ high rate) may result in higher bandwidth compared to zlib. Since zstd is quicker

On 2020-09-07 11:21:13 [+1000], Darren Tucker wrote: > The zstd part would be a larger discussion because we would need to > either carry it as a Portable patch or have zstd added to OpenBSD > base, and I don't know if that would be accepted. Do you have any > performance numbers for zstd in this application? A key stroke is here 10 bytes of raw data which zstd compresses usually

I added ZSTD support to OpenSSH roughly over a year and I've been playing with it ever since. The nice part is that ZSTD achieves reasonable compression (like zlib) but consumes little CPU so it is unlikely that compression becomes the bottle neck of a transfer. The compression overhead (CPU) is negligible even when uncompressed data is tunneled over the SSH connection (SOCKS proxy, port

https://bugzilla.mindrot.org/show_bug.cgi?id=2888 Bug ID: 2888 Summary: Consider adding other compression schemes (lz4, zstd) Product: Portable OpenSSH Version: 7.7p1 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 Component: Miscellaneous Assignee:

Hi All, Any inputs on this issue? -- Shedi On Wed, Feb 21, 2024 at 5:12?PM Shreenidhi Shedi < shreenidhi.shedi at broadcom.com> wrote: > Hi All, > > Copying the content from the GH issue as is. > Need your inputs on the same. > FWIW, the coredump files generated in linux have xattr values which are > > 32 bytes. > > https://github.com/WayneD/rsync/issues/569

From: Sebastian Andrzej Siewior <sebastian at breakpoint.cc> zstd compression was announced as "good compression with high throughput" so I gave it a try. With zlib, on high speed links the CPU is usually the bottle neck. With zstd I'm able to fill a 200Mbit link :) zstd detection happens automatically via pkg-config. No zstd header means no error about missing zstd. So that

On 2020-08-06 08:45, J Martin Rushton via CentOS wrote: > You'll need to upgrade to CentOS8. > > C7 is at rsync 3.1.2-10, and will not go above 3.1.2 ever. > > C8.2 is at 3.1.3-7, C8 will always be on 3.1.3 > > Martin Another option is to build rsync from source, which is what I did to try out the zstd compression. centos7$ rsync --version rsync? version 3.2.2? protocol

ok, I did install zstd (zstd command line interface 64-bits v1.4.4, by Yann Collet) reconfigured & compiled dovecot 2.3.10.1 again with option : with-zstd changed the configuration file to : zlib_save = zstd and restarted dovecot - now I have following log file errors : Aug 28 16:17:39 lxc-imap dovecot: imap(rnowotny)<237930><H1kft/CtENRUclcc>: Error: zlib_save: Unknown

On 8. Sep 2020, at 12.35, Robert Nowotny <rnowotny1966 at gmail.com> wrote: Dear Aki, I switched to "gz" now, since "zstd" also gave some errors on writing to files. What kind of errors? Probably this? : Panic: file ostream.c: line 287 (o_stream_sendv_int): assertion failed: (!stream->blocking) can be - unfortunately I do not have the log files anymore... Sep

Can anyone tell me the repository to use to upgrade to a version of rsync later than 3.1.2? Chris -- Christopher Wensink IS Administrator Five Star Plastics, Inc 1339 Continental Drive Eau Claire, WI 54701 Office: 715-831-1682 Mobile: 715-563-3112 Fax: 715-831-6075 cwensink at five-star-plastics.com www.five-star-plastics.com

On 9. Sep 2020, at 11.14, Robert Nowotny <rnowotny1966 at gmail.com> wrote: Sep 3 08:33:25 lxc-imap dovecot: imap(mpaul)<48684><2/9E5mKuAezAqKjk>: Error: Mailbox Sent: UID=2171: read(zlib(/home/vmail/virtualmailboxes/mpaul/storage/m.119)) failed: read(/home/vmail/virtualmailboxes/mpaul/storage/m.119) failed: Broken pipe (FETCH BODY[]) Also this way you can see if the broken

> > On 8. Sep 2020, at 12.35, Robert Nowotny <rnowotny1966 at gmail.com <mailto:rnowotny1966 at gmail.com>> wrote: >> >> >> Dear Aki, >> I switched to "gz" now, since "zstd" also gave some errors on writing to files. > > What kind of errors? Probably this? : Panic: file ostream.c: line 287 (o_stream_sendv_int): assertion

Dear Aki, I switched to "gz" now, since "zstd" also gave some errors on writing to files. I dont know if "xz" compression or "zstd" shreddered my MDBOX Files, but I lost 4 days of mail. (a couple of thousand mails). After restoring the backup (what was made after switching to version 2.3.11.3) I still have some broken mdfiles, but not too many. Interestingly

> On 01/06/2020 18:02 Peter <peter at pajamian.dhs.org> wrote: > > > On 2/06/20 1:49 am, Aki Tuomi wrote: > >> we are still waiting for CentOS 8 Repo for current Dovecot version from > >> here https://repo.dovecot.org/. Do you have an idea when it will come? > >> Who does it maintain? Is it the Dovecot team? > >> > >> Thanks, >

Hi, enabling this line in hosts file "WAN eth2:0.0.0.0/0!1.0.0.0/8,10.0.0.0/8,169.254.0.0/16,172.16.0.0/12,192.168.0.0/16 routeback,blacklist,tcpflags" results in this error message -- Preparing iptables-restore input... Running /usr/sbin/iptables-restore... iptables-restore v1.3.8: error creating chain ''ACCEPT'':File exists Error occurred at line: 29 Try

Hi, please, excuse my poor English Exist any tool for upgrade kernel automatically in DomU machines? Because I have the following problem: After upgrade the kernel package from linux-image-2.6.24-21-xen to linux-image-2.6.24-22-xen in Dom0 (an Ubuntu Server), I modified the config files in /etc/xen/domUmachine.cfg for all my VM. Later a restarted its, but i found the following error // DomU //

zstd support was added in v2.3.11 (not v2.3.12 like I mistakenly tried to say in the earlier mail). > On 28. Aug 2020, at 16.36, Robert Nowotny <rnowotny at rotek.at> wrote: > > > ok, I did install zstd (zstd command line interface 64-bits v1.4.4, by Yann Collet) > > reconfigured & compiled dovecot 2.3.10.1 again with option : with-zstd > > changed the