При копировании размеры исходной и целевой папок сильно различаются
 

Здравствуйте.

Имеется ОС FreeBSD 6.2
При копировании на внешний винт содержимого RAID массива с помощью 2 разных способов получаются сильно отличающиеся итоговый размер источника и размер файлов на целевом диске.

Исходные файлы (RAID массив, da0) находятся в папке /data
Целевой диск ad6 я подмонтировал в /mnt/data2

Команда, которой я воспользовался для копирования (СПОСОБ 1):
Получилось, что целевый файлы занимают на 50% больше, чем исходные! Причем я задал не обходить ссылки в cp.
Вот вывод команды: df -h

Внешний винт (ad6) разбивал как GPT с помощью утилиты gpt.
Правда потом выяснилось, что размеры кластеров отличаются в /data и /mnt/data2
Вот, что выдает dumpfs -m /dev/da0
Для ad6 та же команда выдает:
НО! размер кластера в ad6 меньше! значит, что потерь на маленьких файлах должно быть меньше потерь, то есть размер по крайней мере должен быть меньше или тот же, а у меня получается намного больше!

хотя еще непонятно насчет кластера. Смотрю до создания маленького файла в какой нибудь папке ad6 размер командой du -hsx. Потом создаю файл в несколько байт, меньше 512. Смотрю опять du -hsx - разница на 2048. То же и на da0 и ad4 дисках. Хотя в newfs написано, что минимум размер кластера можно сделать 4К, а вывод dumpfs говорит, что вообще имеется 16К кластер.

Потом сделал СПОСОБ 2.
Удалил GPT разделы с внешнего диска. Пересоздал. Инициализировал ФС на ad6 с помощью команды:
Подмонтировал ad6p1 в /mnt/data2
Запустил Midnight Commander с помощью утилиты screen (так как копировать долго, чтобы можно было терминал закрыть).
Открыл в одном окне /data, а в другом /mnt/data2, нажимаю F5, из опций копирования выбраны: Using Shell Patterns и preserve attributes.
Нажимаю ОК. Через часов этак 20, когда закончится копирование, смотрю вывод команды df -h

Размер ad6 намного меньше теперь, при одинаковых файловых системах.
Пробовал заходить в каждую папку в /data и /mnt/data2 и сравнивать размеры командами:
du -hsx
LANG=C find . -type f -ls | awk '{ sum+= $7 } END { print sum }' (общее количество байт, как в Windows суммарный размер файлов, а не сколько они занимают на диске).
ls -l -R | grep ^- | wc -l (количество файлов в каждой папке)

Почти везде одиаково, в сумме даже на da0 около 727G получается, а не 992G.
Единственное, что в /data/temp и /mnt/data2/temp при одних и тех же папках (там 0 файлов) du -hsx выдает для ad6 6К, а для da0 8К.

Вопросы:
Не пойму как мне убедиться, что все скопировалось правильно?
Как правильно определить размер кластера(блока)? И почему когда я создаю один маленький файл, разница в размерах составляет число, несовпадающее с числом в newfs -b?
Почему такие сильные отличия в размерах при копировании получаются?

P.S. Не хочется пользоваться командой dump/restore, так как они сохраняют все в один файл-образ.

Какие вообще могут быть причины разлияия размера папок?
я насчитал три:
1) Сбой при копировании - не доходит копирование до конца, правда когда размер больше, то эта причина отпадает.
2) Разный размер кластера - опять у меня на маленьком кластере больше места
3) Фрагменатция диска. Вот тут не знаю. Вроде бы UFS2 - журналируемая файловая система и ей фрагментация не страшна должна быть.

Какие хотя бы не в моем случае, а вообще могут быть причины этого?

нет, она не имеет журнала, журнал можно прикрутить по желанию man gjournal. а фрагментация да, минимальны, у меня на каком то тазике, где бд крутилась гигов на 150, круглогодично, за пару лет фрагментация и за 8% помницо не перевалила.
ну самый простой способ сверить хеши файлов, можно и скриптик какой простенький своять, если файлов много:)

может ещё в таблице inodes колличество резервируемых записей кончилось, место свободное есть а писаца туда не может.

а как это проверить?

проверял md5 хеши с помощьют cfv, вроде бы сходится. Файлов очень много.

А может это быть из-за папки .snap? как раз ее я не переписывал. Но если туда зайти, там два файла, каждый из них размером как весь RAID массив (так показывает размер mc). То есть, фактически на RAID массиве есть 2 файла + сама информация, в сумме получается в 3 раза больше, чем размер RAID массива, поэтому думаю, размер этих файлов (мгновенные образы файловой системы) не настоящий.

И напрасно. Это позволяет минимизировать занимаемое бекапом место, особенно при использовании сжатия и максимально упростить развёртывание. Также даётся 100% гарантия идентичности данных, а также полное сохранение всех прав, ссылок и т.п.

Для копирования информации один-в-один лучше всего подходит rsync - все права и специальные атрибуты также сохраняются. В принципе, эта утилита задумана для удалённой синхронизации файлов, но и локально работать умеет.

На различие показаний df и du не следует обращать внимания, они показывают принципиально разные вещи - df отображает пространство, занимаемое файловой системой (с учётом резерва, с учётом того, что не все файлы помещаются точно в размер кластера и прочий оверхед), du показывает размер файлов и директорий, с ключом -s банально суммируя эти показания.
У вас снепшоты включены. Понятное дело, они вам для бекапа не нужны, но туповатый cp про это не знает. В отличие от dump.

Ну я ей все таки воспользовался для создания дампа системы.

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

Но при копировании, при сравнении разных папок одна и та же команда, применнная к оригиналу и копии (оригинал - весь отдельный диск, копия - другой отдельный диск) должна показывать одно и тоже? если ФС одинаковая.

А вот тут я синхронизировал все кроме папки .snap
А как узнать реальный размер .snap?

Да нет у неё реального размера. Это снепшот. Виртуальная папка с образом фс на определённое число.
Читайте тут http://www.freebsd.org/doc/ru/books/...snapshots.html

Я читал, но не понял, они же место вроде бы должны занимать. Написано, Записываются в суперблок.

Скажем так, в снепшоты физически записываются дельты, но не более. Вы сами понимаете, что снепшот ну никак физически не может превышать размер диска/тома.