search for: robbosch

I've been running some tests on files created by rsync and noticing fragmentation issues. I started the testing because our 5TB array started performing very slowly and it appears fragmentation was the culprit. The test I conducted was straighforward: 1. Copy over a 49GB file. Analyzed with contig (from sysinternals), no fragments. 2. Ran rsync and the file was recreated normally (rsync

I'm guessing no one else has seen this issue? Most exit codes are properly reported (e.g. code 12, code 10, code 2). The specific scenario is when a filename too long or directory not present error causes the client to exit with a code of 23 (reported as the exit code on the client properly and captured in the environment variable there). The exit code of the server still shows an exit code

Wayne.my vote is for a command-line option. I've noticed there is some penalty for very large files (35GB-50GB). The penalty is relatively small based on my 'intuitive' measurements.read me watching without running a real timer. The difference is very small compared to what happens after a few weeks without the fragmentation patch. Our SAN was becoming so fragmented that we were

I've looked at these arguments via environment variables and and I can't find the remote client's pathname in the RSYNC_ARG# values. For example, if I run the command: rsync -ruvit --ignore errors /usr/bin host::module/ the ARG values include all the options but the /usr/bin value. I'd like to be able to track the remote directory being used. Is this possible? Am I missing

I've noticed that even if rsync has a non-zero exit code on the client that the server still reports an exit status of 0. For example, I've received an error 23 with the following output on the client-side "rsync error: some files could not be transferred (code 23) at main.c(954) [sender=2.6.9cvs]" while the server-side rsync_raw_status and rsync_exit_status were still both

I received the following error on the client when testing the pre2 release. I'm not sure what it means or if it helps. Rsync 2.6.9 runs the same backup without error. I compiled rsync under cygwin CVS so it may be an issue there as well. Server side did not crash. It did log an error, but I'm pretty sure it was due to the client-side crash. Rsync was running using an ssh port

Just thought I'd post a simple workaround for Windows ACL's and file attributes for rsync. Using some basic scripting will allow ACL information to be stored for future use on files transferred using rsync. Most will probably find the information worthless but thought I'd post it anyway. - To get ACL information, use the icacls program provided as part of Server 2003 SP1

I had a case where I was using the --partial option (client is running rsync-pre5, server daemon is rsync-pre8). The transfer was interrupted and the partially transferred file replaced the destination file on the server. My understanding is that the partially transferred file would be kept but it would not replace the destination file...that is, both files would be kept so that rsync could pick

I'm getting errors in my rsync.logs using rsync3.0.0pre8 with the -vv option. The client is running on cygwin as the client, CentOS as the server. The error in the log is: rsync: delete_file: rmdir(filepath) failed: No error (0) When I look on the server/receiving side the directory does not exist. Just trying to understand why this would cause a non-zero exit code. Rob

Just as clarification, when I said the directory does not exist I mean that is was properly deleted by the server/receiving side. It appears as if rsync did everything that it should but an error code of zero is being returned and the exit code is set to 23, non-zero. Full options: -ruvvityz --compress-level=9 --links --ignore-case --ignore-errors --stats --del

Let me know of any additional info or tests you need me to run. I'll halp any way I can. thanks. rob

I've been trying to test rsync on files over 80GB again to see if I can find ways to improve performance further. I tried passing a manual block-size value and I keep getting "Invalid block length" from the [sender]. Can someone refresh my memory of the valid values that can be passed using this parameter? I've tried passing 1048 and the -vvv output shows the file being

I ran an rsync test using the RDC program that comes with the Server 2008 SDK. The RDC program is a simple program to demonstrate Microsoft's Remote Differential Compression algorithm. It uses the API for RDC to copy a file across a WAN/LAN connection. The program, as-is, has little functionality and a lot of limitations but I thought it might be fun to test. I compiled the RDC code as-is

I've been trying to find out how to improve performance with large files (e.g. Exchange databases > 80GB). One thing I've found is that reviewing the log output using -vvvv is difficult to pinpoint what is taking the majority of the time without monitoring the log "live" which isn't really feasible on 80GB files. It would be helpful if the additional logging (or all

I'm using rsync over an ssh tunnel to transfer some large files. I've been getting the "Resource temporarily unavailable" in my rsyncd.log frequently. The connections are T1's and very stable so I don't think it is a network drop. The disconnect occurs on the same files every time...although these files are also the largest ones taking the most time. I tried limiting

I've been getting the error below and the only thing I can see odd about the directory is the ! in the directory name. That and there is a space at the end of the text which doesn't seem like it should be there either. There are no permissions issues with accessing the directory and the directory does exist. Does anyone know if the ! will cause a problem or will rsync escape the special

Since upgrading to 2.6.8 with the tag 3 patch, I've been consistently getting an error using rsync. We have about 100 servers using the client to a central backup server and the issue is repeatable on the servers having the problem. About 10 of the servers are having the problem. The error reported by rsync is: Invalid file index: -1019607330 (count=8353) [sender] rsync error: protocol

I've been trying to compile 3.0.0pre8 under cygwin. I was getting a problem with the iconv functions which I think are related to the cygwin environment and its iconv.h. To bypass it I wanted to compile with the --disable-iconv function. I'm still getting the following errors during compile: /usr/src/rsync-3.0.0pre8/rsync.c:85: undefined reference to `_iconv_open'rsync.o: In

I've been trying to figure out why some large files are taking a long time to rsync (80GB file). With this file, the match process is taking days. I've added logging to verbose level 4. The output from match.c is at the point where it is writing out the "potential match at" message. In a 9 hour period the match verbiage has changed from: potential match at 14993337175 i=2976

When I use the preallocate patch and create a 77GB file using the function I get a CPU spike on the server-side. The spike lasts about 20 minutes and uses about 20%-25% of the cpu associated with the rsync instance creating the file. The spike is directly linked to the time it takes to create the file. I compiled rsync using cygwin CVS. I initially suspected the implementation of