Впрочем, иной раз дефрагментация необходима, когда на файловую систему идёт активная дозапись-перезапись файлов и fsck показывает процент выше 25-30. Далее см. `man tar`.
Conclusion
Though I only tested two PC's, here's what I found: File fragmentation mainly happens in filesystems which contain some large files. You don't have to worry about your /usr or /var directory being fragmented, since they don't contain many large files. As the results show, it's worth the effort to try Con Kolivas defragmentation script.
Кажется процент тех, кто верит, что дефрагментация ускоряет работу ldconfig в полтора раза, стремительно падает.
Он утверждал это на примере вендовой игрушке под вендой. Т.е. в качестве примера предлагалось практически однозадачная ситуация. Всем желающим можно предложить дефрагментировать систему с помощью этого скрипта и проверить, насколько быстрее будет работать команда ldconfig.
>Он утверждал это на примере вендовой игрушке под вендой.
Это один из вторичных примеров. Первичный же - это насколько система начинает летать после переноса её на новый раздел. У меня уже назрело по ходу сразу на двух машинах.
>Вообще, этот Крон все время жалуется, что у него что-то глючит и не работает.
Конечно. У каждого что-то работает, а что-то глючит. Ничего не глючит только у тех, кто комп не включал никогда. Нет, прошу прощения, только у тех, кто не рождался никогда, ибо глюки компами не ограничиваются. Говорить о том, что прекрасно работает - неинтересно. Разве что в сравнении с другими глюками у других. А вот на глюки жаловаться полезно. Может неожиданно найтись решение, подсказанное коллективным разумом :)
> Основная причина - это любовь к дефрагментации с помощью mv.
И что, у диска большого размера вдруг seek станет в 1000 раз меньше? У меня, как бы, итак дома винты 2*250+4*80+мелочь, а на работе - 200Г забитые всего процентов на 20.
Мое мнение основано на чисто теоретических рассуждениях. Для себя считаю что необходимости в дефрагментации нет. На корне свободное пространство есть, помойка отделена.
Практика показывает все. Ради интереса надо будет когда-нибудь попробовать перенос системы, тогда и будет материал для оценок.
Человек вроде адекватный говорит о своем опыте, по умолчанию предполагается что доверять можно, но оценка "все начало летать" все-же относительна.
>Сделайте ldconfig до и после.
Холодный запуск на недавно обновлённой системе.
# time ldconfig
real 0m0.171s
user 0m0.080s
sys 0m0.072s
>И размер /etc/ld.so.cache
# ls -l /etc/ld.so.cache
-rw-r--r-- 1 root root 188505 Dec 16 13:48 /etc/ld.so.cache
>Заодно посмотрим,что там у вас процессе mv потерялось.
А с чего хоть что-нибудь должно теряться. Неужели никогда систему
на новый HDD не переносили? Или, как в Windows, новый винт - новая установка? :)
...
Недавно, вон, переносил систему с полной заменой архитектуры
(Athlon XP (32 бита, естественно)/PATA/NVidia -> Core2Duo/SATA/Intel),
так тоже ничего не переставлялось...
В смысле до и после дефрагментации. Казалось бы, ldconfig должен быть
очень чувствительным к скорости файловой системы, однако скорость его
работы практически линейно зависит от размеров кэша (т.е. сколько
много библиотек находится в каталогах */lib/*).
#time ldconfig
real 0m0.060s
user 0m0.000s
sys 0m0.060s
#ls -lA /etc/ld.so.cache
-rw-r--r-- 1 root root 70931 2007-12-16 14:44 /etc/ld.so.cache
GNU DETAILS
The GNU implementation (in fileutils-3.16) is broken in the sense that
mv can move only regular files across filesystems.
>но оценка "все начало летать" все-же относительна.
Если более конкретно, то на тех же плотных дисковых операциях система проводит меньше времени в IO-Wait и даже при более высоком IO-Wait ниже латентность GUI. И окошки таскаются более плавно, и меню открываются без задержек...
Особенно хорошо это заметно в Gentoo при компиляции чего-нибудь, типа kdelibs. На "старой" установке в отдельные моменты система буквально "затыкается", вплоть до затыков воспроизведения музыки. При чём это явно не фрагментированность /var/tmp, в котором идёт сборка, так как сей каталог висит на отдельном разделе и раздел регулярно чистится. И тормозить начинает не при компиляции, а при линковке. Т.е. налицо - проблемы со скоростью доступа к основным системным библиотекам. После же переноса системы на новый раздел - тормозить перестаёт, kdelibs в фоне собирается незаметно :)
...
А вот с конкретными цифрами, увы, тут помочь нечем, как я уже отмечал. Во-первых, подобные мероприятия - процедура нечастая, так как возни много, во-вторых, чётко измеримых параметров - нет.
...
Сейчас вывел монитор загрузки CPU на машине, где идёт компиляция. Во время компиляции - чистый nice при полном отсутствии io-wait. Configure - каша из nice и небольших io-wait. При ldconfig - 100%-й долгий (секунд по 30..40? - точно не измерял) io-wait. Скрины с примерами попозже подкину, что-то мой колокейшн сейчас недоступен, а Агава не отзывается на звонки.
Была бы команда полного сброса кешей и буферов... :) Ну да объёмная компиляция, похоже, кеш хорошо вычищает. Сейчас проверю, сравню несколько машин с разным уровнем фрагментации.
>Перезагружаться неохота, аптайм с утра сбивает показатель?
Походу, ldconfig сразу после установки пакета и ldconfig в произвольный момент времени - две принципиально разных вещи :) В общем, первый результат: Celeron-1700, 1G, системе года полтора, время выполнения ">>> Regenerating /etc/ld.so.cache..." при emerge - 39.7 сек, ждите результатов с ещё двух систем :)
(А "чистый" ldconfig на это системе работает 0.5сек)
>Вторая машина, Core2Duo, 2G, системе около двух месяцев, время выполнение ldconfig во время emerge заметить не получается :) Меньше полусекунды.
После сборки толстого пакета djvu, судя по всему, был вычищен кеш. На этой машине ldconfig проработал теперь не просто заметно, а приличное время - 21.7сек.
Итого, округлённо:
Core2Duo, 2 месяца - 20 секунд.
P4-3000, полгода - 30 секунд.
Celeron-1700, полтора года - 40 секунд.
...
Недостоверно :) Насколько мощность процессора важна для ldconfig?
Можно слепить синтетический тест - выделить раздел, измерить скорость каких-то операций (скажем, ядро запаковать), потом долго мурыжить его стиранием/удалением нужных и временных файлов (если получится так поднять фрагментацию) и измерить снова. Но мне это уже как-то влом ;)
Да нет, берется помойка, разворачивается и грепается. Хотя после распаковки оно в значительной степени в кеше и будет, но можно архив взять размером побольше оперативки.
>а, поднять фрагментацию - так вроде речь о разных машинах идет
Да, у меня на одной машине до и после "дефрага мувом" измерить не получится, элементарно нет времени и желания особого заниматься чисткой винта / переразбиением / переносом... В принципе, предстоит покупка ещё одного HDD в массив, под это дело можно будет и "почистить" самую тормозную машину, но будет это вряд ли раньше конца января :)