Otto Moerbeek wrote:
So your problem seems to be that rsync -S is inefficient to the point
where it is not useable. I do not use rsync a lot, so I do not know
if there's a solution to that problem. It does seem strange that a
feature to solve a problem actually make the problem worse.
Well, I don't want to create a miss understanding here about rsync. -S
does address the issue of making the sparse file copy smaller at the
end, if you like. It doesn't help in the fact that it is processing them
however and if not use -S, then the sync is much, much faster, however
the destination is huge space actually use space on the drive that fill
it up. So they do their respective job, but with different side effect.
Faster sync, much lower bandwidth usage, bigger end results usage space
on disk. The other one is the opposite. (;>. But the biggest side effect
is that using -S will redo the transfer regardless if the end results
would be the same as it doesn't see it as the same. In the end, that's
really the problem, witch I don't think there is a solutions for anyway
in the design of rsync. If there is one anyway, I don't think about it
at the moment for sure. It's just a catch 22 situation at the moment.
A stupid solution that I just though of writing it to explain it might
be as simple as putting temporary a box between the original one and the
remote bunch that would be sync to first. This way, it add more delay
yes, but may be in the end would much better.
I can manage, I find ways to use ls -laR, or du -k and do diff's between
them and fine the files that are getting out of wack, replace them and
then continue, but this really is painful.
stat -s gives the raw info in one go. Some shell script hacking should
make it easy to detect sparse files.
Thanks Otto for the suggestion. That might help until it can be address
for good. It would help speed up some of it. (;>
Many thanks as trying to explain the problem better may have given me a
temporary work around that is not brilliant, but that might just work
until the problem can be address better.
Daniel
