LINUX.ORG.RU

Фрагментация ext4 на торрентах, личный опыт

 , ,


0

3

Жил-был у меня раздел, который когда-то, лет 14 назад, был /home. Время шло, он переехал на новый винчестер при помощи dd. Затем у меня завёлся SSD и я переместил /home на него а то, что было /home/user/torrents, оставил, теперь у меня /home на SSD, а /home/user/torrents на HDD. Потом /home переехал на более крупный SSD, а потом ещё раз - на ещё более крупный. Всё при помощи dd.

Таким образом, у меня раздел /home/user/torrents жил 14 лет, а /home примерно 10 лет с двумя переездами при помощи dd. И тут я в эти выходные вдруг взял да озаботился дефрагментацией при помощи e4defrag. А почему бы и нет.

В целом, раздел /home/user/torrents дефрагментировался примерно полчаса и показал уровень фрагментации 0.1%. Раздел /home дефрагментировался четыре часа (на ssd!) и показал уровень фрагментации около 4%. Оба раздела имеют одинаковый размер в 2Тб. Особенно фрагментированными оказались директории ~/.cache, ~/.local/share/Trash, ~/Downloads и, как ни странно, ~/.config.

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

Это я всё к чему. Сдаётся мне, проблема фрагментации из-за торрентов слегка преувеличена.

Дискас.

★★★★★

Сдаётся мне, проблема фрагментации из-за торрентов слегка преувеличена

Особенно если ставить галку «резервировать место сразу». Впрочем, фрагментация на ext4 никогда проблемой не была, а уж в современных условиях многоядерных процессоров и ssd тем более.

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

дефрагментация не зависит от многоядерности процессоров или типа фс, это вообще побоку :)
дефрагментация напрямую зависит от времени перемещения головки винчестера от одного фрагмента к другому.
в ssd это время ==ноль.

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

дефрагментация не зависит от многоядерности процессоров

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

или типа фс

Дизайн всех современных фс делался во времена, когда основными носителями были харды, поэтому во всех них на уровне самой фс встроена борьба с фрагментацией. У ext4 это экстенты.

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

в ssd это время ==ноль.

стало быть, тесты на чтение показывают одинаковую скорость для rand read и seq read. Верно? Так и есть?

targitaj ★★★★★
()
Последнее исправление: targitaj (всего исправлений: 1)
Ответ на: комментарий от gremlin_the_red

экстент сколь помню делался не для уменьшения фрагментации, а для упрощение структуры inode один экстент размером до 128мб создавал в inode одну запись взамен 30 000 записей блоков размером всего в 4 кб максимум.
дефрагментацию уменьшала карта свободного места ранжированная по размеру свободного места. т.е. появилась возможность выбирать подходящий по размеру свободный блок и полностью его заполнять.

pfg ★★★★★
()
Последнее исправление: pfg (всего исправлений: 1)
Ответ на: комментарий от targitaj

по идее да.
но остаются еще расходы на обслуживание работы файловой системы по формированию запросов и все такое.

рандомное чтение кусков данных с разных концов ssd будет практически идентично по скорости чтению кусков данных последовательно расположенных.

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

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

интересно бы еще сравнить скорости прямого и рандомного чтения из /dev/sd* без фс замудрений и разделов.

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

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

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

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

рандомное чтение кусков данных с разных концов ssd будет практически идентично по скорости чтению кусков данных последовательно расположенных.

для большого количества мелких файлов эта мантра почему то не работает. скорость падает очень сильно

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

на больших количества мелких фалов сами файловые системы накрываются со скоростью, даже в условиях RAMдисков…
все зависит от структур и качеств фс

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

Кэши сбрасывал? Место резервировал?В первом случае кино на флешку не копировалось? Винт и мать с NCQ были?

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

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