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

В принципе для Ext3 не особо это влияет на скорость. Но проги вроде есть - e2defrag, shake (вроде так назывались)
Для нтфс, думаю, надо, но хз насчет того, есть под линух или нет.

Собственно, Крис Касперски как-то возникал по поводу отсутствия дефрагментации в линуксе - якобы это великая проблема. Впрочем, имхо, ext3 не имеет таких проблем.

Для ext3 это не проблема, в принципе. Она и так не быстрая, и от растущей фрагментации сильнее не тормозит (примерно, как и ntfs). ЕМНИП, это происходит благодаря особенностям протокола ATA. Если же всё же хочется ФС с дефрагментатором, то xfs - твой выбор :)

Скачивай с git самую свежую версию e2fsprogs/utils там был e4defrag
http://opentorrent.ru/viewtopic.php?t=113925

На etx3 небольшая фрагментация есть, но она практически никогда не достигает такой степени, чтобы влиять на скорость. На ext4 она вообще почти отсутствует.

для ext4 есть, очень сильно не фрагменитруеться, но если есть возможность уменьшить кол-во фрагментов, но грех не воспользоваться. вот до

e4defrag -c ./tmp/
<Fragmented files> now/best ratio
1. /amule/tmp/018.part 7/1 0.11%
2. /amule/tmp/005.part 41/1 0.09%
3. /amule/tmp/021.part 10/1 0.09%
4. /amule/tmp/014.part 20/1 0.09%
5. /amule/tmp/001.part 23/1 0.08%

Total/best extents 959/61
Fragmentation ratio 0.06%
Fragmentation score 0.47
[0-30 no problem: 31-55 a little bit fragmented: 55- needs defrag]
This directory(./tmp/) does not need defragmentation.
Done.

....
[13/62]/amule/tmp/010.part: 100% extents: 106 -> 50 [ OK ]
[14/62]/amule/tmp/014.part.met.bak: 100% extents: 1 -> 1 [ OK ]
[15/62]/amule/tmp/004.part.met: 100% extents: 1 -> 1 [ OK ]
[16/62]/amule/tmp/020.part: 100% extents: 38 -> 28 [ OK ]
[17/62]/amule/tmp/019.part.met: 100% extents: 1 -> 1 [ OK ]
[18/62]/amule/tmp/004.part.met.bak: 100% extents: 1 -> 1 [ OK ]
[19/62/amule/tmp/006.part.met.bak: 100% extents: 1 -> 1 [ OK ]
[20/62]/amule/tmp/021.part: 100% extents: 10 -> 10 [ OK ]
[21/62]/amule/tmp/012.part.met: 100% extents: 1 -> 1 [ OK ]
[22/62]/amule/tmp/007.part: 100% extents: 103 -> 76 [ OK ]
[23/62]/amule/tmp/012.part: 100% extents: 32 -> 24 [ OK ]
.....

и результат

e4defrag -c ./tmp/
<Fragmented files> now/best ratio
1. /amule/tmp/021.part 10/1 0.09%
2. /amule/tmp/001.part 23/1 0.08%
3. /amule/tmp/018.part 5/1 0.08%
4. /amule/tmp/005.part 32/1 0.07%
5. /amule/tmp/017.part 24/1 0.07%

Total/best extents 663/61
Fragmentation ratio 0.04%
Fragmentation score 0.31
[0-30 no problem: 31-55 a little bit fragmented: 55- needs defrag]
This directory(./tmp/) does not need defragmentation.
Done.

А у reiserfs есть такая проблема?

use btrfs/xfs, Luke!

> use btrfs
Подождём пока хотя бы дисковый формат стабилизируется.

fsck

и забей

> В принципе для Ext3 не особо это влияет на скорость.

ну-ну. Скачай какой-нибудь популярный торрент на пяток гигабайт и потом попробуй его куда-нибудь скопировать. Когда диск остынет — попробуй ещё раз, почувствуй разницу.

Почти во всех торрент-качалках есть типа такой опции - «Резервировать место под торрент». Попробуй :)

Дисковый формат стабилен уже наверное год как.
Последний раз когда разработчики его меняли - они сделали тулзу, которая конвертировала фс из старого формата в новый.
А ещё они обещали больше не менять формат, только если обнаружены будут критические баги.

Только она всё равно медленней чем ext4.

Фактически, на повседневную работу фрагментация практически не влияет - одной программе нужен один файл, второй - совсем другой, так что головка и так по диску мотается. Она влияет (и сильно) на массивное последовательное чтение, например копирование. Плюс, у ext3/4 дизайн для уменьшения фрагментации.

Вы все еще не резервируете место под торренты?

да я не жалуюсь, это мой сознательный выбор

Мой пост был к тому что фрагментация в Linux существует, и хороший способ себе её заработать — скачать таким образом торрентов. И если есть костыль для торрентов не значит что в других ситуациях этой фрагментации нет, может не столь явно выраженной.

Почти во всех торрент-качалках есть типа такой опции - «Резервировать место под торрент». Попробуй :)

Это должно повлиять также и на базы данных? Такие, которые из кучи табличек, в которые постоянно и непредсказуемо дописываются кусочки, мелкие, но много? Не нравятся примеры, придумай другие, проблема-то растёт из другого места, капиш?

Специального софта нет!

Есть сш-скрипт разработанный умельцами - выложил здесь http://rghost.ru/1335805

Хотя для Линукса проблема фрагментации файлов не принципиальна

К предыдущему

Вот еще скрипт который покажет насколько дефрагментирован раздел http://rghost.ru/1335825

>Такие, которые из кучи табличек, в которые постоянно и непредсказуемо дописываются кусочки, мелкие, но много?

В таких случаях дефрагментация _вообще_ на скорость не влияет.

> А у reiserfs есть такая проблема?

В принципе есть, но очень незначительно, обычно фрагментация не более 5-10%, при длительном использовании раздела, поэтому не существенна и глазу не заметна.

Для Ext2 и Ext3 явление такое имеется, но проблем не создаёт. Более того - особенностью работы с файлами в GNU/Linux (в отличие от Windows) является то, что файл можно открывать несколькими программами много раз. То есть существует мнение, что при использовании одного и того же файла несколькими программами при фрагментированности файла возрастает производительность. Однако степень дефрагментации для линуксовых файловых систем мала, и поэтому ощутимые потери производительности отсутствуют. А вот в ReiserFS это вроде уже проблема.

Кстати программы для дефрагментации были. Вот только они были заброшены из-за полной ненужности - ими вообще никто не пользовался.

Фрагментация на ext3 будет более-менее заметна, если забивать её изменяющимися файлами под завязку.

Фрагментация будет серьезная, если без пререзервирования скачать данные торрента с маленьким размером части. rtorrent по дефолту так и качает на ext3.

В винде была такая штука — дефрагментация

В линуксе проблему решают до того, как она проявится, а не после. Дефрагментацию при необходимости производят командой cp.

Большая фрагментация может возникнуть если места на фс всё время мало.
Но я, честно говоря, фрагментацией на ext3/4 никогда не страдал - сколько смотрел не более пары процетов выводило.

А с ext4 вообще хорошо - там экстенты, delayed allocation и прочие вкусности которые уменьшают фрагментацию.

В e2fsprogs из гита есть тузла e4defrag для ext4

> Фрагментация будет серьезная, если без пререзервирования скачать данные торрента с маленьким размером части. rtorrent по дефолту так и качает на ext3.

Ну у меня с ext3 и rtorrent`ом со sparse файлами проблем небыло.

Ну попытайся после этого внезапно прочесть всю БД подряд. Или пост прочитай целиком: это просто примеры, фрагментация существует независимо от них.

>Специального софта нет!
Дануу. e4defrag?
Читать надо всё-таки иногда тред

То, что в ext* фрагментации нет - чушь, файлы каталогов фрагментируются и довольно сильно, решения как такового нет (кроме copy/format/copy), обычные файлы можно попробовать тягать туда-сюда скриптами.
фанатам fsck - http://sf.net/projects/davl

В линуксе проблему решают до того, как она проявится, а не после. Дефрагментацию при необходимости производят командой cp.

Не решают, а уменьшают вероятность возникновения и последствия для производительности. Не именно в Линуксе, а на разных платформах в более современных файловых системах.

Копирование - настоящий костыль, решение непрозрачное и в использовании более сложное, чем онлайновая дефрагментация.

вот уже двое не умеющих читать тред отметилось. e4defrag - эот не решение что ли?

>>Есть ли на ___ext3____ такая проблема?

e4defrag - эот не решение что ли?

вот уже двое не умеющих читать тред отметилось.

Ну ты первый - это поятно, а кто второй?

>e4defrag - эот не решение что ли?

Нет. Выше по треду писали же, что оно непонятно что делает и повторный запуск уменьшает число фрагментов. Это не дефрагментатор, это обертка для cp какая-то. Вот xfs_fsr — совсем другое дело.

>То, что в ext* фрагментации нет - чушь

решения как такового нет

исходим из своего поста, любезный.

>исходим из своего поста, любезный.

диагноз там для всех ext* описан, а решение - именно под сабж (ext3) о чем и спрашивалось. а вот твой e4defrag тут вообще боком

Пора собирать сборник мифов, популярных среди линуксоидов :)

реально достаточно редко приходится видеть что ext2-3 , а особенно ext4
фрагментируется достаточно сильно, обычно фрагментация не превышает 20%
Исключения - файлообмен, там файлы достаточно большие и записать их одним куском достаточно сложно, но даже в таком случае куски по возможности остаются достаточно большими чтобы сильно не снижать производительность ФС.

только что 2 диска с проверки (ext3):

3321 non-contiguous files (12.5%)
752 non-contiguous files (0.9%)

> Нет. Выше по треду писали же, что оно непонятно что делает
Так и пиши что _тебе_ не понятно.

и повторный запуск уменьшает число фрагментов.

дефрагментатор ещё сырой, не стоит ожидать от него безупречной работы

Это не дефрагментатор, это обертка для cp какая-то.

Бред.
Вот shake - это обёртка для cp, да.

>3321 non-contiguous files (12.5%)

752 non-contiguous files (0.9%)

Это % фрагментированных файлов от общего количества, а не фрагментации в целом (число_фрагментов/число_файлов грубо), т.е. если будет скажем один из 100 файлов разбит на миллион фрагментов, то fsck покажет 1 non-contiguous files (1.0%), вообщем всем вменяемым нужно смотреть на davl, а не fsck