linux user group brescia

immagine del castello

Archivio della mailing list

Cambio hard disk

andrea gelmini andrea.gelmini a lugbs.linux.it
Ven 15 Ago 2003 14:06:28 UTC
On gio, ago 14, 2003 at 07:43:44 +0200, Luca Coianiz wrote:
>  Infatti è questo che mi aveva incuriosito, solo che non essendo pratico ho
> pensato di essere io ad interpretare male: praticamente cat va "meglio" per
> file di testo (dato che può operare delle modifiche) mentre dd lavora meglio
> sul binario (cioè su tutto dato che il "testo" alla fine lo si può vedere
> come un "binario interpretato") ovvero dove non deve esserci alcuna
un paio di puntualizzazioni:
a) in unix non esiste la distinzione tra binario e testo (in verita` non
   avrebbe alcun senso di esistere, ma certi sistemi operativi...);
b) quali tipi di modifiche puo` fare il cat sul testo?;
c) dd e cat nascono per ragioni differenti e con scopi differenti, avendo
   in comune un comportamento similare. cio` detto, nel caso del thread in
   questione dd si presta meglio a cat.

> conversione (a meno di non utilizzare il parametro conv=CONVERSION
> ovviamente, e copiando un HD non mi pare il caso ;)).
dd se non ricordo male esce proprio dai laboratori IBM. ci sono diversi
aneddoti sull'origine del nome, ma nessuno che venga dato come ufficiale.
notasi che il maledetto EBCDIC e` tutt'ora utilizzato sui mainframe ibm.

>      # Copy all but the label from disk to tape.
>      (dd bs=4k skip=1 count=0 && dd bs=512k) <$disk >$tape
[...snip...]
> 
>  quindi count=0 vuol dire "non copiare nulla" invece che, come avevo capito,
> "copia tutto"?
la confusione, a mio avviso, te l'ha generata lo script. tradotto in parole
significa: dallo stream di dati $disk scavalca i primi 4k non mandando
nulla su stdout (dd bs=4k skip=1 count=0) e poi copia tutto il resto su
stdout, a blocchi di 512k, che a sua volta viene rediretto su $tape (&& dd bs=512k).
in verita` l'avrei scritto in un'altra maniera, ma non ho letto il contesto
in cui la cosa viene inserita, sicche`.

> >ad ogni modo, piccola raffinatezza, specificato un bs => a 4kb su macchine
> >a 32 bit, o a 8kb su architetture a 64 bit, si puo` tenere un certo
> >vantaggio in performance (vantaggio che non cambia all'aumentare della
> >dimensione indicata).
> 
>  Interessante, in caso i dischi da clonare siano di generose dimensioni.
sottolineo, il vantaggio e` minimo, e comunque la procedura e` esposta a
tutta una serie di fattori (insomma, inutile farsi troppe pippe a
riguardo).

ciao,
andrea



Maggiori informazioni sulla lista Lug