Quoting Shachar Shemesh, from the post of Sun, 05 Nov: > Ira Abramov wrote: > > although rsync makes a full list of the files and > > their attributes before copying (even on local copy), and shows speed > > stats with -P, it won't let me get a good picture about the total > > procentage of the copy process, > I can venture a guess that this is because it is only optimized for > remote transfers. With those, rsync cannot tell how much actual transfer > is still necessary, and so cannot provide more than an estimate. Still,
of course it cannot predict how long it will take if it bumps into a file that only requires a small delta to be transfered, but since it DOES go over the entire directory before the copy and reads file date and sizes (and possibly ownership and modiffiers as well) it should be able to have the WORST CASE copy ammount at the bottom line, a total that can only be shortened in case there's a high hit rate in a delta transfer down the road. > an estimate would be nice (i.e. - bytes remaining, bytes transfered, > bytes saved from transferring). You can submit that to the rsync mailing > list as a request for enhancement. I certainly will... > As a side note, I'll mention that local->local transfers using rsync are > not differential saving, and do not use the rsync algorithm to "save" on > "bandwidth". Still, the program is not optimized for this operation, and > performance seems to, indeed, suffer. indeed, in local copies it does not do delta tests, but it skips copying files that are not newer than in the target (though I'm sure /bin/cp has options for that too) > > any recommended tools for this? > KDE's file manager shows you progress. It seems to calculate it > relatively fast, though I'm stumped as to how. well, I prefer a CLI tool. many times I do those operations via SSH or in a windows-client-only shop where I don't install X on the servers just to transfer the file tree in question. > Collecting the information about the overall process' magnitude takes > time itself, and will, typically, gravely interfere with the actual > copying process due to simultaneous access to the media. I'm interested > to know what is the compelling reason you need this, and how much KB/s > are you willing to sacrifice for it, as it will never come with no cost > at all. well of course it costs bandwidth, I do not ignore it. but at times I need that. today I had to move an SVN repository tree between NFS servers. I mounted on one Linux machine (both are NetApp Filers) and copied 28k files totaling 4.9 GB. I could not tell the client if it will take 10 minutes or an hour, and that information had an impact of the downtime of the R&D people using the SVN. At the end it was just under an hour, and I would have definitely given away the 5 more minutes it took to dig the tree and give me the estimate (roughly based on the amount of time it took rsync to count the 28k files before copying over the ones which changed at the end of the tar|tar copy) -- The greatest story ever told Ira Abramov http://ira.abramov.org/email/ ================================================================= To unsubscribe, send mail to [EMAIL PROTECTED] with the word "unsubscribe" in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
