Sander_Marechal решил (http://lxer.com/module/newswire/view/96989/index.html) собственноручно убедится в отсутствии необходимости использования программ для дефрагментации файловой системы в Linux.
Вывод: для ощутимого повышения уровня фрагментации файлов в ФС (ReiserFS) пришлось постараться. После запуска defrag (http://ck.kolivas.org/apps/defrag/defrag-0.06/defrag) скрипта от Con Kolivas, фрагментация опять упала до приемлемого уровня (суть скрипта в сортировке файлов по их размеру с последующим переименованием и копированием). Мелкие файлы мало влияют на уровень фрагментации ФC, фрагментация повышается только при наличии крупных файлов.
Дополнение: Вадим Калинников подготовил заметку (http://ylsoftware.com/?action=news&na=viewfull&news=379) на основе текста статьи.URL: http://lxer.com/module/newswire/view/96989/index.html
Новость: http://www.opennet.me/opennews/art.shtml?num=13179
Ну, это было понятно давно -- исходя из логики работы аллокатора reiserfs.
на самом деле, если верить рассылке freebsd-stable@, если файл нефрагментированный, то это не значит что он одним куском на диске лежит. если я правильно понял %-) так что, в реальности фрагментация - не показатель. Даже если она равна нулю, всё-равно файлы не лежат штабелями. я с тех пор на этот показатель внимания не обращаю, т.к. он нерепрезентативен... :(
Не правильно. Презентативен, обращают. Фрагментация просто разная бывает.
Да-да! Бывает Фрагментированно, но так, что недеврагментированно! %)))) Сам видел!!! =))))
>если файл нефрагментированный, то это не значит что он одним куском на диске лежитДефрагментация хороша уже тем, что "куски" рядом лежат, последовательно друг за другом. Упреждающее чтение даст повышение производительности (HDD придется меньше головками двигать).
Дефрагментированные файлы проще найти и восстановить после аварийного сбоя, если нет бэкапа, конечно.
Кстати, если фрагменты файлов записывать попеременно на разные стороны (блины) жесткого диска, то можно добиться параллельной работы нескольких головок.
Это не всё не столь актуально в нынешних файловых системах (с другим расположением инод и прочих метаданных), особенно в условиях многозадачности и наличия кэшей. Более того, есть и практики намеренного фрагментирования файлов для общего ускорения в конечном счете - навроде этой самой записи на разные блины, но не такое - потому что реальная геометрия винтов уже давно оторвана от той, которую видит ОС.
... Нужна, нужна... и обязательно с красивыми мигающими квадратиками, ala O&O Defrag :)
Я бы еще отметил, что сам факт фрагментации начинает появляться при недостатке свободного места на диске, если процентов 20% свободно, то и беспокоиться не о чем. Серьёзно задуматься о чистке нужно, когда в логе появятся сообщения о изменении политики оптимизации с "time" на "space".
Например, для запускаемых файлов (которые практически никогда не меняются) оптимальна "плотная укладка", когда не резервируется место под возможное расширение файла. Так что /usr надо дефрагментировать одним способом, а /var надо дефрагментировать совершенно иначе. У Norton SpeedDisk была возможность выбора алгоритма/цели дефрагментации вплоть до "собрать директории вместе (для ускорения поиска файлов по имени)".
Это давно неактуально для современных файловых систем.