¿Cómo contar el tamaño total del directorio y por qué la salida de `du` difiere entre las copias del directorio?

Question 1

No olvide que duinforma el uso del disco en el nivel del sistema de archivos subyacente sin formato, no en el nivel aparente "tamaño del archivo" nivel... ver --apparent-size.

--apparent-size

imprimir tamaños aparentes, en lugar del uso del disco; Aunque el tamaño aparente suele ser menor, puede ser mayor debido a agujeros en archivos ('escasos'), fragmentación interna, bloques indirectos y similares.

Ver también -b, cuál podría ser una mejor opción que dar--block-size=1 y --apparent-sizejuntos:

-b,--bytes

equivalente a--apparent-size --block-size=1

... entonces, ¿ du -bs ${dir}produce mejores resultados?

Dado que la mayoría o todos los sistemas de archivos se basan en bloques de tamaño fijo, es muy común ver el aparente "Tamaño del archivo" (es decir, la cantidad de bytes que podría leer de un archivo) difieren del espacio real utilizado en el disco (es decir, la cantidad de bytes consumidos para almacenar este archivo y sus metadatos).

Por ejemplo:

Los archivos pequeños normalmente utilizan más espacio del que "debería"... en un sistema de archivos con bloques de 4 KB, no es posible que un archivo utilice menos de 4 KB de espacio en disco, incluso si solo almacena un byte.
Los archivos de gran tamaño suelen construirse a partir de varios archivos "extensiones"... una extensión describirá dónde ubicar los datos de una parte del archivo. Las extensiones también consumen espacio en el disco.
- En un sistema de archivos sin fragmentación (es decir, grandes espacios de espacio no utilizado), es posible tener un "grande"archivo con una sola extensión.
- En un sistema de archivos con mucha fragmentación (es decir, muchos datos por todas partes, dejando pequeños espacios entre los datos), lo mismo "grande"El archivo puede tener en realidad varias extensiones utilizadas para indicar dónde se almacenan los datos.

Depende completamente del orden en que se colocaron los archivos en el disco y de los algoritmos que se utilizan para buscar bloques contiguos de espacio libre.

Podría tener un sistema de archivos que ahorre mucho espacio y que reorganice de forma continua y cuidadosa todos los archivos de modo que queden perfectamente teselados, como un tablero de Tetris bien jugado. El sistema de archivos terminaría dedicando mucho tiempo a buscar el espacio adecuado y el rendimiento se vería afectado drásticamente.

Del mismo modo, podría tener un sistema de archivos muy orientado a la fragmentación, que sólo utilice los primeros bloques no utilizados y se salte los bloques usados. Escribir datos desde el primer paso también diezmará su rendimiento.

En cambio, preferimos equilibrar las cosas, gastaralgunotiempo (pero no demasiado) para buscar un bloque contiguo de espacio no utilizado que contendrá la totalidad de los datos que intentamos escribir.

El nivel de fragmentación de un archivo no está directamente relacionado con el orden en que se emitieron los comandos de copia, en parte debido a "inténtalo, pero no demasiado" enfoque descrito anteriormente.

En resumen, los datos almacenados en estos dos directorios deberían ser los mismos, pero el uso del disco (incluso paralos mismos datos) es poco probable que coincida perfectamente.

Hay varias opciones para verificar que los datos almacenados sean los mismos; inténtelo diff(ningún resultado es bueno, informará los cambios):

diff -qr "${src}" "${dst}"

Para complicar esto aún más, es posible que los archivos dispersos puedan usarsignificativamentemenos de lo esperado:

$ truncate -s 100M x
$ ls -l x
-rw-r--r-- 1 attie attie 104857600 Jul 14 17:15 x
$ du --block-size 1 x
0       x
$ du -bs x
104857600       x

Answer