А я и указывал, что речь идет о десктопах и что в топике обсуждение не концентрируется только на серверах.

А приведенные  ранее цитаты специалистов показывают только одно - что они сами толком не знают насколько увеличивает реальную произ-ть файловой системы дефрагментация, поэтому отмазываются общими фразами

Здесь автор высказывания склоняется к тому, что польза есть.

Здесь чисто общая фраза и польза не отрицается.


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

Мои главные аргументы, мое ИМХО ( Имею Мнение Хрен Оспоришь )) ) это:
1) На забитом данными винте фрагментация файлов и свободного места между файлами в любом случае присутсвует.
2) Влияние фрагментированности файлов на НЖМД, на котором есть достаточно свободного места мала, ввиду современных алгоритмов выделения места под файл, препятствующих сильной фрагментации фрагментов файлов(алгоритм пытается выделить под файл непрерывную цепочку кластеров).
3) Из-за фрагментации свободного места на диске все данные распоожены неоптимально, некомпактно и смещены в сторону внешних дорожек, на которых линейная скорость существуенно ниже, чем на внутренних.
4) Чем ближе расположены данные к началу диска, тем выше скорость их считывания (график считывания "ступенька"), чем более часто используются эти данные, тем выше выигрыш в скорости.
5) Чем более близко расположены наиболее часто используемые данные, тем выше скорость обращений к ним, т.к. накладные расходы на перепозиционирование головок считывания/записи минимальны.

Если посмотреть на работу нормальных дефрагментаторов(например виндовый от Symantec) то они строго следуют приведенным выше пунктам, а не просто тупо собирают воедино(дефрагментируют) файлы при дефрагментации: неизменяемые/малоизменяемые файлы и данные, которые часто используются расположены в начале диска, затем идут прочие данные, далее располагаются временные и часто изменяемые файлы(с хвостами в виде свободных блоков - "на вырост"), редко используемые данные расположены к конце диска, т.к. скорость их считывания мало кого волнует, при этом они освобождают место на скоростных начальных дорожках под данные, скорость считывания которых действительно важна.

есть драйвера под винду, для ext2.3

Дефрагментатор для ext2/ext3 не нужен :\. Это тебе не винда. А винт меняй по гарантии быстрее, если она еще осталась

Если бы это было совсем бесполезно, то никто не стал утруждать себя писать подобного рода программу:

$ apt-cache show defrag|tail
MD5sum: dd930bf69722c5b75e9762dcb457bf7b
Description: ext2, minix and xiafs filesystem defragmenter
As a file system is used, data tends to become more and more
scattered across the disk, degrading performance.  A disk
defragmenter simply re-organises the data on the disk, so that
individual files occupy a single sequential set of disk blocks,
and all the free space on the disk is collected together in a
single region. This generally means that reading a whole file
is faster, and disk accesses in general are more efficient.

Да, скорее всего, но на десктопе не всегда имеет смысл делать такую разбивку, чтобы не оказаться в ситуации, когда в /usr свободного места будет 1 мегабайт, в то время как в /home останется 10 гигов, в /var/ гигабайт и т.д - чтобы заниматься фигнея, плодя симлинки после раскидывания части директориий из /usr по другим разделам.  В этом случае имеет смысл бить винта на два раздела / и /boot, естественно ситуация с фрагментацией получается другой, нежели с /var, /usr, /home, ....

Имелось ввиду на своем десктопе, тут загаживать диск некому кроме себя, да и квоты есть, чтобы вредителей пришпорить.  Если же переполнение и возникнет каким-то образом, например по причине логов, то большой разницы не будет - разгребать /var/ в /var/ или /var/ в /.

В чем заключается опасность на своем лично десктопе?
Поясню для чего все разделы скинуты у меня в /  - чтобы максимально использовать все доступное дисковое пространство и не встать перед фактом что один из разделов забит в то время как на остальных полно места, чтобы не пришлось переразмечать и извращаться с симлинками.  
На моем корневом  разделе все-в-одном из-за приличной сборки(решил поглядеть на скорость оптимизированного OOo ) достпно сейчас 500 метров, если бы точки монтирования были бы физически разнесены по разделам диска, то места бы не хватило и сборка бы уже давно вывалилась.

У вас никогда не переполнялся / ? Вам повезло.


Дык если грамотно все планировать то не будет никаких проблем с нехваткой места.


Ну да это уже изврат.


Ну это скорее исключение чем правило Хотя у Гентушников возможно и постоянно  


Вообще такие вещи лечатся покупкой более жирного hdd У меня например не меньше 10 Gb в /usr /var и не меньше 50 Gb в /home и меньше очень редко бывает.


Затем что бы обезопасить / от переполнения, а то переполнение того же /tmp может вызвать критический сбой в системе.


Лучше lvm по крайней мере проблема с местом отпадает


Если она и имеет место быть то только на десктопе ибо на серваке с его постоянной динамикой обращения к дискам она не нужна.

Да вроде еще такого не было, /var и /tmp на других системах с порезанными по-правильному разделами забивались, демоны да программы только ругались, но ничего страшного с самой  системой не происходило, недостаток места в каком либо из разделов эквивалентен разделу в ro, но в таком режиме система работает, система продолжает работать, поругиваясь, даже после аппаратной поломки единственного винта...

В gentoo /boot вообще в noauto  А /usr в ro это круто(обновления потребуют постоянного перемонтирования), особенно на десктопе.
Это очень странно, причины потери данных от переполнения неочевидны: ну никак не могут данные одного раздела заехать на другой или логи при невозможности записи начать писаться поверх других файлов, естественно на нормальном железе при корректной таблице разделов, т.к. при останове кулера на проце, битой памяти или выходе из строя мамки файловая может превратиться в кашу.