I've had rsync hangs when transferring hug filesystems (~80Gb) over network,
but till i've suppress the -v option from my command line there's no hang
anymore hang.
The -v option under 2.4.6 is bugged, try to mutiplie v's and the hangs will
increase too.
( rsync -axWP --rsync-path=/usr/local/bin/
>I haven't used the --bwlimit option and don't really know how it works.
>I remember when somebody contributed it that I was skeptical about how
>well it could work. I'm especially not surprised that it has no impact
>on local-to-local transfers.
I have used --bwlimit and it works a treat. It
On Tue, May 29, 2001 at 12:02:41PM -0500, Phil Howard wrote:
> Dave Dykstra wrote:
>
> > On Fri, May 25, 2001 at 02:19:59PM -0500, Dave Dykstra wrote:
> > ...
> > > Use the -W option to disable the rsync algorithm. We really ought to make
> > > that the default when both the source and destinati
Dave Dykstra wrote:
> On Fri, May 25, 2001 at 02:19:59PM -0500, Dave Dykstra wrote:
> ...
> > Use the -W option to disable the rsync algorithm. We really ought to make
> > that the default when both the source and destination are local.
>
> I went ahead and submitted a change to the rsync CVS t
On Fri, May 25, 2001 at 02:19:59PM -0500, Dave Dykstra wrote:
...
> Use the -W option to disable the rsync algorithm. We really ought to make
> that the default when both the source and destination are local.
I went ahead and submitted a change to the rsync CVS to automatically turn
on -W when t
> There is a feature I would like, and I notice that even with -c this
> does not happen, but I think it could based on the way rsync works.
> What I'd like to have is when a whole file is moved from one directory
> to another, rsync would detect a new file with the same checksum as an
> existin
[EMAIL PROTECTED] [[EMAIL PROTECTED]] writes:
> Actually, the lack of -W isn't helping me at all. The reason is that
> even for the stuff I do over the network, 99% of it is compressed with
> gzip or bzip2. If the files change, the originals were changed and a
> new compression is made, and usu
David Bolen wrote:
> The discovery phase will by default just check timestamps and sizes.
> You can adjust that with command line options, including the use of -c
> to include a full file checksum as part of the comparison, if for
> example, files might change without affecting timestamp or size.
[EMAIL PROTECTED] [[EMAIL PROTECTED]] writes:
>Dave Dykstra wrote:
>
>> That's two different kinds of checksums. The -c option runs a whole-file
>> checksum on both sides, but if you don't use -W the rsync rolling
checksum
>> will be applied.
>
>So the chunk-by-chunk checksum always is used w/o
On Fri, May 25, 2001 at 04:33:28PM -0500, Phil Howard wrote:
> Dave Dykstra wrote:
> > > One possibility here is that I do have /var/run symlinked to /ram/run
> > > which is on a ramdisk. So the lock file is there. The file is there
> > > but it is empty. Should it have data in it? BTW, it was
On Fri, May 25, 2001 at 03:39:31PM -0500, Phil Howard wrote:
> Dave Dykstra wrote:
>
> > > 2 =
> > > When syncronizing a very large number of files, all files in a large
> > > partition, rsync frequently hangs. It's abou
Dave Dykstra wrote:
> > 2 =
> > When syncronizing a very large number of files, all files in a large
> > partition, rsync frequently hangs. It's about 50% of the time, but
> > seems to be a function of how much work ther
On Fri, May 25, 2001 at 12:14:17PM -0500, Phil Howard wrote:
> I switched to 2.4.6 a while back, but have only been making heavy
> use of rsync the past couple of months, and have been running into
> a few problems that may be bugs. I looked at the bug tracker, but
> it was too cumbersome to use
I switched to 2.4.6 a while back, but have only been making heavy
use of rsync the past couple of months, and have been running into
a few problems that may be bugs. I looked at the bug tracker, but
it was too cumbersome to use effectively. I don't know if these
are real bugs or just configurati
14 matches
Mail list logo
