linux - mp3tag - ¿Es dd mejor que el gato?
mp3 tag linux (10)
Algunos puntos
ltrace cat </dev/zero >/dev/null sugiere que cat es más eficiente de manera predeterminada, ya que no memcpy y, lo que es más importante, utiliza búferes 4KiB por defecto.
ltrace dd if=/dev/zero of=/dev/null muestra que dd usa por defecto 512B buffers que es muy ineficiente para leer discos modernos (aunque el kernel debería aliviar esto un tanto con varias programaciones de disco). Sin embargo, dd es mucho más configurable que cat y puedes usar algo como bs = 2M para reducir el número de syscalls
dd es problemático en presencia de errores de disco, y puede bloquearse o, lo que es más importante, ignorar los datos no legibles, lo que daña el disco de destino. Considere dd_rescue o ddrescue para esta tarea en su lugar.
Supongamos que quiero clonar mi disco duro ( hda ) en otra unidad ( hdb ) en la misma computadora. Como yo lo veo, hay dos maneras fáciles, rudas y hágalo usted mismo:
cat /dev/hda > /dev/hdb
y
dd if=/dev/hda of=/dev/hdb
¿Qué razones técnicas hay para afirmar que a menudo se dice / se dice que esta última es mejor que la primera?
bajo ninguna circunstancia intente estos comandos en casa, o su UNIX está fubarizado
Creo que puede haber una penalización de rendimiento por enviar todos tus datos a través de la tubería. dd lo hace todo en un solo programa, y probablemente esté optimizado para lecturas y escrituras en bloque.
Es realmente histórico, y no tan importante si todo lo que vas a hacer es clonar un disco en otro.
En Unix tradicional, se podía acceder a los discos a través de dispositivos de bloque y dispositivos de caracteres, y cada uno tenía requisitos diferentes. ''dd'' era necesario para interactuar con los dispositivos de bloque, porque ''cat'' solo sabía sobre la E / S de caracteres. (La E / S de bloques fue particularmente importante para manejar eficientemente cosas como unidades de cinta).
dd puede ser útil si necesita reiniciar una copia de larga ejecución, debido a sus opciones de omisión y búsqueda.
A menos que esté en un sistema que todavía tenga la distinción de bloque / carácter para el acceso al disco (que Linux no), ya menos que necesite hacer algo como swap bytes, ''cat'' estará bien (y probablemente más rápido, porque Por defecto tendrá tamaños de bloques más grandes que dd).
Tenga en cuenta que, a menos que alguien haya hecho algunos ajustes importantes en el diseño del caparazón desde la última vez que miré, ''cat foo> bar'' no hace la escritura en ''barra'' a través del caparazón; todo lo que hace el shell es ''barra'' abierta para escribir con truncamiento, luego pasa el descriptor de archivo abierto a ''cat'' a través de un fork / exec como descriptor de archivo 1 (stdout). En ese punto, el shell está fuera del ciclo, y no se involucra nuevamente, más allá de ser notificado del estado de salida de ''cat''.
Interesante ... He visto recomendaciones en el pasado para hacer este tipo de operación de copia con varias permutaciones de dd, cpio o tar, pero nunca cat.
Sigo queriendo decir que es una cuestión de que cat esté orientado al texto y que los demás estén orientados a datos binarios o que dd pueda manejar más fácilmente el espacio sin formato, pero * nix realmente no hace una distinción de texto / binario y copia el archivo del dispositivo tomará el sistema de archivos con la copia, por lo que el formateo no debería ser un problema.
dd tiene muchas opciones adicionales para la conversión de datos en el proceso de transferencia, pero no esperaría que esto fuera particularmente relevante cuando transfiera el sistema de archivos en sí mismo en lugar de solo sus contenidos.
La gran diferencia entre simplemente ''gato'' y ''dd'' es que dd asegura que todas las lecturas y escrituras se realizan con el tamaño que especifique. Esto puede ser significativo, dependiendo de qué dispositivo (y versión de * nix) esté usando.
Si mal no recuerdo, dd es mucho más "de bajo nivel" en su enfoque, saltándose cosas tan sofisticadas como los sistemas de archivos y todas las campanas y silbatos :)
Una vez, dd literalmente salvó mi preciosa vida, ehm:
pegado con una caja de linux llena de "DATOS ABSOLUTAMENTE IRREJUGABLES" de un contratista, con waaaay a muchos sectores defectuosos que lo único utilizable era el shell de emergencia de linux. ¿Mencioné la imposibilidad de abrir la caja para obtener el disco? Ah, sí, no usb y tal ...
Y luego, la luz !!! dd y ftp trabajando !!! Ahhh, refrescando! Guardando tu día (y carrera) con un impecable encantamiento de línea de comando para realizar un volcado de respaldo en un disco remoto con ftp ...
Algo así como put |dd if=/dev/hda bs=4096 count= ???? o similar...
El gato no funcionó para mí entonces ...
Ya hay poca diferencia práctica.
Internamente, ambos optan por usar casi los mismos cals.
dd tiene una serie de características adicionales útiles para copias de datos más complejas y otros usuarios podrían reconocerlo como más "normal" para este tipo de tareas. Pero el simple ''gato'' está en la esencia de Unix,
dd debería ser más rápido porque hace las E / S internamente, a diferencia de cat, que usa stdio y el shell para E / S.
Desea usar dd para poder especificar cosas como bsize, que es cuánto leer / escribir a la vez; sintonizar esto con un múltiplo de 4k va a ser mucho más rápido que con cat, que, creo, va a estar limitado por las tuberías involucradas.
Estaba en Ubuntu 12.04 y mi experiencia fue que podía ''cat'' una partición (/ dev / sda1) pero no todo el dispositivo (/ dev / sda). Solo pude clonar exitosamente un dispositivo usando `dd ''. De alguna manera, la información de la partición y el sector de arranque se perdieron si cat / dev / sda.