Дефрагментация

Закончилось место на разделе с данными. Прикупил диск побольше размером. Решил разметку делать. Выбрал после долгих метаний и анализов за файловую систему ext3 (во-первых, потому что всегда пользовался ext2/3, и она меня не подводила [тьфу x 3], во-вторых по отзывам). И тут у меня всплыла старая мысля на счет фрагментированности данных будущих на разделе...

Почти весь день провел в экспериментах и чтении статей. Заливал переносимые данные на новый диск, удалял их, снова заливал... После каждой операции делал e2fsck -nvf /dev/disk. Ниже приведены выдержки из выводов e2fsck после двух смежных действий:

126038 inodes used (0.28%)        | 163249 inodes used (0.37%)
2017 non-contiguous inodes (1.6%) | 2437 non-contiguous inodes (1.5%)
52589072 blocks used (29.60%)     | 67262691 blocks used (37.86%)
5 large files                     | 5 large files

Видим, что фрагментация не слишком велика, хотя есть (после второго прохода e2fsck соотношение свободного места к занятому 246/388Gb). Всему виной является... как всегда лень: файлы при копировании я не отбирал по размеру, большие и маленькие файлы шли не по-порядку, смешиваясь. Несомненно, 5 больших файлов много меньше общего числа фрагменированных (2017 и 2437)

После этого я решил повторить процедуру, но при этом я сначала залил несколько больших файлов (образы DVD по 1-4,4Gb), а потом немного маленьких (пакеты).

20524 inodes used (0.05%)
369 non-contiguous inodes (1.8%)
5 large files

Здесь относительная фрагментация больше (но это результат несоответствия параметров экперимента). Если заполнить разделы по такому же принципу, но теми же самыми файлами, то фрагментация уменьшится (не верите -- проверьте ;-) ).

Циферки, конечно же, относительные (процент фрагментов на общее число инодов), и согласно правилам проведения эксперимента далеко не отражают действительность (уж извините, но на каждый вид действия минимум по 3 серии с различными условиями я не выдержал бы :-P ).

Это то, что касается упреждения дефрагментации при заполнении раздела. Теперь, как бороться, если уже есть файлы, а фрагментация приличная.

В сети находится множество отзывов и статей по теме. Большинство говорят, что дефрагментация не нужна, т.к. система записи на диск "интеллектуальная", в отличии от fat и Ко, которые пихают данные в первые замеченные свободные блоки. Планировщики стараются расположить данные на диск оптимально. Но, допустим, Ваш раздел заполнен маленькими файлами, а Вы решили записать на диск образ DVD. Для этого были выбраны "самые несчастные" и удалены. Но они были расположены по диску с переменной плотностью. В итоге свободного места достаточно для записи, но файл будет в любом случае фрагментирован. Можно не допускать такого поведения, если заранее выделить свободное место на диске (что вообщем-то и делает mke2fs по умолчанию, выделяя свободными 5% раздела для пользователя root).

Встретил даже такое мнение, что некторые unix-администраторы считают полезной фрагментацию для многопользовательских многопоточных процессов. Теоретически с этим можно согласиться, т.к. в один момент процесс 1 читает данные в начале раздела, тут планировщик передает приемущество использования железа процессу 2, а он желает прочитать другой файл. Желательно для быстродействия, чтобы его части этого файла были "размазаны" от начала раздела. Но это очень идеализированный случай, на практике все совсем сложнее: предугадать и разместить части файла под каждую операцию невозможно.

Для моего случая данные будут не слишком фрагментированы (надеюсь :-) ), т.к. они в основном статичны. Ну а если это порты Gentoo неусмотрительно расположенные вместе с ftp для заливки фильмов? Опять же по данным форумов, фрагментация в таком случае может достигать 50% (а то и более). В этом случае поможет tune2fs для освобождения зарезервированных блоков (если вы, конечно, заранее не пожадничили ;-) ), или... дефрагментация. Тут, возможно, кто-то подумает о Windows и множественном выборе программ по теме. Для Ext2/3 под Linux таких программ не много, сам знаю только defrag. Ext3 придется сначала переключить в Ext2. Процесс ни разу сам не проводил, а по отзывам эффект минимальный.

Вы может и не поверите, но самым простым способом для дефрагментации данных является... cp или mv с желаемыми параметрами :-). Аки unix-way: чем проще тем лучше. Для этого, правда, потребуется еще один раздел по размеру не уступающий дефрагментируемому (что весьма трудно добиться для массивов на пару Tb ;)). Он будет временным приемником файлов. В общем-то по примерно такой же схеме работает и дефрагментатор, но он данные сначала переносит в свободные блоки, после чего пытается все упорядочит. В итоге объем работы возрастает. А при использовании копирования всего три крупные операции: копирование на приемник (с учетом схожих по размеру послеловательностей файлов), очистка раздела/форматирование и обратный перенос данных. И этот способ будет иметь эффект для всех файловых систем.

Напоследок хочется сказать, что вместо cp можно использовать вообще tar, не сжимая упаковщиками, тогда все права сохранятся в файле, который можно записывать на фс с не-unix идеологией (e.g., NTFS). Да и действие по автоматизированному отлову больших/маленьких файлов возможно наваять даже на shell.

Links:

• Ext4 в Wiki
• Ext3 defragmentation on linuxquestions.org

P.S. В конце концов решил особо не заморачиваться, да и устал немного :-). Залил все данные, в итоге получилось:

161601 inodes used (0.36%)
4716 non-contiguous inodes (2.9%)
76630040 blocks used (43.14%)
5 large files

Фрагментация выражена не ярко, при том, что в этот раз я активно манипулировал с файлами: копировал, перемещал, удалял.

Ждем Ext4. Из плюшек там заявлено автоматическое упреждение фрагментации.