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

<child-troll>
Ух ты, картинки. С разноцветными квадратиками...
Это для вышивания крестиком?
Или игра какая-то?
</child-troll>

Ну объяснил бы. Сформулировал бы выводы, а то так не совсем понятно...

Stahl (16.01.2012 18:43:50)

Пора переходить на SSD. Там, емнип, скорость чтения в куда меньшей степени зависит от порядка блоков.

Sadler (16.01.2012 18:45:37)

Ну, очевидно, вроде. Синий квадратик — блок без фрагментированных файлов, красный — с оными. Белый — свободное пространство.

Дефраг нужен регулярный. Вот и весь вывод :) А те, кто говорит, что современные ФС не фрагментируются — заблуждаются :D

KRoN73 (16.01.2012 18:48:42)

Угу. Хотя тоже зависит, в общем. И сильно зависит скорость записи. Если только контроллер не умный и сам в фоновом режиме не оптимизирует размещение и не стирает ненужное.

KRoN73 (16.01.2012 18:49:35)

Современные ФС дают команду discard.

Relan (16.01.2012 18:51:52)

Но /var держать на SSD всё равно стрёмно :) Да и в /home очень уж много постоянных модификаций.

KRoN73 (16.01.2012 18:53:31)

>А те, кто говорит, что ext4 является современной ФС — заблуждаются :D

Починил.

spoilt (16.01.2012 18:56:10)

А что современное? NTFS? btrfs? zfs? :)

KRoN73 (16.01.2012 18:57:35)

/var как раз не стремно. Ну посыпется, ну и хрен с ним. А вот /home жалко.

Я это к тому, что при наличии контроллера SATA 3Gb/s, SSD с поддержкой оного и современной ФС, скорость записи падает не так уж сильно по мере заполнения диска.

Да и вообще, не так уж много записей на домашней-то системе. Чтений в любом случае гораздо больше.

Relan (16.01.2012 19:03:56)

Reiserfs. Даже третий.

spoilt (16.01.2012 19:06:12)

Стрёмно. С дешёвого SSD толку мало, а дорогой если посыплется — жалко :)

Ну, в целом да.

Чтений больше, но время жизни SSD определяется не отношением числа чтений к записи, а абсолютным числом записей. И вот тут всё не шоколадно. Взять тот же kde, который в .xsession-error постоянно срёт тоннами. Да и просто в kde/gnome каждый чих в конфигах пишется постоянно. Опять же, кеши браузеров и т.п.

KRoN73 (16.01.2012 19:07:48)

А теперь ещё продемонстрируй зависимость скорости чтения/записи от фрагментации в этих ФС. И потвикать бубунту не забудь, ага.

Lighting (16.01.2012 19:08:21)

Там фрагментация была такого же уровня. Сколько лет я на нём просидел, знаю уж особенности :)

KRoN73 (16.01.2012 19:08:37)

Вот смотрю я на эти картинки и думаю: а нафига раздел на 90-90% забивать? Чтобы аллокатору было над чем подумать? Не забивай раздел до отказа, не будет фрагментация бешено расти.

unanimous (16.01.2012 19:11:07)

Приводил когда-то. ext4 на портеже возрастом в несколько месяцев — emerge -pe world занимал около 6 минут. После дефрага мувом — чуть более 3 минут (191 сек).

Это на Gentoo было.

KRoN73 (16.01.2012 19:13:09)

/home забит на 61%, свободно 32Гб
/usr забит на 67%, доступно 9,3Гб
downloads забит на 92%, доступно 33Гб.

В каком месте не нравится?

Предлагаешь на downloads держать свободным терабайт места? :)

KRoN73 (16.01.2012 19:15:08)

...а некоторые просто используют SQLite.

Lighting (16.01.2012 19:15:27)

Юзаю jfs - никаких проблем нет.

zloy_buratino (16.01.2012 19:16:39)

А речь не о нём (я, кстати, предпочитаю squashfs+aufs), а о влиянии фрагментации (в том числе свободного пространства) на скорость.

KRoN73 (16.01.2012 19:19:23)

Ну так и у меня на ext4/xfs проблем никаких нет. И?

KRoN73 (16.01.2012 19:19:55)

Вот это не нравится. 60-70 вполне ОК.

Я ничего не предлагаю, просто если раздел забит на 90 это значит "пока покупать новый диск!"

Ну и моя персональная точка зрения: я не знаю, что и зачем нужно качать в таких количествах. Жрете все без разбору и желательно в HD?

unanimous (16.01.2012 19:21:09)

Так если у тебя дерево Portage в RAM, то при чём тут фрагментация?

Lighting (16.01.2012 19:22:34)

Да это я так просто... :)

zloy_buratino (16.01.2012 19:24:41)

Вот на Video у меня 1,5Тб. Занято на 100% (свободно 2,5Гб). Ты предлагаешь, чтобы у меня тупо без дела пропадало 0,5Тб места? :) Да многие живут целиком на таких винтах :D

Смотреть надо и на процент свободного места, и на абсолютный свободный объём. Когда у тебя свободно 50Гб, то пофиг что это 5% раздела.

Опять же, на цель смотреть надо. Ну и что, что каталог с видео забит на 100%. Тебе не пофиг, когда оно оттуда будет читаться в один неторопливый (Едва за 1Мбайт/с) поток с буферизацией?

Это не многопоточное критичное к скорости чтение из /usr или /home, например.

KRoN73 (16.01.2012 19:26:18)

а памяти в машине сколько? по моему фрагментация резко выражена на xfs при нехватке оперативки

psv1967 (16.01.2012 19:26:51)

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

А то ты, блин, как те Кэпы, которые видя тесты производительности компиляторов на вычислении рекурсивного Фибоначчи, лезут с заявлением о том, что Фибоначчи можно считать в цикле. Можно. И ещё дядько есть в Киеве и бузина в огороде.

KRoN73 (16.01.2012 19:28:02)

Как же линуксоиды столько времени без дефрагментатора жили?

ertgblasd (16.01.2012 19:28:16)

3Гб. RSS + буфера + кеши обычно занимают меньше 100%

KRoN73 (16.01.2012 19:28:52)

Ну, 99.9% виндузятников живут же как-то :)

Кроме того, у нас тоже есть xfs_fsr и дефраг мувом :)

KRoN73 (16.01.2012 19:29:29)

Виста запускает дефраг в фоне, по расписанию. Так что у среднестатистического виндузятника диски дефрагаются с шокирующим постоянством.

Manhunt (16.01.2012 19:43:25)

Как бы у нас уже есть e4defrag.

GotF (16.01.2012 19:46:19)

Это не дефраг, одно название. Как и xfs_fsr на xfs. Он не дефрагментирует свободное пространство, не реорганизует файлы по частоте обращений и не группирует их и т.п.

Сейчас под винду я только один _полноценный_ дефраг знаю — PerfectDisk. Многие ли в курсе про него? А все остальные, что щупал, или делают то же самое, что виндовый, или вообще являются мордами к виндовому :)

KRoN73 (16.01.2012 19:49:29)

>Как бы у нас уже есть e4defrag.

Ну, это у вас. У нас пока его нет:

balancer@balpc-ubuntu:~$ sudo e4defrag
sudo: e4defrag: command not found

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

KRoN73 (16.01.2012 19:50:47)

Тем не менее, файлы вполне себе дефрагментируются.

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

Ибо запатентовано перфектдиском.

Много ли толку от перегруппировки?

Manhunt (16.01.2012 19:57:34)

Ну так и суди по скорости чтения/записи обыкновенных файлов(кинца там, архивов), ибо в данном случае дефрагментация вообще значения не имеет.

Lighting (16.01.2012 20:01:45)

«не дефрагментирует свободное пространство, не реорганизует файлы по частоте обращений и не группирует их и т.п.»

С одних файлов толку мало.

Важно и нужно. При консолидации занятого пространства головке винта меньше бегать. Скажем, при 50% заполнении раздела в аккурат (в среднем) вдвое меньше бегать придётся. А учитывая, что seek — самая тормозная операция во всём процессе… А если ещё многопоточное чтение взять…

Да щаз! А Norton SpeeDisk старых версий чем занимался? :) Или они патент у Norton'а перекупили?

Впрочем, причины не так важны, важно, кто этим занимается, а кто — нет :)

Зависит от задачи. Например, когда все файлы игры находятся в одном месте, скорость загрузки (в том числе подгрузки во время самой игры) весьма сильно поднимается.

KRoN73 (16.01.2012 20:04:28)

В четвёртый (кажется) раз повторяю, что речь идёт о снижении скорости при фрагментации, а не о влиянии этого снижения на конкретные задачи.

KRoN73 (16.01.2012 20:05:36)

современным ФС пофиг на умеренную (т.е. не от торрентов/логов/БД) фрагментацию

Lordwind (16.01.2012 20:09:10)

Объективно это подтвердить можешь?

Lighting (16.01.2012 20:09:53)

www.linux.org.ru/forum/talks/7280107?cid=7280359

KRoN73 (16.01.2012 20:11:44)

www.linux.org.ru/forum/talks/7280107?cid=7280359

KRoN73 (16.01.2012 20:12:00)

Хм, похоже, я слегка перепутал. SMARTPlacement™ is a patented optimization strategy that organizes files according to usage patterns and consolidates free space. This results in faster defrag passes, quicker boot times, slower refragmentation, reduced resource consumption and improved overall performance http://www.raxco.com/user_data/white_papers/perfectdisks_smartplacement_6_1_2011...

Manhunt (16.01.2012 20:13:51)

И у нас его нет, что печально

[art@heaven ~]$ yaourt e4defrag
[art@heaven ~]$ 

OldWiseCat (16.01.2012 20:15:14)

Ну, как я говорил, на самом деле это не так важно. Важно, что PerfectDisk рулит, но его не использует сколь-нибудь заметная доля пользователей :)

А под Linux аналогов вообще нет. Да и простых дефрагментаторов — 1,6 штуки :)

KRoN73 (16.01.2012 20:16:51)

Зато есть e4rat, а в нем e4rat-realloc. Так, что все нормально.

vadik (16.01.2012 20:22:53)

предлагаешь загнать в e4rat.log все файлы диска, а потом запустить e4rat-realloc?

OldWiseCat (16.01.2012 20:24:27)

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

Manhunt (16.01.2012 20:24:54)

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

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

Manhunt (16.01.2012 20:26:39)

Примерно. С одной стороны, все файлы будут перемещены к физическому началу диска. Но с другой стороны - для обычной дефрагментации это конечно излишне. Но лучше так, чем никак.

vadik (16.01.2012 20:30:14)

Для ext4 есть e4defrag начиная с версии утилит 1.42. mv уже ни к чему.

post-factum (16.01.2012 20:32:56)