e4defrag идет в народ

Welcome to Future! (c)

И вот в 2011 году мы таки сделали дефрагментатор.

А оно зачем-то нужно? Не знаю, как в ext4, но в ext3, вроде, пока есть свободное место особо и нечего бояться

Видимо от хорошей жизни приобрела популярность «дефрагментация через mv».

Кстати, тоже вариант)

Я просто считал, что это когда мало места на диске остается

>Я просто считал, что это когда мало места на диске остается

Проблема не [с]только во фрагментации файлов, с ней более-менее успешно борются (ну, кроме всяких многопоточных php), проблема во фрагментации свободного пространства. Интересно, борется ли с ней e4defrag?

С наступающим 2011 годом!

По ссылке не вижу никакого сдвига.

Проблема не [с]только во фрагментации файлов, с ней более-менее успешно борются (ну, кроме всяких многопоточных php), проблема во фрагментации свободного пространства.

Это как? От самой по себе фрагментации пустого пространства ни тепло ни холодно, главное что это влечёт за собой фрагментацию файлов. С учётом этого твоё утверждение выглядит непонятно.

прогресс, я для OBS его еще весной собрал

Напоминаю про чистилку гномовского реестра: http://code.google.com/p/gconf-cleaner/

;)

Глядишь - и венду догоним в этом :)

Антивирус есть, твикер вроде был, чистилка реестра есть, дефрагментатор есть. Что ещё нужно?

>От самой по себе фрагментации пустого пространства ни тепло ни холодно

Холодно. Или жарко. Смотря с какой стороны оценивать. Размазывание файлов по поверхности диска сильно увеличивает время рэндомного доступа к произвольным данным.

Ты запускаешь софтину, а винт, вместо нескольких цилиндров, в рамки которых влезают десяток гигов /usr/lib, начинает скакать по всей поверхности.

«Дефраг мувом» заметно помогает, даже когда фрагментация файлов очень низкая :)

>> Ты запускаешь софтину, а винт, вместо нескольких цилиндров, в рамки которых влезают десяток гигов /usr/lib, начинает скакать по всей поверхности.

NCQ или софтовые планировщики должны это сглаживать, разве нет?

>NCQ или софтовые планировщики должны это сглаживать, разве нет?

Я ещё ни разу не видел какого-либо заметного эффекта от включения NCQ :)

трояны и вирусы?

Откровенно говоря, я тоже. Ядро загружается с elevator=noop для того, чтобы другие планировщики не «спорили» с NCQ, хотя разницы в скорости не замечал, в общем-то. Но у меня и фрагментации практически не бывает, так что делать выводы не из чего.

Ты запускаешь софтину, а винт, вместо нескольких цилиндров, в рамки которых влезают десяток гигов /usr/lib, начинает скакать по всей поверхности.

что именно искать? свободное место?

>Я ещё ни разу не видел какого-либо заметного эффекта от включения NCQ :)

И не увидишь, продолжая пользоваться CFQ

>e4defrag идет в народ
а зочем это непоймичто на reiserfs?
думаю оно не нужно

>Я ещё ни разу не видел какого-либо заметного эффекта от включения NCQ
вообще то надо отключать ещё и cfq, deadline, anticipatory и иже с ними...

>И не увидишь, продолжая пользоваться CFQ

Прикинь, у меня noop на винтах с NCQ и bfq на винтах без NCQ. Удивительно, правда? :)

>что именно искать?

Файлы.

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

>скакать она будет не потому что ищет а потому что файлы разорваны на кусочки

Мы выше обсуждаем вопрос именно при малой фрагментации файла.

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

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

xx-2009 год - для linux fs дефрагментатор не нужен (xfs не в счет)

2010 год - «e4defrag идет в народ »

Тут уже одному с очень интересным диагнозом тему с подобными рассуждениями удалили :)

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

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

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

Тогда малая фрагментация будет побарабану.

> ну, кроме всяких многопоточных php

можно, пожалуйста, подробнее как связь у многопоточного php и фрагментацией?

Читать «p2p» ;)

Под потоками имеются в виду не треды/форки/процессы, а потоки закачки :)

>так это уже не фрагментация

Я же чётко сказал - «фрагментация свободного пространства». Устоявшийся и корректный термин. Хорошие дефраги под офтопик имеют бороться с этим явлением, начиная с самого Norton Speedisk :)

Тогда малая фрагментация будет побарабану

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