что думаете про такой дефрагментатор

Думаем, что разработчики файловых систем уже высказались, что фрагментация на 2-4% некритична.

> "Braindead fs-agnostic defrag"

Бгггг!!!!

Впрочем, иной раз дефрагментация необходима, когда на файловую систему идёт активная дозапись-перезапись файлов и 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 в полтора раза, стремительно падает.

> разработчики файловых систем уже высказались, что фрагментация на 2-4% некритична.

KRoN73 утверждал, что дефрагментация командой mv ускоряла работу системы заметно и ощутимо.

Он утверждал это на примере вендовой игрушке под вендой. Т.е. в качестве примера предлагалось практически однозадачная ситуация. Всем желающим можно предложить дефрагментировать систему с помощью этого скрипта и проверить, насколько быстрее будет работать команда ldconfig.

Вообще, этот Крон все время жалуется, что у него что-то глючит и не работает. Основная причина - это любовь к дефрагментации с помощью mv.

Речь идёт вот об этом треде (если кто заинтересуется): http://www.linux.org.ru/view-message.jsp?msgid=2297598#2299618

Синус, а вы своё мнение о дефрагментации ещё не изменили?

>Думаем, что разработчики файловых систем уже высказались, что фрагментация на 2-4% некритична.

1. Зато критичной может быть фрагментация свободного пространства.

2. У меня на основных рабочих разделах (xfs, reiserfs, ext3) фрагментация сейчас более 20%.

>Он утверждал это на примере вендовой игрушке под вендой.

Это один из вторичных примеров. Первичный же - это насколько система начинает летать после переноса её на новый раздел. У меня уже назрело по ходу сразу на двух машинах.

>Вообще, этот Крон все время жалуется, что у него что-то глючит и не работает.

Конечно. У каждого что-то работает, а что-то глючит. Ничего не глючит только у тех, кто комп не включал никогда. Нет, прошу прощения, только у тех, кто не рождался никогда, ибо глюки компами не ограничиваются. Говорить о том, что прекрасно работает - неинтересно. Разве что в сравнении с другими глюками у других. А вот на глюки жаловаться полезно. Может неожиданно найтись решение, подсказанное коллективным разумом :)

> Основная причина - это любовь к дефрагментации с помощью mv.

4.2, однако :D

>У меня уже назрело по ходу сразу на двух машинах.

Вот и сделвейте бенчмарк. А то, может быть, вы какой-то жизненно важный орган перенести забываете, после чего все начинает бегать (но недолго, хехе).

>> критичной может быть фрагментация свободного пространства.

Купи диск большего размера.

>Вот и сделвейте бенчмарк.

И как это, по-Вашему, можно сделать? :) Это, ведь, не FPS измерить и не размер файла оценить...

>Купи диск большего размера.

И что, у диска большого размера вдруг seek станет в 1000 раз меньше? У меня, как бы, итак дома винты 2*250+4*80+мелочь, а на работе - 200Г забитые всего процентов на 20.

Сделайте ldconfig до и после. И размер /etc/ld.so.cache. Заодно посмотрим,что там у вас процессе mv потерялось.

Мое мнение основано на чисто теоретических рассуждениях. Для себя считаю что необходимости в дефрагментации нет. На корне свободное пространство есть, помойка отделена.

Практика показывает все. Ради интереса надо будет когда-нибудь попробовать перенос системы, тогда и будет материал для оценок.

Человек вроде адекватный говорит о своем опыте, по умолчанию предполагается что доверять можно, но оценка "все начало летать" все-же относительна.

>Сделайте 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 длятся десятки секунд. Размер кеша:

$ ls -lh /etc/ld.so.cache

-rw-r--r-- 1 root root 220K Dec 16 14:29 /etc/ld.so.cache

Была бы команда полного сброса кешей и буферов... :) Ну да объёмная компиляция, похоже, кеш хорошо вычищает. Сейчас проверю, сравню несколько машин с разным уровнем фрагментации.

> Только что отметил - на "старой" машине у меня обновлёные ldconfig длятся десятки секунд.


Не понял.

Перезагружаться неохота, аптайм с утра сбивает показатель?

time ldconfig
ldconfig 0,13s user 0,10s system 76% cpu 0,300 total

>Перезагружаться неохота, аптайм с утра сбивает показатель?

Походу, ldconfig сразу после установки пакета и ldconfig в произвольный момент времени - две принципиально разных вещи :) В общем, первый результат: Celeron-1700, 1G, системе года полтора, время выполнения ">>> Regenerating /etc/ld.so.cache..." при emerge - 39.7 сек, ждите результатов с ещё двух систем :)

(А "чистый" ldconfig на это системе работает 0.5сек)

>>При ldconfig - 100%-й долгий (секунд по 30..40? - точно не измерял) io-wait.

А это понятно? Такое впечатление, что отваливается по какому-то таймауту.

Вторая машина, Core2Duo, 2G, системе около двух месяцев, время выполнение ldconfig во время emerge заметить не получается :) Меньше полусекунды.

...

На третьей (P4-3000, 1G, около полугода) результат будет нескоро, там как раз kdelibs пересобирается ;)

>Такое впечатление, что отваливается по какому-то таймауту.

Нет, работает-то прекрасно :) 100% io-wait показывает очень высокую интенсивность дисковых операций.

>На третьей (P4-3000, 1G, около полугода) результат будет нескоро, там как раз kdelibs пересобирается ;)

Пересобрался, первый же после установки kdelibs ldconfig выполнялся 30.8 сек, второй - мгновенно.

>Вторая машина, Core2Duo, 2G, системе около двух месяцев, время выполнение ldconfig во время emerge заметить не получается :) Меньше полусекунды.

После сборки толстого пакета djvu, судя по всему, был вычищен кеш. На этой машине ldconfig проработал теперь не просто заметно, а приличное время - 21.7сек.

Итого, округлённо:

Core2Duo, 2 месяца - 20 секунд.
P4-3000, полгода - 30 секунд.
Celeron-1700, полтора года - 40 секунд.

...

Недостоверно :) Насколько мощность процессора важна для ldconfig?

Может быть что нибудь типа find или grep?

>Может быть что нибудь типа find или grep?

Можно слепить синтетический тест - выделить раздел, измерить скорость каких-то операций (скажем, ядро запаковать), потом долго мурыжить его стиранием/удалением нужных и временных файлов (если получится так поднять фрагментацию) и измерить снова. Но мне это уже как-то влом ;)

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

а, поднять фрагментацию - так вроде речь о разных машинах идет

>а, поднять фрагментацию - так вроде речь о разных машинах идет

Да, у меня на одной машине до и после "дефрага мувом" измерить не получится, элементарно нет времени и желания особого заниматься чисткой винта / переразбиением / переносом... В принципе, предстоит покупка ещё одного HDD в массив, под это дело можно будет и "почистить" самую тормозную машину, но будет это вряд ли раньше конца января :)

Недавно переносил систему на новый раздел....Субъективно намного быстрее работать стало.