Войти

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


VictorSh
20-07-2011, 20:17
Здравствуйте.

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

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

Команда, которой я воспользовался для копирования (СПОСОБ 1):

#nohup cp -P -R -p /data /mnt/data2 > /usr/home/XXXX/cp.txt


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


Filesystem Size Used Avail Capacity Mounted on
/dev/ad4s1a 496M 331M 125M 73% /
devfs 1.0K 1.0K 0B 100% /dev
/dev/ad4s1d 124M 566K 113M 0% /tmp
/dev/ad4s1f 3.9G 2.7G 846M 77% /usr
/dev/ad4s1g 65G 4.3G 55G 7% /usr/data
/dev/ad4s1e 990M 333M 578M 37% /var
/dev/da0 1.1T 984G 12G 99% /data
/dev/ad6p1 2.6T 1.4T 1.0T 58% /mnt/data2
devfs 1.0K 1.0K 0B 100% /var/named/dev


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

# newfs command for /dev/da0 (/dev/da0)
newfs -O 2 -U -a 8 -b 16384 -d 16384 -e 2048 -f 2048 -g 16384 -h 64 -m 8 -o time -s 585921024 /dev/da0


Для ad6 та же команда выдает:

# newfs command for /dev/ad6p1 (/dev/ad6p1)
newfs -O 2 -U -a 32 -b 4096 -d 4096 -e 512 -f 2048 -g 16384 -h 64 -m 8 -o time -s 1465133275 /dev/ad6p1


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

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

Потом сделал СПОСОБ 2.
Удалил GPT разделы с внешнего диска. Пересоздал. Инициализировал ФС на ad6 с помощью команды:

# newfs command for /dev/da0 (/dev/da0)
newfs -O 2 -U -a 8 -b 16384 -d 16384 -e 2048 -f 2048 -g 16384 -h 64 -m 4 /dev/ad6p1


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


[root@server /usr/home/XXXX]# df -h
Filesystem Size Used Avail Capacity Mounted on
/dev/ad4s1a 496M 331M 125M 73% /
devfs 1.0K 1.0K 0B 100% /dev
/dev/ad4s1d 124M 570K 113M 0% /tmp
/dev/ad4s1f 3.9G 2.7G 846M 77% /usr
/dev/ad4s1g 65G 4.3G 55G 7% /usr/data
/dev/ad4s1e 990M 337M 574M 37% /var
/dev/da0 1.1T 992G 3.9G 100% /data
devfs 1.0K 1.0K 0B 100% /var/named/dev
/dev/ad6p1 2.6T 726G 1.8T 28% /mnt/data2


Размер 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, так как они сохраняют все в один файл-образ.

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

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

bozordzh
26-07-2011, 00:43
Вроде бы UFS2 - журналируемая файловая система »
нет, она не имеет журнала, журнал можно прикрутить по желанию man gjournal. а фрагментация да, минимальны, у меня на каком то тазике, где бд крутилась гигов на 150, круглогодично, за пару лет фрагментация и за 8% помницо не перевалила.
Не пойму как мне убедиться, что все скопировалось правильно? » ну самый простой способ сверить хеши файлов, можно и скриптик какой простенький своять, если файлов много:)

bozordzh
26-07-2011, 03:11
может ещё в таблице inodes колличество резервируемых записей кончилось, место свободное есть а писаца туда не может.

VictorSh
26-07-2011, 22:03
может ещё в таблице inodes колличество резервируемых записей кончилось, место свободное есть а писаца туда не может. »
а как это проверить?

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

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

vadblm
31-07-2011, 15:10
P.S. Не хочется пользоваться командой dump/restore, так как они сохраняют все в один файл-образ. »
И напрасно. Это позволяет минимизировать занимаемое бекапом место, особенно при использовании сжатия и максимально упростить развёртывание. Также даётся 100% гарантия идентичности данных, а также полное сохранение всех прав, ссылок и т.п.

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

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

VictorSh
31-07-2011, 18:53
И напрасно. »
Ну я ей все таки воспользовался для создания дампа системы.

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

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

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

vadblm
31-07-2011, 18:57
А как узнать реальный размер .snap »
Да нет у неё реального размера. Это снепшот. Виртуальная папка с образом фс на определённое число.
Читайте тут http://www.freebsd.org/doc/ru/books/handbook/snapshots.html

VictorSh
31-07-2011, 19:09
Читайте тут http://www.freebsd.org/doc/ru/books/...snapshots.html »
Я читал, но не понял, они же место вроде бы должны занимать. Написано, Записываются в суперблок.

vadblm
31-07-2011, 20:09
Скажем так, в снепшоты физически записываются дельты, но не более. Вы сами понимаете, что снепшот ну никак физически не может превышать размер диска/тома.




© OSzone.net 2001-2012