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

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

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

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

Ну объяснил бы

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

Сформулировал бы выводы

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

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

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

Если только контроллер не умный и сам в фоновом режиме не оптимизирует размещение и не стирает ненужное.

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

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

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

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

Починил.

Починил.

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

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

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

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

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

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

/var как раз не стремно

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

Я это к тому, что

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

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

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

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

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

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

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

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

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

И потвикать бубунту не забудь, ага.

Это на Gentoo было.

Вот смотрю я на эти картинки и думаю: а нафига раздел на 90-90% забивать?

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

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

Не забивай раздел до отказа, не будет фрагментация бешено расти.

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

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

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

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

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

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

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

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

downloads забит на 92%, доступно 33Гб.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

а памяти в машине сколько?

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

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

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

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

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

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

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

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

Виста запускает дефраг в фоне

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

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

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

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

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

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

Это не дефраг, одно название.

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

Он не дефрагментирует свободное пространство

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

не реорганизует файлы по частоте обращений

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

не группирует их

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Хм, похоже, я слегка перепутал. 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_2...

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

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

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

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

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

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

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

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

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

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

А если ещё многопоточное чтение взять…

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

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

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