Recibo entre 4 y 100 archivos tar muy grandes (~20 GB) todos los días. Los he estado concatenando en el pasado recorriendo cada uno de los archivos que veo en el sistema de archivos y haciendo algo como esto
/bin/tar -concatenate --file=allTars.tar receivedTar.tar
Sin embargo, el problema con esto es que a medida que concateno más y más archivos tar, debe leer hasta el final allTars.tarpara comenzar a concatenar nuevamente. A veces se necesitan más de 20 minutos para comenzar a agregar otro archivo tar. Es demasiado lento y me falta un tiempo de entrega acordado para el producto completo allTars.tar.
También intenté entregarle a mi comando tar una lista de archivos como este:
/bin/tar --concatenate --file=alltars.tar receiverTar1.tar receivedTar2.tar receivedTar3.tar...etc
Esto dio resultados muy extraños. allTars.tarsería el tamaño esperado (es decir, cerca de todos los receivedTar.tartamaños de archivos sumados) pero parecía sobrescribir los archivos cuando allTars.tarse descomprimió.
¿Hay alguna forma de concatenar todos estos archivos tar en un solo comando para que no sea necesario leer hasta el final del archivo que se concatena cada vez?y¿Hacer que se descompriman correctamente y con todos los archivos/datos?
Respuesta1
Puede que esto no le ayude, pero si está dispuesto a utilizar la -iopción al extraer del archivo final, puede simplemente catjuntar los archivos tar. Un archivo tar termina con un encabezado lleno de nulos y más relleno de nulos hasta el final del registro. Con --concatenatetar debemos recorrer todos los encabezados hasta encontrar la posición exacta del encabezado final, para poder comenzar a sobrescribir allí.
Si solo usa catlos alquitranes, solo tendrá nulos adicionales entre los encabezados. La -iopción le pide a tar que ignore estos valores nulos entre encabezados. Así que puedes
cat receiverTar1.tar receivedTar2.tar ... >>alltars.tar
tar -itvf alltars.tar
Además, su tar --concatenateejemplo debería estar funcionando. Sin embargo, si tiene el mismo archivo con el mismo nombre en varios archivos tar, reescribirá ese archivo varias veces cuando lo extraiga todo del tar resultante.
Respuesta2
Esta pregunta es bastante antigua, pero desearía que me hubiera resultado más fácil encontrar la siguiente información antes. Entonces, si alguien más se topa con esto, que lo disfrute:
Lo que Jeff describe arriba es un error conocido en gnu tar (informado en agosto de 2008). Solo -fse elimina el marcador EOF del primer archivo (el que está después de la opción). Si intenta concatenar más de 2 archivos, los últimos archivos estarán "ocultos" detrás de los marcadores de final de archivo.
Es un error en el alquitrán. Concatena archivos completos, incluidos los bloques de ceros finales, por lo que, de forma predeterminada, la lectura del archivo resultante se detiene después de la primera concatenación.
Fuente:https://lists.gnu.org/archive/html/bug-tar/2008-08/msg00002.html (y siguientes mensajes)
Teniendo en cuenta la antigüedad del error, me pregunto si alguna vez se solucionará. Dudo que haya una masa crítica afectada.
La mejor manera de evitar este error podría ser utilizar la -iopción, al menos para archivos .tar en su sistema de archivos.
Como señala Jeff, tar --concatenatepuede tomar mucho tiempo llegar al EOF antes de que concatene el siguiente archivo. Entonces, si vas a quedarte atrapado con un archivo "roto" que necesita la tar -iopción de descomprimir, te sugiero lo siguiente:
En lugar de usar
tar --concatenate -f archive1.tar archive2.tar archive3.tar
probablemente será mejor que corras cat archive2.tar archive3.tar >> archive1.taro canalizar ddsi desea escribir en un dispositivo de cinta. Tenga en cuenta también que estopodríaconducir a un comportamiento inesperado si las cintas no se pusieron a cero antes de (sobre)escribir nuevos datos en ellas. Por esa razón, el enfoque que voy a adoptar en mi aplicación es tars anidados como se sugiere en los comentarios debajo de la pregunta.
La sugerencia anterior se basa en el siguiente punto de referencia de muestra muy pequeño:
time tar --concatenate -vf buffer.100025.tar buffer.100026.tar
real 65m33.524s
user 0m7.324s
sys 2m50.399s
time cat buffer.100027.tar >> buffer.100028.tar
real 46m34.101s
user 0m0.853s
sys 1m46.133s
Los archivos buffer.*.tar tienen un tamaño de 100 GB, el sistema estaba prácticamente inactivo excepto por cada una de las llamadas. La diferencia de tiempo es lo suficientemente significativa como para que personalmente considere que este punto de referencia es válido a pesar del pequeño tamaño de la muestra, pero usted es libre de juzgar esto y probablemente sea mejor que ejecute un punto de referencia como este en su propio hardware.
Respuesta3
Como ha indicado, el archivo de destino debe leerse hasta el final antes de agregarle el segundo archivo de origen. GNU tar tiene una -nopción que le indica que asuma que un archivo se puede buscar (recuerde que tar fue diseñado para archivos en cinta y secuencias que no se pueden buscar). GNU tar supuestamente detecta automáticamente de forma predeterminada si un archivo es buscable, sin embargo, muchos usuarios como usted pueden asegurarse de que tar omita la lectura del contenido completo de cada registro agregando la -nopción:
tar -n --concatenate --file=target_file.tar other_file.tar
No puedo verificar (en el momento de escribir este artículo) qué versiones de tar, si las hay, funcionarán como se esperaba para este comando. Si otros usuarios tienen la capacidad de probar esta solución, comente a continuación y actualizaré esta respuesta en consecuencia.
Respuesta4
Como la concatenación requiere un uso intensivo de E/S, recomendaría que sean necesarios 3 SSD (1 TB) en un RAID 0. Un solo SSD en sata 3 proporcionará 500 MB/s de lectura y similar para escritura. Caro, sí, pero rápido x3.