LINUX.ORG.RU
ФорумTalks

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


0

2

ext4, /home, не дефрагментировался года два:
http://balancer.ru/img/forums/1201/ext4-home-frag.png

ext4, /usr, дефрагментирован (мувом) месяца два назад:
http://balancer.ru/img/forums/1201/ext4-usr-frag.png

ext4, /var, дефраг мувом несколько месяцев назад:
http://balancer.ru/img/forums/1201/ext4-var-frag.png

xfs, downloads для торрентов, дефраг несколько месяцев назад
xfs_fsr: actual 145198, ideal 6665, fragmentation factor 95,41%
http://balancer.ru/img/forums/1201/xfs-downloads-frag.png

Для построения карт фрагментации использовался Визуализатор фрагментации файлов на диске. С квадратиками

★★★★★

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

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

Stahl ★★☆ ()

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

Sadler ★★★ ()
Ответ на: комментарий от Stahl

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

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

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

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

KRoN73 ★★★★★ ()
Ответ на: комментарий от Sadler

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

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

KRoN73 ★★★★★ ()
Ответ на: комментарий от KRoN73

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

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

Relan ★★★★★ ()
Ответ на: комментарий от Relan

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

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

KRoN73 ★★★★★ ()
Ответ на: комментарий от KRoN73

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

Починил.

spoilt ★★★ ()
Ответ на: комментарий от KRoN73

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

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

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

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

Relan ★★★★★ ()
Ответ на: комментарий от Relan

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

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

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

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

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

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

KRoN73 ★★★★★ ()

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

Lighting ★★★★★ ()
Ответ на: комментарий от spoilt

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

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

KRoN73 ★★★★★ ()

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

unanimous ★★★★★ ()
Ответ на: комментарий от Lighting

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

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

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

Это на Gentoo было.

KRoN73 ★★★★★ ()
Ответ на: комментарий от unanimous

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

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

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

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

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

KRoN73 ★★★★★ ()
Ответ на: комментарий от KRoN73

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

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

Lighting ★★★★★ ()
Ответ на: комментарий от Lighting

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

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

KRoN73 ★★★★★ ()
Ответ на: комментарий от zloy_buratino

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

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

KRoN73 ★★★★★ ()
Ответ на: комментарий от KRoN73

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

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

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

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

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

unanimous ★★★★★ ()
Ответ на: комментарий от KRoN73

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

Lighting ★★★★★ ()
Ответ на: комментарий от unanimous

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

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

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

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

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

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

KRoN73 ★★★★★ ()

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

psv1967 ★★★★★ ()
Ответ на: комментарий от Lighting

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

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

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

KRoN73 ★★★★★ ()

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

ertgblasd ★★ ()
Ответ на: комментарий от psv1967

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

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

KRoN73 ★★★★★ ()
Ответ на: комментарий от ertgblasd

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

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

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

KRoN73 ★★★★★ ()
Ответ на: комментарий от KRoN73

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

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

Manhunt ★★★★★ ()
Ответ на: комментарий от KRoN73

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

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

GotF ★★★★★ ()
Ответ на: комментарий от Manhunt

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

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

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

KRoN73 ★★★★★ ()
Ответ на: комментарий от GotF

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

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

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

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

KRoN73 ★★★★★ ()
Ответ на: комментарий от KRoN73

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

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

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

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

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

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

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

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

Manhunt ★★★★★ ()
Ответ на: комментарий от KRoN73

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

Lighting ★★★★★ ()
Ответ на: комментарий от Manhunt

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

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

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

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

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

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

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

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

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

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

KRoN73 ★★★★★ ()
Ответ на: комментарий от Lighting

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

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

KRoN73 ★★★★★ ()
Ответ на: комментарий от KRoN73

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

Lordwind ★★★★★ ()
Ответ на: комментарий от KRoN73

Да щаз! А 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...

Manhunt ★★★★★ ()
Ответ на: комментарий от Manhunt

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

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

KRoN73 ★★★★★ ()
Ответ на: комментарий от OldWiseCat

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

vadik ★★ ()
Ответ на: комментарий от vadik

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

OldWiseCat ★★ ()
Ответ на: комментарий от KRoN73

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

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

Manhunt ★★★★★ ()
Ответ на: комментарий от KRoN73

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

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

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

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

Manhunt ★★★★★ ()
Ответ на: комментарий от OldWiseCat

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

vadik ★★ ()

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

post-factum ★★★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.