cp o rsync, vale davvero la pena cp?

8

Spero che questo non conta come una domanda senza una vera risposta, come io non riesco a trovare una buona ragione per usare cp(1)sopra rsync(1)in quasi tutte le circostanze. Se uno tipicamente favorire rsyncsopra cp? C'è qualche buona linea guida per il loro uso?

rsync: Trasferisce i diff, può usare la compressione, può essere usato da remoto (e in modo sicuro), può essere riavviato nonostante un'interruzione, anche durante il trasferimento di un singolo file di grandi dimensioni. '
cp: Forse è solo più semplice da usare? È più veloce di rsync?

— Soyuz
fonte

4

A volte il sovraccarico del confronto è uno sforzo molto maggiore rispetto alla semplice copia cieca dei byte.

— Bahamat,

Stessa domanda con una risposta migliore: serverfault.com/questions/43014/…

— Daniel

9

cpfa parte dei coreutils, quindi è presente ovunque. Inoltre, è stato progettato principalmente per copiare file all'interno di un computer.

rsyncnon fa parte di coreutils, non è presente nemmeno nell'ambiente predefinito. Inoltre, è stato progettato principalmente per trasferire file in rete. Ha anche rsyncpiù dipendenze rispetto ai coreutils, tuttavia questa differenza non ha molto senso.

PS: A proposito, l'utilizzo della CPU è ancora importante sui sistemi integrati.

— corsa
fonte

6

Il motivo principale che non si desidera utilizzare rsyncper ogni operazione di copia è perché rsyncha un sovraccarico di calcolo. Prima che il trasferimento dei dati abbia effettivamente inizio, rsyncesegue la scansione di tutti i file. Quindi, prima di ogni file, viene effettuato un confronto. Questo sovraccarico non è insignificante, anche con la CPU veloce disponibile nel 2012. Faccio questo tipo di trasferimenti in ogni momento, e su server di dimensioni abbastanza decenti, una volta che inizi a gestire i concerti di dati, il sovraccarico può richiedere molto tempo.

Non sto dicendo di non usare rsync, per niente, usare rsyncogni volta che puoi risparmiare un po 'di tempo di trasferimento. Basta non usare rsyncquando cppotrebbe realizzare la stessa cosa.

Quello che faccio di solito, prima porta i dati usando i normali metodi di copia. Quindi rsyncper le successive modifiche, ovvero quando è possibile sfruttare tali differenze.

— JM Becker
fonte

È un grande prezzo da pagare, vista la potenza dei nostri processori oggi?

— Soyuz,

3

Grande è soggettivo e cambierebbe in base al numero di file rispetto alle dimensioni dei dati rispetto a IO. Il mio punto principale sarebbe che non è insignificante, indipendentemente dai processori di oggi. Una cosa da ricordare per i processori di oggi, deve ancora gestire i dati di oggi.

— JM Becker,

Concordato. Le CPU non diventano più veloci nel vuoto. Uno dei migliori motivi che abbiamo per le CPU GHz è la rete gigabit: una CPU più lenta semplicemente non riesce a mantenere una pipe I / O così piena. I computer tendono ad essere ben bilanciati come sappiamo come realizzarli. Porta via un po 'di potenza della CPU e parte della capacità I / O diventa inattiva. Aumenta la richiesta di I / O e la CPU finisce in idle di più, in attesa di I / O.

— Warren Young,

3

Mi aspetterei cpdi usare meno CPU quando copi localmente perché non usa diff, mentre rsyncpuò ridurre le scritture quando usi diff. La compressione dovrebbe essere evitata localmente perché devi leggere e scrivere comunque l'intero file / diff e richiede calcoli aggiuntivi.

— SCAI
fonte

Quindi, tutto si riduce al costo della CPU o al costo I / O

— Soyuz,

2

@soyuz, questo è vero per i dati che sono stati modificati, in riferimento ad altri dati. Più piccolo è il diff, più rsyncè preferito. Ma quando il loro non è diff, rsyncporta solo spese generali senza ulteriori benefici.

— JM Becker,

@TechZilla Penso che intendi, quando non c'è nulla in comune. Se non c'è differenza, rsync finirà presto perché non c'è nulla da copiare, rendendolo molto più preferito.

— Izkata,

@Izkata: c'è almeno un modo per rsyncavere un overhead di I / O doppio per due file identici rispetto a blind cp: un tempo di modifica modificato. Dovresti dare --size-onlyper risolvere questo problema. L'unico altro modo in cui posso vedere questo sarebbe rsyncaffidarsi ai checksum del filesystem, ma per la maggior parte dei filesystem non sono ottimi predittori statistici dell'identità.

— Warren Young,

3

A parte le spese generali nel caso di un diff diffuso o inesistente, rsyncnon sembra avere un equivalente di cp --reflink=always, che può salvare un'enorme quantità di dati se si copia all'interno di un filesystem che lo supporta (crea copie copy-on-write, quindi i dati in comune tra l'originale e la copia (che è, ovviamente, inizialmente tutto) vengono archiviati una sola volta). rsyncè, tuttavia, migliore nell'aggiornamento delle copie CoW, utilizzando --inplace.

— Darael
fonte