Как подсчитать общий размер каталога и почему вывод `du` отличается между копиями каталога?

Question 1

Не забывайте, что duотчеты об использовании диска на уровне базовой файловой системы, а не на видимом уровне "размер файла"уровень... см --apparent-size.

--apparent-size

выводить видимые размеры, а не использование диска; хотя видимый размер обычно меньше, он может быть больше из-за дыр в («разреженных») файлах, внутренней фрагментации, косвенных блоков и т. п.

Смотрите также -b, что может быть лучшим вариантом для предоставления--block-size=1 и --apparent-sizeвместе:

-b,--bytes

эквивалентно--apparent-size --block-size=1

... так что, du -bs ${dir}дает лучшие результаты?

Учитывая, что большинство файловых систем основаны на блоках фиксированного размера, очень часто можно увидеть кажущуюся "Размер файла" (т. е. количество байтов, которые вы сможете прочитать из файла) отличается от фактического используемого пространства на диске (т. е. количества байтов, использованных для хранения этого файла и его метаданных).

Например:

Небольшие файлы обычно занимают больше места, чем они "должен«... в файловой системе с блоками размером 4 КБ невозможно, чтобы файл использовал менее 4 КБ дискового пространства, даже если он хранит только один байт.
Большие файлы обычно состоят из нескольких "экстенты«... экстент описывает, где размещать данные для части файла. Экстенты также занимают дисковое пространство.
- В файловой системе без фрагментации (т. е. без больших промежутков неиспользуемого пространства) возможно наличие "большой"файл только с одним экстентом.
- В файловой системе с высокой степенью фрагментации (т. е. множество данных, разбросанных по всему пространству, с небольшими промежутками между данными), то же самое "большой"Файл на самом деле может иметь несколько экстентов, используемых для указания места хранения данных.

Это полностью зависит от порядка размещения файлов на диске и алгоритмов, используемых для поиска смежных блоков свободного пространства.

У вас может быть очень эффективная файловая система, которая непрерывно и тщательно переупорядочивает все файлы так, чтобы они были идеально мозаичными, как доска для хорошо сыгранного тетриса. Файловая система в конечном итоге тратила бы много времени на поиск подходящего места, и производительность бы сильно пострадала.

Точно так же у вас может быть очень фрагментированная файловая система, которая использует только первые неиспользуемые блоки и пропускает используемые блоки. Запись данных на основе первого пробела также подорвет вашу производительность.

Вместо этого мы предпочитаем балансировать, тратянекоторыйвремя (но не слишком много) для поиска непрерывного блока неиспользуемого пространства, который будет содержать все данные, которые мы пытаемся записать.

Уровень фрагментации файла не связан напрямую с порядком, в котором были выданы команды копирования, отчасти из-за "попробуй, но не слишком сильно"подход, описанный выше.

Подводя итог, можно сказать, что данные, хранящиеся в этих двух каталогах, должны быть одинаковыми, но использование диска (даже дляте же данные) вряд ли будет совпадать идеально.

Есть несколько вариантов проверки того, что сохраненные данные одинаковы — попробуйте diff(отсутствие выходных данных недопустимо, программа сообщит об изменениях):

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

Чтобы еще больше усложнить ситуацию, возможно, что разреженные файлы могут использоватьсущественноменьше, чем ожидалось:

$ 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