similar to: local -> local file copy question

Attached is a patch that makes window strides constant when files are walked with a constant block size. In these cases, it completely avoids all memmoves. In my simple local test of rsyncing 57MB of 10 local files, memmoved bytes went from 18MB to zero. I haven't tested this for a big variety of file cases. I think that this will always reduce the memmoves involved with walking a large

We've just been hit rather badly by a very nasty bug that can cause rsync to silently discard files or fill them with zeroes. It happens when e.g. opendir() succeeds but readdir() returns an error; rsync does not check for an error from readdir() and so simply ignores the error (along with any remaining files in the directory). No error is reported to the user, who will then happily

Hi, On systems with HAVE_SETATTRLIST, commit b936741 breaks compilation. This is because do_setattrlist_times hasn't been converted to STRUCT_STAT *stp. Here's a small patch to do it. Cheers, Filipe PS: I've been playing with IO_BUFFER_SIZE, MAX_MAP_SIZE and WRITE_SIZE. Any plans to make it configurable at runtime? It seems to make a big difference for large files on a fast link

Greetings, I'd like to propose a new option to rsync, which causes it to read device files as if they were regular files. This includes pipes, character devices and block devices (I'm not sure about sockets). The main motivation is cases where you need to synchronize a large amount of data that is not available as regular files, as in the following scenarios: * Keep a copy of a block

In short: Platform: linux with 2.4 kernel Version: rsync 2.6.6 Command line: rsync266 -av -W --bwlimit=1 /mnt/somedir/rsync-2.6.6.tar.gz ./ Destination: local disk Source: file on a smbfs mounted filesystem; share is exported on a NT 4.0 workstation over a very slow and unstable link Result: Rsync completes operation with no special message, but the resulting file is damaged, large

Author of the message didn't include rsync@lists.samba.org in the reply, and I think this message is in topic. -------- Original Message -------- Subject: Re: rsync windows -> unix still hanging :( Date: Mon, 30 Dec 2002 16:10:32 -0800 From: Jim Kleckner <jek-cygwin@kleckner.net> To: Mike Rubel <mrubel@galcit.caltech.edu>, cygwin@cygwin.com Mike - Greger Cronquist and I

I'm transferring 1.1 Mb files over very poor GSM EDGE connection. My rsync command is: rsync --partial --remove-source-files --timeout=120 --append --progress --rsh=ssh -z LOCAL_FILE root at SERVER:REMOTE_PATH File on remote server "grows" in size in steps of 262144 bytes. That is a lot, because system needs to transfer at least 262144 (before compression) every time connection

https://bugzilla.samba.org/show_bug.cgi?id=8512 Summary: rsync -a slower than cp -a Product: rsync Version: 3.1.0 Platform: All OS/Version: All Status: NEW Severity: normal Priority: P5 Component: core AssignedTo: wayned at samba.org ReportedBy: linux.news at bucksch.org QAContact:

I've been studying the read and write buffering in rsync and it turns out most I/O is done just a couple of bytes at a time. This means there are lots of system calls, and also most network traffic comprises lots of small packets. The behavior is most extreme when sending/receiving file deltas of identical files. The main case where I/O is buffered is writes from the server (when io

https://bugzilla.samba.org/show_bug.cgi?id=8177 Summary: Problems with big sparsed files Product: rsync Version: 3.0.8 Platform: x64 OS/Version: Linux Status: NEW Severity: normal Priority: P5 Component: core AssignedTo: wayned at samba.org ReportedBy: joluinfante at gmail.com

Hi, When using rsync-3.0.2 through 3.0.5, I get this error on a large dataset syncing from machine-a to machine-b: $ /bin/rsync -aHSz /local/. machine-b:/local/. invalid len passed to map_ptr: -1737287498 rsync error: error in file IO (code 11) at fileio.c(188) [sender=3.0.5] This happens no matter which side initiates the connection, so this fails in the same way: $ /bin/rsync -aHSz

Hi, This weekend I migrated a samba-server to new hardware and software : I'm running samba 3.2.7-11.3.2 on Opensuse 11.1. Everything works fine I believe except for an old DOS-application, written in Clipper. It's too slow to be usable. I tried to debug this but I'm stuck. I put the loglevel to 10, but I can't see anything wrong. I first added to veto oplock files :

Hi, Michael I have met ext4 error when using vhost_scsi on arm64 platform, and suspect it is vhost_scsi issue. Ext4 error when testing virtio_scsi & vhost_scsi No issue: 1. virtio_scsi, ext4 2. vhost_scsi & virtio_scsi, ext2 3. Instead of vhost, also tried loopback and no problem. Using loopback, host can use the new block device, while vhost is used by guest (qemu).

Hi, Michael I have met ext4 error when using vhost_scsi on arm64 platform, and suspect it is vhost_scsi issue. Ext4 error when testing virtio_scsi & vhost_scsi No issue: 1. virtio_scsi, ext4 2. vhost_scsi & virtio_scsi, ext2 3. Instead of vhost, also tried loopback and no problem. Using loopback, host can use the new block device, while vhost is used by guest (qemu).

Patches welcome, eh, Paul? Upon further (belated) investigation, there are 2 affected places in receiver.c with this error message. Both call write_file(). And write_file is called only in those two places. So that is the appropriate location to patch. Especially since the obvious fix is to use the rewrite code already there for the sparse file writes.

Hi We are currently embedding a rather large C++ library in R (BioC), and we want some comments on the portability of how we have approach this. First of, we are not really able to do much about the portability of the basic library, which of course is the main question :) We have an approach which seems to work, I just want a bit of feedback on it.... The way we integrate it into R is

On Fri, 2015-09-18 at 14:09 -0700, Nicholas A. Bellinger wrote: > On Fri, 2015-09-18 at 11:12 -0700, Ming Lin wrote: > > On Thu, 2015-09-17 at 17:55 -0700, Nicholas A. Bellinger wrote: > > > On Thu, 2015-09-17 at 16:31 -0700, Ming Lin wrote: > > > > On Wed, 2015-09-16 at 23:10 -0700, Nicholas A. Bellinger wrote: > > > > > Hi Ming & Co, > >

On Fri, 2015-09-18 at 14:09 -0700, Nicholas A. Bellinger wrote: > On Fri, 2015-09-18 at 11:12 -0700, Ming Lin wrote: > > On Thu, 2015-09-17 at 17:55 -0700, Nicholas A. Bellinger wrote: > > > On Thu, 2015-09-17 at 16:31 -0700, Ming Lin wrote: > > > > On Wed, 2015-09-16 at 23:10 -0700, Nicholas A. Bellinger wrote: > > > > > Hi Ming & Co, > >

Here is a patch that prevents the example encoder from rejecting some wav files that ffmpeg generates. The problem was that it wasn't properly handling the case where extra bytes were added to the header and they weren't a multiple of 4 bytes. This fixes that problem by getting the number of extra bytes in the header and reading that much data. Aaron Index: encoder_example.c

The inode eviction can be very slow, because during eviction we tell the VFS to truncate all of the inode''s pages. This results in calls to btrfs_invalidatepage() which in turn does calls to lock_extent_bits() and clear_extent_bit(). These calls result in too many merges and splits of extent_state structures, which consume a lot of time and cpu when the inode has many pages. In some