Soy un estudiante graduado de química computacional con acceso a un clúster de Linux. El clúster consta de un servidor de archivos muy grande (25 TB), al que están conectadas varias docenas de nodos de cómputo. Cada nodo de cómputo consta de 8 a 24 núcleos Intel Xeon. Cada nodo de proceso también contiene un disco local de aproximadamente 365 TB.
Dado que el servidor de archivos es accedido rutinariamente por una docena de usuarios en el grupo de investigación, el servidor de archivos se utiliza principalmente para el almacenamiento de archivos a largo plazo (se realiza una copia de seguridad todas las noches, mientras que los discos locales de los nodos de cómputo nunca se respaldan). Por lo tanto, el administrador del sistema nos ha indicado que ejecutemos simulaciones en los discos locales, que tienen E / S más rápidas que el servidor de archivos, para no ralentizar el servidor de archivos para los demás usuarios.
Entonces, ejecuto simulaciones en los discos locales y luego, una vez que terminan, copio los archivos de trayectoria (estoy ejecutando simulaciones de dinámica molecular (MD)) en el servidor de archivos para su almacenamiento. Supongamos que tengo un archivo llamado trayectoria traj.trr
en un directorio en el disco local de un nodo, /home/myusername/mysimulation1/traj.trr
. Para el almacenamiento a largo plazo, siempre copio traj.trr
a un directorio en el servidor de archivos, ~/mysimulation1/traj.trr
donde ~
representa mi directorio en el servidor de archivos, /export/home/myusername
. Después de copiarlo, lo uso habitualmente du -h
para verificar que /home/myusername/mysimulation1/traj.trr
tenga el mismo tamaño de archivo que ~/mysimulation1/traj.trr
. De esta manera, puedo estar al menos razonablemente seguro de que la transferencia al servidor de archivos fue exitosa. Por ejemplo:
cd /home/myusername/mysimulation1/
cp -v traj.trr ~/mysimulation1/
du /home/myusername/mysimulation1/traj.trr -h
du ~/mysimulation1/traj.trr -h
Si las dos llamadas du -h
dan el mismo tamaño de archivo legible por humanos, entonces puedo estar razonablemente seguro de que la transferencia / copia fue exitosa. (Mis traj.trr
archivos típicos varían en tamaño de aproximadamente 15 a 20 GB, dependiendo de la simulación exacta que he ejecutado). Si ejecuto du
(es decir, sin el -h
interruptor) en los dos traj.trr
archivos, sus tamaños en bytes son generalmente muy, muy similares. - generalmente dentro de unos pocos bytes. He estado usando este método general durante el último año y medio, sin problemas.
Sin embargo, recientemente me he encontrado con el siguiente problema: a vecesdu -h
informa quetraj.trr
varios archivos tienen un tamaño diferente en varios GB. Aquí hay un ejemplo:
cd /home/myusername/mysimulation1/ # this is the local disk
cp -v traj.trr ~/mysimulation1/
du traj.trr -h
cd ~/mysimulation1/ # this is the fileserver
du traj.trr -h
El resultado de las dos llamadas a du -h
es el siguiente, respectivamente:
20G traj.trr
28G traj.trr
Creo que el primero (es decir, traj.trr
en el disco local /home/myusername/mysimulation1/
) es el tamaño de archivo correcto, ya que se espera que mis trayectorias de simulación sean de aproximadamente 15 a 20 GB cada una. Pero entonces, ¿cómo podría el archivo en el servidor de archivos en realidad ser más grande ? Pude ver cómo podría ser más pequeño, si de alguna manera la cp
transferencia fallara. Pero no veo cómo podría ser más grande .
Obtengo resultados similares cuando ejecuto los mismos comandos que arriba, pero sin el -h
interruptor dado a du
:
20717480 traj.trr
28666688 traj.trr
¿Se te ocurre alguna razón para la diferencia?
Si, por alguna improbable oportunidad, de du
alguna manera funciona mal, puedo estar de acuerdo con eso. Pero realmente necesito asegurarme de que la copia del traj.trr
servidor de archivos esté completa e sea idéntica a su versión de origen en el disco local. Necesito eliminar el archivo local para tener suficiente espacio en el disco local para ejecutar nuevas simulaciones, pero no puedo permitir que la versión del traj.trr
servidor de archivos esté dañada.
El formato de archivo .trr (del paquete de dinámica molecular Gromacs) es un formato binario, no texto. Por lo tanto, no estoy seguro si los archivos pueden ser comparados de manera confiable por un programa como diff
.
fuente
md5sum
osha1sum
en los archivos. ¿Se complementan?md5sum
en los dos archivos. Las dos sumas de verificación coinciden. Entonces, ¿supongo que esto significa que los dos archivos son iguales?ls -l
? El comandodu
informa cuánto espacio en el disco se utiliza para su archivo, no qué tan grande es su archivo. El tamaño del disco puede verse influenciado por su sistema de archivos y sus estrategias de asignación.ls -l -h
dice que ambos archivos son de 20 GB. Del mismo modo,ls -l
dice que ambos archivos son 21214683940 bytes. Así que supongo que los archivos son del mismo tamaño, pero no usan la misma cantidad de espacio en disco (segúndu
).Respuestas:
Realmente deberías usar algo como
md5sum
osha1sum
para verificar la integridad.Si realmente quieres usar el tamaño, usa
ls -l
odu -b
.La
du
utilidad normalmente solo muestra el uso del disco en el archivo, es decir, qué cantidad del sistema de archivos utiliza. Este valor depende totalmente del sistema de archivos de respaldo y otros factores como los archivos dispersos.Ejemplo:
Tenemos dos archivos que contienen 512 MB de ceros. El primero se almacena escaso y no utiliza ningún espacio en disco, mientras que el segundo almacena cada byte explícitamente en el disco. - Mismo archivo, pero uso de disco completamente diferente.
La
-b
opción puede ser buena para ti:fuente
Este es un problema común cuando coloca los mismos datos en 2 discos duros diferentes. Querrá ejecutar el
du
comando con un conmutador adicional, suponiendo que lo tenga, que debería tener en cuenta que son nodos de Linux.¿El interruptor?
Ejemplo
Los sistemas de archivos anteriores son un disco local (
/root
) mientras que el otro/home/sam
es un recurso compartido NFS de mi NAS.¿Entonces que hay de nuevo?
Esto confunde a mucha gente, pero recuerde que cuando los archivos se almacenan en un disco, consumen bloques de espacio, incluso si solo usan una parte de esos bloques. Cuando ejecuta
du
sin--apparent-size
obtener el tamaño en función de la cantidad de espacio de bloque utilizado en el disco, no el espacio real consumido por los archivos.usando una suma de verificación en su lugar?
Esta es probablemente una mejor opción si le preocupa comparar 2 árboles de archivos. Puede usar este comando para calcular una suma de verificación para todos los archivos y luego calcular una suma de verificación final de sumas de verificación. Este ejemplo usa,
sha1sum
pero podría usarlo con la misma facilidadmd5sum
.Ejemplo
Entonces podemos ver que los 2 árboles son idénticos.
(Nota: el comando find enumerará los archivos tal como aparecieron en el sistema de archivos. Por lo tanto, si está comparando dos directorios del sistema de archivos diferente (por ejemplo, Ext3 vs. APFS), debe ordenar primero antes de la suma final sha1. Xianjun Dong)
fuente
La respuesta corta: no pruebe el tamaño del archivo, pruebe el estado de retorno del comando. El estado de retorno es la única indicación confiable de si la copia tuvo éxito (salvo comparar los dos archivos byte por byte, directamente o indirectamente, lo que es redundante si la copia tuvo éxito).
Verificar el tamaño del archivo no es una forma muy útil de verificar si una copia se realizó correctamente. En algunos casos, puede ser una comprobación de cordura útil, por ejemplo, cuando descarga un archivo de la web. Pero aquí hay una mejor manera.
Todos los comandos de Unix devuelven un estado para indicar si tuvieron éxito: 0 para el éxito, 1 o más para los errores. Así que verifique el estado de salida de
cp
.cp
normalmente habrá impreso un mensaje de error si falla, indicando cuál es el error. En un script, el estado de salida del último comando está en la variable mágica$?
.En lugar de verificar si
$?
es cero, puede usar operadores booleanos.Si está ejecutando un script y desea que el script se detenga si falla algún comando, ejecute
set -e
. Si algún comando falla (es decir, devuelve un estado distinto de cero), el script saldrá inmediatamente con el mismo estado que el comando.En cuanto a la razón por la cual el archivo copiado era más grande, debe ser porque era un archivo escaso . Los archivos dispersos son una forma cruda de compresión donde los bloques que contienen solo bytes nulos no se almacenan. Cuando copia un archivo, el
cp
comando lee y escribe bytes nulos, por lo que cuando el original tenía bloques faltantes, la copia tiene bloques llenos de bytes nulos. En Linux, elcp
comando intenta detectar archivos dispersos, pero no siempre tiene éxito;cp --sparse=always
hace que se esfuerce más a expensas de un ligero aumento en el tiempo de CPU.De manera más general,
du
podría arrojar resultados diferentes debido a otras formas de compresión. Sin embargo, los sistemas de archivos comprimidos son raros. Si desea saber el tamaño de un archivo como el número de bytes en el archivo, en lugar del número de bloques de disco que usa, use enls -l
lugar dedu
.fuente