Получить размер каталога (включая все его содержимое) независимо от использования диска.

Вам, вероятно, следует взглянуть наsplit:

Вот справочная страница с примерами:

https://ss64.com/bash/split.html

2
31.08.2019, 14:32
2 ответа

Rsync и другие инструменты не будут точно копировать каталоги. Они могут или не могут точно копировать разреженные файлы. Это не то, о чем следует беспокоиться в целом.

Рассмотрим следующий пример bash.

 mkdir -p /tmp/demo/a
 cd /tmp/demo/a
 touch {1..10000}
 ls -ld

это создает 10 000 файлов и перечисляет размер каталога, в котором они хранятся. В моей системе я получаю каталог размером 155648 байт. Теперь удалите 9000 из них и снова проверьте размер.

 rm ????
 ls -ld

Размер каталога у меня не изменился и составляет 155648 байт. Теперь сделайте копию, здесь я использую cp, но это может быть rsyncили cpioили что-то еще, что копирует файлы

 cd..
 cp -r a b
 ls -l

Для меня каталог bзанимает всего 20 480 байт, т.е. на 135 168 меньше. Это связано с тем, что в каталоге aесть место для записи файла 3141, который был удален, но в каталоге bэто место не выделено.

3
27.01.2020, 21:53

Обратите внимание, что duдаже GNU с его опцией --apparent-sizeбудет включать видимый размер (, указанный вlstat())всех типов файлов, включая обычные файлы , устройства , символические ссылки , fifos , каталоги . GNU du, как и многие другие реализации, будет пытаться не учитывать один и тот же файл несколько раз (, например, когда есть несколько жестких ссылок на один и тот же файл ).

Здесь, поскольку вы не передаете опцию -Hв rsync, жесткие ссылки не будут сохранены, поэтому исключение дубликатов в учетной записи duприведет к несоответствию, если в учетной записи есть жесткие ссылки. источник.

Видимый размер файла типа каталог действительно представляет собой реальный размер его данных:список имен файлов вместе с информацией о том, где их найти, но формат и размер этого списка зависит от типа файловой системы, ее настройки и заполнения каталога.

Для файлов устройств, fifos,сокеты, для которых rsyncне передают никаких данных, некоторые системы (, такие как Linux ), всегда возвращают 0 в качестве видимого размера, некоторые возвращают количество данных, которое можно было прочитать из них (для блочного устройства файлов, например, это может быть размер соответствующего хранилища ).

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

Вы можете сделать это с помощью GNU findс помощью:

find. -type f,l -printf '%s\n' | awk '{s+=$0}; END{print s}'

Если вы обнаружите одинаковый номер в источнике и получателе, это может указывать на то, что rsyncвозможно, удалось передать все данные,(содержимое обычных файлов и символические ссылки, (их цель путь )). Возможно, ему не удалось передать все метаданные, такие как расширенные атрибуты, ACL (, которые вы все равно не сохраняете, поскольку вы не передали параметры -Xи -A), имена файлов, пустые файлы...

В качестве согласованного представления количества данных каталогов (при условии отсутствия проблем с кодировкой¹ )вы можете использоватьfind. | wc -c(сумму всех путей к файлам + 1 ).

Вы также можете повторно -запустить ту же команду rsyncс-n(dry -run )и-v(verbose ), чтобы проверить, не пропало ли что-то, возможно, добавив --deleteчтобы также проверить файлы, которые находятся в месте назначения, а не в источнике.


¹ Строго говоря, размеры символических ссылок могут различаться, если над именами файлов выполняются некоторые преобразования, например, в некоторых случаях преобразования кодировки символов для символов, отличных от -ASCII, особенно если задействованы файловые системы, отличные от -Unix или macOS

3
27.01.2020, 21:53

Теги

Похожие вопросы