| 1 |
On 03/04/2022 16:29, Frank Steinmetzger wrote: |
| 2 |
> Am Sun, Apr 03, 2022 at 09:59:22AM +0100 schrieb Wols Lists: |
| 3 |
>> On 03/04/2022 02:15, Bill Kenworthy wrote: |
| 4 |
>>> Rsync has a bwlimit argument which helps here. Note that rsync copies |
| 5 |
>>> the whole file on what it considers local storage (which can be mounted |
| 6 |
>>> network shares) ... this can cause a real slowdown. |
| 7 |
>> It won't help on the initial copy, but look at the - I think it is - |
| 8 |
>> --in-place option. |
| 9 |
|
| 10 |
> This one is mostly useful if space on the destination is tight or the data |
| 11 |
> link (for FS commands) is slooow, because normally rsync creates a new temp |
| 12 |
> file and moves it into place once the transfer is complete. This to ensure |
| 13 |
> you never lose data due to a broken connection. If space is tight you could |
| 14 |
> also consider --delete-before instead, to first do all deletions before |
| 15 |
> copying the new stuff. |
| 16 |
> |
| 17 |
And making a temporary file may be exactly what you DON'T want. I make |
| 18 |
heavy use of hard links, and "make a temp file" absolutely buggers file |
| 19 |
system integrity ... |
| 20 |
|
| 21 |
And my use case with LVM and backups, "make a temp file" does both |
| 22 |
absolutely nothing to protect file system integrity, and makes every |
| 23 |
backup waste far more space than is necessary ... |
| 24 |
|
| 25 |
So --in-place actually has a lot of uses outside your two examples. I |
| 26 |
have oodles of space, and both my source and target are on fast sata |
| 27 |
links in the same computer, but not using --in-place would be *very* |
| 28 |
costly for me. |
| 29 |
|
| 30 |
Cheers, |
| 31 |
Wol |
Archives