I once read the manual and remembered my favorite combination of parameters, which includes "-z"
A couple of days ago I manually started a rsync copy between a local source and a local destination. Today after screen -x I discovered the rsync is still running and taking 95% of the cpu. After a bit of wtf'ing around I finally carefully looked at rsync parameters and noticed my "-z" parameter.
Stopping rsync and restarting without compression brought disk traffic back to expected.
Truth is I never expected compression to be enabled when copying from local to local: why would rsync activate compression if both source and destinations are local, anyway?
A default behaviour to match this expectation would probably save others.
No please do not. If I specify an option, I want that option. If I do not want that option, I will not specify that option.
At most, add a new option that modifies the behavior of -z a la --skip-compress.
It's true I can't honestly think of a specific reason off hand, other than benchmarking and intentionally exercising (not invalid uses already), where I'd want to -z locally, I don't think it would even help where "local" includes nfs/samba mounts,
It's also true that since I first used rsync in... 1998 or 1999, I never considered this a problem. One mans automatic convenience is another mans "dammned automagical behavior is doing what makes sense in the common case _at the expense of_ what I need in this case".
>why would rsync activate compression if both source and
>destinations are local, anyway
Because you told rsync to do so.
hereby, i also give my vote to NOT include such feature in rsync
I also think rsync should do as it is told.