Пара картинок о фрагментации ФС

Дефраг нужен регулярный

если я не ошибаюсь, то дефолтная убунтушная проверка диска (которая сама вылазит при буте раз в месяц или раз в 30 монтирований) именно этим и занимается

e2fspogs, ёпрст.

В терминах количества seek-ов, дополнительные (по сравнению с дефрагментацией только файлов) оптимизации почти ничего не дадут.

Пара картинок о фрагментации ФС (комментарий)

5-й абзац

Было бы интересно посмотреть оценки длительности seek в зависимости от расстояния. Подозреваю, что зависимость там будет отнюдь не линейная.

Почти линейная.

Это задача планировщика io.

Который на многопоточном рэндомном чтении практически бесполезен.

Для ext4 есть e4defrag начиная с версии утилит 1.42

Рискнуть, что ли…

mv уже ни к чему.

А свободное пространство консолидируется?

если я не ошибаюсь, то дефолтная убунтушная проверка диска (которая сама вылазит при буте раз в месяц или раз в 30 монтирований) именно этим и занимается

Нет. Только проверка.

Это не говорит ни о чем. То, что фрагментация будет тормозить однопоточный процесс последовательного чтения, суть факт, таковы законы природы и физического устройства НЖМД. Тем более, проседание менее, чем в два раза, а мне рассказывали ужасы о копировании сильнофрагментированого диска на NTFS4 со скоростью 50кбс. «Современным файловым системам не нужна фрагментация» понимать надо так - с одной стороны, фс достаточно умны, чтобы в меру своих сил уменьшать фрагментацию (и картинки, кстати, это вполне подтверждают), с другой стороны, в современных многозадачных системах диск нужен всем и сразу, так что полноценного однопоточного чтения с него организовать все равно толком не получится, так что некоторая фрагментация заметна не будет - не суть важно, что seek вызывет, новый фрагмент или какой амарок, попросившый следующую песню, а заодно и картинку к ней. Портеж - штука специфичная, фрагментации подверженная сильно больше, чем при «обычной» работе. Да и сильно подозреваю, что загрузка системы при тесте была близка к нулевой, безо всяких торрентов с сотенкой активных соединений.

Почти линейная.

Порылся в поисках графиков. Всё, что нашлось: http://www.ece.unm.edu/~jimp/611/slides/chap6_5.html (там единственная картинка)

Получается, что seek на пол-диска (distance 1250) занимает ~13 мс, а seek на весь диск (distance 2500) занимает ~17 мс. Разница примерно 30%, в нулевом приближении можно за нее и не бороться.

Да и сильно подозреваю, что загрузка системы при тесте была близка к нулевой

А это нормальная работа обычного десктопа.

безо всяких торрентов с сотенкой активных соединений

Если торренты раздают плотным потоком, то ни о какой отзывчивости системы ни в каких условиях речи уже нет.

А если их урезать, то тогда фрагментация того же /usr становится весьма заметной (я измерял по скорости работы ldconfig, но цифр нет под рукой — там разница между новой и старой ФС даже не вдвое, а раз в 5-10 была, ЕМНИП).

три гига мало (один запущенный браузер с закладками отест до гига), надо больше по нынешним временам...

скорее всего уже на 4х станет легче, ну а 8 вообще позволит забыть о проблеме фрагментации на xfs (хотя запускать на ней дефрагментатор как раз просто и необременительно)

Если торренты раздают плотным потоком, то ни о какой отзывчивости системы ни в каких условиях речи уже нет.

Где ж такую систему взять? Разве что одноядерным процом 100мбит/с аплинк забивать. Но это, мсье, некрофилия и мазохизм.

Этого не знаю.

Получается, что seek на пол-диска (distance 1250) занимает ~13 мс, а seek на весь диск (distance 2500) занимает ~17 мс

Как-то мало. Обычно было больше. Хотя тестов сторонних под рукой нет, а самому измерить нечем.

Разница примерно 30%

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

…

В общем, цифры для фрагментированного и дефрагментированного портежа я приводил. Цифры ldconfig по своей памяти — тоже.

…

Впрочем, не люблю быть неточным. Нашёл тесты с ldconfig. Там у меня был старый не ext4, а reiser4.

19,5 … 26,8 сек. для старой системы
9,10 … 12,7 сек. для дефрагнутой мувом
// http://balancer.ru/tech/forum/2009/05/t64670--ocherednoj-bench-proizvoditelno...

Не в 5…10 раз, как я говорил, ошибся (это, значит, где-то ещё было), но в те же два раза.

Кроме того, вместо теоретического ldconfig там есть и вполне практические цифры уменьшения времени запуска приложений. Запуск того же Firefox сокращается с 8,3…12,5 до 6,5…9,7сек.

три гига мало (один запущенный браузер с закладками отест до гига)

А у меня обычно браузер на этой машине и не запущен :) Да и не ест больше 400..600 Мб RSS.

скорее всего уже на 4х станет легче, ну а 8 вообще позволит забыть о проблеме фрагментации на xfs

На машине с 16Гб под ext4 вопрос фрагментации точно такой же как и на машине с 2Гб :) Про xfs тут не скажу, конечно. Но на самом деле пофиг, когда есть xfs_fsr. Собственно, тест состоялся потому что я когда последний раз, с пол-года назад ковырялся с разделам, отрубил ежедневный фоновый дефраг. Сейчас прогнал один проход, фрагментация упала до actual 9122, ideal 6665, fragmentation factor 26,93%. Сейчас ещё разок прогоню и построю карту после дефрага (это в downloads)

KRoN73

balancer@home-gentoo ~ $ sudo e4defrag
sudo: e4defrag: command not found

fail

[ root@desktop ] megabaks # equery b e4defrag 
 * Searching for e4defrag ... 
sys-fs/e2fsprogs-1.42 (/usr/sbin/e4defrag)
[ root@desktop ] megabaks #

Где ж такую систему взять? Разве что одноядерным процом 100мбит/с аплинк забивать

Не знаю. Я, когда открываю на отдачу свой канал 20Мбит без ограничений, машина очень вялая становится. Экспериментально подобрал, что заметное на глаз снижение отзывчивости начинается с 400кбайт/с. Так что держу раздачи, вообще, до 200кбайт/с зажатыми :) И то за 350Гб исходящего случается в месяц :) — Какое количество трафика вы потребляете, сидя в сети, ежемесячно? (комментарий)

Разве что одноядерным процом

Ну, вообще, таки да, домашняя файлопомойка у меня на P4-3000 в HT.

Для вброса не хватает ZFS и NTFS.

Ну да, ты же у нас рискуешь файловые системы мучить тестируемыми версиями пакетов :) А я лучше подожду, пока такие как ты все шишки соберут :)

Для вброса не хватает ZFS и NTFS.

NTFS я могу показать (на другую машину придётся идти), но это не интересно. Там почти всё синенькое будет и в начале раздела. Там Perfect Disk практикуется :)

просто я не некрофил - обсуждали же
и это тестируемый пакет только в твоих фантазиях
обычный релиз - не замаскирован, не альфа, не бета

кстати про шишки - в багтрекере генты ни одного упоминания этой версии
зато предыдущей...
а пакет этот уже давно в дереве

и это тестируемый пакет только в твоих фантазиях

Так почему он до сих пор не в arch?

В любом случае зуб даю, что консолидацией свободного пространства он не занимается, так что практическая польза от него невысока.

кстати про шишки - в багтрекере генты ни одного упоминания этой версии

Там, разве, встречается более-менее часто что-то кроме проблем сборки? :)

Многие даже за 30% прирост быстродействия удавиться готовы

Кмк, на фоне эффекта от простой дефрагментации файлов, эта разница будет незаметна.

KRoN73

консолидацией свободного пространства он не занимается

возможно
у меня нет ext*

KRoN73

Так почему он до сих пор не в arch?

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

Кмк, на фоне эффекта от простой дефрагментации файлов, эта разница будет незаметна.

В том-то и дело, что основная масса файлов на современных FS при нормальном использовании итак нефрагментирована или фрагментирована мало. Те, что фрагментированы, в массе своей используются одновременно не так часто и хорошо кешируются. Так что и эффект от дефрагментации большим не будет.

А вот эффект от консолидации бывает очень заметным. Хотя бы потому, что этим явлением современные ФС вообще не заморачиваются :) И потому там получается каша.

KRoN73

Там, разве, встречается более-менее часто что-то кроме проблем сборки? :)

частенько

у меня нет ext*

И зачем тогда тебе sys-fs/e2fsprogs-1.42 (/usr/sbin/e4defrag)? :D

тебе напомнить про ментайнеров-слоупоков?

А куда спешить? :) Итак Gentoo в СГ катится, ты хочешь, чтобы оно туда катилось ещё быстрее?

Сейчас прогнал один проход, фрагментация упала до actual 9122, ideal 6665, fragmentation factor 26,93%. Сейчас ещё разок прогоню

После второго прохода стало actual 7193, ideal 6664, fragmentation factor 7,35% (напомню, что было 95,41%).

Теперь карта downloads такая:

http://balancer.ru/img/forums/1201/xfs-downloads-defragged.png

…

Ладно, фиг с вами, попробую e2fsprogs 1.42 поставить :)

основная масса файлов на современных FS при нормальном использовании итак нефрагментирована или фрагментирована мало.

А почему тогда тут весь диск розового цвета? :) http://balancer.ru/img/forums/1201/ext4-var-frag.png

[оффтоп]Я правильно понимаю, что ты - владелец balancer.ru?[/оффтоп]

Потому что это /var, это не «нормальное использование» :D

ты - владелец balancer.ru?

Угумс.

оно туда и катится из-за того, что ментайнеры слоупоки
и речь не столько о версиях, сколько о скорости реакции поддерживающего на появишийся баг/фикс в/для его пакет(е/а)
+ положили хер на пользователей
всё что дают юзы просто отправили к праотцам - я о гтк2/3
с каких они решили, что все хотят использовать только гтк3?
ради пользователей гнома2 недавно замаскировали несколько версий блоба нвидии - в гноме был какой-то косяк с теми версиями
и спустя пару месяцев запиливают gnome-mplayer, audacious и т.д. с...гтк3!
хде логика?
смотрим ветки - audacious-3.1 стабильная
gnome-panel (просто часть гнома2) - стабильная
но первое требует гтк3, а второе гтк2
и как это будет выглядеть?
это же феерия
о чём они думают - я хз
хотя и audacious и гном-мплеер могут быть собраны как с гтк3, так и с гтк2 (что собственно овер юзы в своём оверлее и сделал)
их много народа просило о выборе гтк2/гтк3 - «нам похер на вас - гтк3 апстрим! нет тем? а нас это не***!»
вот и сказке конец

Потому что это /var, это не «нормальное использование» :D

А ведь на части машин var на том же разделе, что и все остальные директории :)

Но даже если var живет отдельно, тут тоже половина диска розовая - http://balancer.ru/img/forums/1201/ext4-home-frag.png

И что эта страничка - http://sovsklad.balancer.ru/ - тоже твоя?

Хостится у меня. А так — случайный человек, но мне для такой темы не жалко. Точнее, на хостинге balancer.ru только страница, торренты — со стороны.

эти уроды просто положили хер на саму идею дистра - гибкость

Но даже если var живет отдельно, тут тоже половина диска розовая

Ладно, уговорил, эффект от дефрагментации, всё же, будет заметным. Как и от консолидации ;)

Угумс.

А эта штука - http://sovsklad.balancer.ru/ - тоже твоя? Мне бы разжиться OCR-енными школьными учебниками по географии/биологии/химии/физике etc. Сколько ни гуглил, ничего толкового найти не могу. Может, попадалось?

случайный человек

Ок, ясно, спасибо

оно туда и катится из-за того, что ментайнеры слоупоки

Это, как раз, мне пофиг. А вот то, что _надёжность_ дистрибутива падает — вот это меня бесит. То, что слоупоки — фиг с ним. Важный мне ебилд, пакета, который хочу свежей версии использовать, я могу и с багзиллы взять. Или сам написать. Но всё остальное в системе должно быть стабильно и безглючно. Я Gentoo именно за это в первую очередь любил (ну и за гибкость). А всякие оптимизации и свежие версии глубинного системного софта — это дело для меня десятое.

ты сам себе противоречишь
перечитай мой пост выше ещё раз - до гтк*

Может, попадалось?

Ну, свяжись с автором сайта, «слать сюда: cccp-skladБОЛЬШАЯЗЛАЯСОБАКАyandex.ru» — у него и Jabber есть. Может, что-то есть невыложенное. Тем более, у него условий для торрент-раздач нет, он через мою домашнюю машину это делает, а у меня, как я сейчас увидел, с 5-го числа его rtorrent лежал. (поднял)

перечитай мой пост выше ещё раз - до гтк*

Просто всё описанное тобой меня пока не задевает. И Gnome2 (2.32.1-r1), и nvidia (290.10) работают отлично :)

Собственно, проблема сейчас (и уже давно) одна, и с версиями софта она не связана — это то, что в initrd сегфолтится busybox lvm. Из-за чего уже давно ядро обновить не могу, сижу до сих пор на 2.6.38.5-zen. Дважды мир пересобирал — пофиг. Началось всё после одного из обновлений prelink, тогда на forums.gentoo.org много было на него ругани. Ошибки прямо при работе emerge сыпались. Но у народа всё лечилось его откатом, у меня же при откате и пересборке мира проблемы в системе прошли, а вот ядро так и глючит.

Других проблем сейчас нет :) Иногда вылезает что-то с зависимостями или блокировками, но решается за минуту. Хотя и раздражает.

тудыть тя растудыть!!!
ты ничего, кроме версий не заметил?
перечитывай ещё раз
хотя...
по-твоему нормально, когда пакет в стабильной ветке не может быть собран в течении 3-х недель при наличии фикса в багзилле?
это как раз твоя стабильность/надёжность и т.д.

xfs, downloads для торрентов

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

$ du -h *
4.3G DAOSE_DVD1.iso
4.2G DAOSE_DVD2.iso
$ sudo filefrag *
DAOSE_DVD1.iso: 1 extent found
DAOSE_DVD2.iso: 1 extent found

И на всякий случай информирую, что для xfs есть специальная тулза для дефрагментации: xfs_fsr

Тебе тоже нужно меня перечитать. Я, как раз, и ругаюсь, что Gentoo катится в СГ из-за того, что в стабильной ветке всё чаще встречаются глюки.

Поставь нормальный клиент

Кроме rtorrent других нормальных не знаю :)

И на всякий случай информирую, что для xfs есть специальная тулза для дефрагментации: xfs_fsr

Сделай по треду пробег поиском по «xfs_fsr».

глюки из-за тормознутости поддерживающих там и появляются
а уж если тормозуха протекла и тормоза не работают, то тут такое начинается...
просто основные ментайнеры сами давно катятся по наклонной
а на всю критику кладут болт
да ещё и их подпевал хватает - на том же gentoo.ru таких несколько человек есть
всё просто - «деградация - это так модно!»

Итак, для начала статистика по /var:

# ionice -c3 e4defrag -c /var
<Fragmented files>                             now/best       size/ext
1. /var/log/munin/munin-html.log                15/1              4 KB
2. /var/log/squid/access.log.7                  15/1              4 KB
3. /var/log/kernel/log-2012-01-14-00:03:18
                                                15/1              4 KB
4. /var/log/samba3/log.192.168.1.16.old         13/1              4 KB
5. /var/log/samba3/log.192.168.1.122.old        13/1              4 KB

 Total/best extents				635466/539583
 Average size per extent			34 KB
 Fragmentation score				14
 [0-30 no problem: 31-55 a little bit fragmented: 56- needs defrag]
 This directory (/var) does not need defragmentation.
 Done.

Это для http://balancer.ru/img/forums/1201/ext4-var-frag.png :) «does not need defragmentation», ага…

Кстати, продолжая тему на главной, про зетта-наводнение:
http://www.rg.ru/2011/10/11/tech.html

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

в свете последних тенденций про рост объема данных и децентрализацию

его хранения, похоже

Ну, для этого для начала нужно будет обеспечить хотя бы честный гигабит в каждый дом. Да и то мало будет :)