similar to: Rsync: Re: patch to enable faster mirroring of large filesyst ems

In my particular case, it is reasonable to assume that the size and timestamp will change when the file is updated. (We are looking at it as a patching mechanism.) Right now it's actually using update time only, I should modify it to check the file size as well. Is there a way you could query your database to tell you which extents have data that has been modified within a certain timeframe?

Keating, Tim [TKeating@origin.ea.com] writes: > Is there a way you could query your database to tell you which > extents have data that has been modified within a certain timeframe? Not in any practical way that I know of. It's not normally a major hassle for us since rsync is used for a central backup that occurs on a large enough time scale that the timestamp does normally change

usage appears to grow gradually, not exponentially. A rsync may take several hours to complete. (I have one running now that started over four hours ago. The filesystem contains 236 GB of data in 2.4 million files. It is currently taking up 1351MB of memory on the mirror server and 646M on the source server.) All filesystems are veritas filesystem, in case that is relevant. I saw someone on

Granzow, Doug (NCI) [granzowd@mail.nih.gov] writes: > Hmm... I have a filesystem that contains 3,098,119 files. That's > 3,098,119 * 56 bytes or 173,494,664 bytes (about 165 MB). Allowing > for the exponential resizing we end up with space for 4,096,000 > files * 56 bytes = 218 MB. But 'top' tells me the rsync running on > this filesystem is taking up 646 MB, about 3

David Starks-Browning [starksb@ebi.ac.uk] writes: > Are you also distributing the source to cygwin1.dll? It is illegal > not to. Well, if it's an unmodified version, I expect a simple pointer to the Cygwin site and/or CVS tree would be sufficient. Physical distribution is not necessarily the only way to satisfy the GPL, and if the included cygwin1.dll is simply a binary downloaded

R. Weisz [rweisz4@home.com] writes: > Has anyone using rsync ever tried using it to manage the replication and > synchronization process for Microsoft ACCESS replicas? If so, Not for Microsoft ACCESS, but we synchronize copies of SQL/Anywhere databases constantly. As long as you're not trying to synchronize files that are actively in use (which may prevent rsync from reading portions

Diburim [diburim@hotmail.com] writes: (Quoted from the subject line - Diburim, it's best to keep the subject line short and put your question in the body of the e-mail. Subject lines are often truncated for display purposes and it can make it more difficult to see your question) > On Windows OS, is there any advantage for completing rsync using > MSVC instead of gcc/cygwin ? Not

Granzow, Doug (NCI) [granzowd@mail.nih.gov] writes: > From what I've observed by running top while rsync is running, its memory > usage appears to grow gradually, not exponentially. The exponential portion of the growth is up front when rsync gathers the file listing (it starts with room for 1000 files, then doubles that to 2000, 4000, etc...). So if your rsync has started

Not sure, I am re-running this to ensure that I was not smoking crack at the time :) > -----Original Message----- > From: Dave Dykstra [mailto:dwd@bell-labs.com] > Sent: Thursday, November 29, 2001 1:12 PM > To: Keating, Tim > Cc: rsync@samba.org > Subject: Re: Rsync: Re: patch to enable faster mirroring of large > filesyst ems > > > On Thu, Nov 29, 2001 at

I was at first, but then removed it. The results were still insufficiently fast. > Were you using the -c option of rsync? It sounds like you > were and it's > extremely slow. I knew somebody who once went to > extraordinary lengths to > avoid the overhead of -c, making a big patch to rsync to > cache checksums, > when all he had to do was not use -c.

I, too, was disappointed with rsync's performance when no changes were required (23 minutes to verify that a system of about 3200 files was identical). I wrote a little client/server python app which does the verification, and then hands rsync the list of files to update. This reduced the optimal case compare time to under 30 seconds. Here's what it does, and forgive me if these sound

Oh. Now i feel like an *enlightened* idiot. I 've always thought of a checksum, crc, or whatever as giving 1/2^^length certainty, and I have a sense that that knowing the file length adds another amount of certainty, though I can't quantify that. I just know that if the size doesn't match, the checksum doesn't matter. I'd never considered the implications of the

Does rsync work over an NFS mount? --Karl _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp

FYI, We've been using the 2.4.7pre1 release for several days now, with nary a hang problem. We haven't seen the EOF bug at all, which was what we upgraded for. This is with transfers of as much as 50GB to set up an initial mirror. The only thing we did was set timeout=0 -- which I guess is unnecessary. The semantics of this flag are a bit unclear. We thought was 'time since

I am trying to rsync a file of 10gb between an NT host running Cygwin 4.10 and a Solaris 8 host running rsync 2.5.1 but am having problems with what appears to be a 2gb file limit - the truncation point occurs at 2096111616 bytes. The target filesystem definately supports files over 2GB. Any ideas how to overcome this limitation? Regards, Craig Donnelly Andel Consulting 10 Fenchurch Avenue

I am having trouble with rsync when I am trying to synchronize a Windows NT volume mounted with smb_fs (FreeBSD) and a unix volume which is also exported with Samba. There are instances where the DOS short name on the NT volume ends up as upper case and then doesn't match filenames which are used in the unix volumes which have been exported by Samba. I don't know if this is a Samba

What is the default block size? I have a few files 30+mb and data is just added to the end of them. It seems like it takes longer to sync them that it was to send it initially. Should I change the block size or something else? I am running: rsync -z -e ssh *.* user@linuxbox:data/ I need to use ssh because I am going over the internet and sending "company data". -------------- next

Hello, Recently while working with rsync as the way to mirror large (several GB) archive on a regular basis, I came across several problems, and also got the ideas about their possible solutions - please could you investigate & consider implementing the features, described below, to future RSYNC releases ? - when the checksumming (consider very large archive, several GB) stage of rsync

I recently installed rsync 2.5.5 on both my rsync server and client being used. I installed the latest version because I was having problems with rsync stalling with version 2.4.6 (I read that 2.5.5 was supposed to clear this up or at least give more appropriate errors). I am still having problems with rsync stalling even after upgrading to 2.5.5. It only stalls in the "/home" tree

Hi. When I discovered rsync, it immediately became one of my most indispensable utilities. It's a real godsend on bandwidth-limited links, especially digital cellular. It works remarkably well in the general case, but I think the algorithm could be improved for one very important special case. Many (or even most) of the updated files I transfer with rsync change only by stuff being appending