e4defrag и последствия

Еще один аргумент в пользу дефрагментации.

Пишут можно побороть опцией no_prefetch_block_bitmaps если я правильно понял

https://bbs.archlinux.org/viewtopic.php?id=270111

К сожалению не помогает. Да, «ext4lazyinit» не активируется. Однако диск стал работать еще медленнее, как и говорится по ссылке, что теряет в производительности немного

а рэйд какой, программный или железо?

32 Тб большая цифра, скинуть вероятно будет некуда?

Железо (lsi mr9260-8i). Да скинуть-то есть куда. Тоже уже задумываюсь о переинициализации хранилища с нуля. Думал смогу отделаться «малой кровью» и решить вопрос без слива данных. Проблема лишь в том, что это занимает время, а из-за возникшей заторможенности хранилища - скидываются файлы тоже целую вечность

RAID0

Я имел ввиду софт или железо

Вероятно из-за размера хранилища доформатирование отъедает слишком много ресурсов, вот оно и начинает на основной деятельности тупить.

Железо (lsi mr9260-8i)

Тогда почему так выходит, что доформатирование происходит каждый раз после дефрагментации?

Возможно оно не происходит после, а становится заметно после. Я так понимаю е4дефраг оптимизирует существующие данные для чтения, возможно это приводит к необходимости метаться к сильно разным секторам для доформатирования. Но это ясное дело предположение.

Ну напиши Тцо, он наверное знает что там может быть.

md спасет этот мир :)

И постоянно после e4defrag замедляются.

Всмысле ты несколько раз это делал? Значит после первого замедления ты как-то смог всё исправить чтобы потом сделать второе?

Очень прошу, подскажите куда копать, что смотреть, изменить и тд

Видимо, не делать e4defrag.

Нет я это делал 1 раз на каждой системе. До этого у меня стоял Ubuntu Server. Я ни разу не делал e4defrag по нескольку раз. Но регулярно после 1 раза использования (назовем это оптимизацией) всегда картина одна - на любой системе диски начинаются ощутимо замедляться

Насколько заполнена ФС, какие размеры файлов? Фрагментация до и после запуска e4defrag анализировалась/сравнивалась?

ЕМНИП, e4defrag просто переписывает файл, никаких гарантий, что фрагментация файла при этом снизится нет.

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

Возможно, что ext4lazyinit у вас был давно, просто выполнялся быстрее.

ФС заполнена примерно на 40%. Размеры файлов разные: от нескольких килобайт до 150гб, ибо это одновременно и медиа и книжная библиотека. А файлов там 35тыс по подсчетам. Дефрагментировать все вручную, начиная с мелких файлов - геммор как минимум) В общем выкачиваю уже все данные с хранилища и буду переинициализировать его. Наверное тему можно закрывать.

P.S. Не пользуйтесь e4defrag, пацаны. Вы своим компам еще нужны)

Как ты вообще дефрагментацию делал? В этот момент на диски что-то писалось?

По «вручную» я подразумевал самописные скрипты...

Выкачиваю уже все данные с хранилища и буду переинициализировать его

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

Нет на диски ничего в этот момент не писалось. Компьютер простаивал. Алгоритм был следующий: инициализировал РЕЙД, установил ОС с указанием точки монтирования. Далее в самой ОС закачал файлы на РЕЙД, захэшировал данные через EiskaltDC++ (скорость считывания/хэша стабильно была около 350мб/с). После чего сделал дефрагментацию. Далее после перезагрузки при старте системы стала появляться медленно работающий процесс ext4lazyinit (оооооочень медленно). Заподозрил неладное и решил перехэшировать данные. И действительно - скорость упала в разы. Ранее такое повторялось. Во время дефрагментации никаких записей на диск не производилось, система была абсолютно статичной

Окей, так и сделаю. Спасибо

Раздел был перемонтирован в ro или нет перед дефрагментацией?

Прописал в /etc/mke2fs.conf

[defaults]
        [...]
        lazy_itable_init = 0
        lazy_journal_init = 0

(можно и параметрами к mkfs)

Форматирую раздел диска в ext4 (никаких рейдов, lvm). e4defrag вызываю с -v для контроля. Как только процесс завершается, диск больше никто не дёргает. Чтобы e4defrag мог эффективно работать, необходимо иметь нефрагментированное свободное место подходящего размера. Т.е. как только таковое закончится, раздел придётся «дефрагментировать» путём переписывания всего на другой диск. К сожалению, умного дефрагментатора так пока и нет.

А вот это интересно. Проверим пожалуй. Благодарю

У меня после удаления больших файлов еще некоторое время(от часа и более) диск подхрюкивает. Хр-хр-хр-хр. Через определенный интервал опять Хр-хр-хр-хр. При этом в iotop какой-то процесс связанный с диском появляется и немного io забивает. Возможно, после дефрагментации в «мехах» какие-то процессы осуществляются. Из-за этого падение скорости. Надо было подождать хотя бы сутки. И для чистоты эксперимента - в следующий раз с livecd делай дефрагментацию. Потому что сам по себе дефрагментатор - всего-навсего переносит файлы в другое место диска. Из-за этого не может быть никаких падений скорости(таких существенных, как у тебя). Значит есть какие-то процессы, которые или io забивают, не давая в полной мере работать девайсу. Возможно даже там параллельно два процесса происходят: 1. на уровне ос 2. на уровне самого девайса

PS: это у меня на 1тб так долго подхрюкивает девайс. А у тебя на 30тб все эти процессы могут занимать и более суток. Думаю, что в этом и есть причина падения скорости после дефрагментации. Дефрагментировал 30тб - недельку подожди)))

Ну я тоже пытался делать дефрагментацию ради интереса и эксперимента через livecd. Тогда диски теряли в скорости еще больше О_О

Да и как-то много неделька) Я на ноутбуке ради чистоты эксперимента проводил дефрагментацию 1Тб. После чего файлы не трогаю на нем уже месяца 2. И все равно скорость осталась ни о чем

ext4lazyinit

So that is what the lazyinit thread does; it is slowly zeroing out the not-yet-used portions of the inode table. Previously, the inode table initialization would be done during mke2fs, but this would make the mkfs process very slow for very large or very slow disks. So instead, we defer this to when the file system is mounted. The reason why can take hours is that we deliberately try to make it take roughly 10% of the disk bandwidth, to minimize the impact on system performance. This can be tuned via a mount option, or you can force the inode table initialization to happen at mke2fs time (so what might take 2 hours for your drive would make mke2fs about 12 minutes longer). You can also temporarily or permanently disable the lazy initialization via a mount option.

Вот что делает поток lazyinit; он медленно обнуляет еще не использованные части таблицы инодов. Раньше инициализация таблицы инодов выполнялась во время mke2fs, но это делало процесс mkfs очень медленным для очень больших или очень медленных дисков. Поэтому вместо этого мы откладываем это до момента монтирования файловой системы. Причина, по которой это может занять несколько часов, заключается в том, что мы намеренно пытаемся сделать так, чтобы это занимало примерно 10% пропускной способности диска, чтобы свести к минимуму влияние на производительность системы. Это можно настроить с помощью параметра монтирования, или вы можете заставить инициализацию таблицы inode происходить во время mke2fs (так что то, что может занять 2 часа для вашего диска, сделает mke2fs примерно на 12 минут дольше). Вы также можете временно или навсегда отключить ленивую инициализацию с помощью параметра монтирования.

Я утверждаю, что из-за дефрагментатора не может быть существенной просадки в скорости. Вообще-то его цель в обратном. Поэтому, падение скорости происходит по причине post-процессов, после перемещения файлов дефрагментатором. Тебе просто после дефрагментации надо ничего не трогать некоторое время. Но если ты сразу включаешь какие-то процессы, которые диск дёргают на полную мощность, то у тебя post-defrag процессы будут затягиваться. На какое время? Да хз

И ленивую инициализацию отключал. При чем буквально вчера. И если после дефрагментации скорость падала примерно до 80мб/с, то при отключенном ext4lazyinit - скорость упала до 50мб/с

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

Что иное - надо углубляться в это, У меня этот кейс появляется раз в 10-15 лет. Если тебе интересно, можешь углубиться. А потом нам рассказать не забудь))

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

Всё правильно. Если ты о скорости записи. Там же нулями не забито. Оно лениво тебе нулями забивало. 60% диска. При параллельных процессах post-defrag + твоей шарилкой это приводило к офигительному падению скорости

Там же нулями не забито. Оно лениво тебе нулями забивало. 60% диска.

Вы же и по-английски, и по-русски привели цитату. Никакие не 60% диска. Только метаданные ФС, т.е. таблицы inode.

Видимо это затратный процесс, раз он долго висит и просаживает скорость

Это не диски с черепичной записью (SMR)?

Нет. Это два диска Western Digital Gold 18Tb с CMR

CMR != continuous layout. А других на >4ТБ и не будет скорее всего.

Вангую что дефраг на логическом уровне вызвал фрагментирование на физическом.

Значит тем более ничего не остается кроме переинициализации)

blkdiscard попробуй сделать перед этим

А то скорость может такой же остаться )

blkdiscard попробуй сделать перед этим

Сейчас все hdd (даже не SMR) поддерживают blkdiscard?

Не хватит просто переинициализации всего RAID’а?

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

Понял принял. Благодарю за подсказку. Почитал про blkdiscard, но так и не понял одного. Это «разовая акция» или надо ждать пока все затрется и перезапишется?

А вы жесткий

Да не с таким падением скорости

Вообще ты конечно свинота. Такую тему социально важную поднял, всех перевозбудил. А потом взял и массив пересоздал. Надо ж было хоть сутки подождать. Подёргать и то и это. Может сама проблема ушла(мой сценарий) или кто-то решение подсказал бы

Ну я пока еще не переинициализировал массив) данные еще выкачиваются…скорость-то все таки небольшая) Так что еще время есть

Размеры файлов разные: от нескольких килобайт до 150гб, ибо это одновременно и медиа и книжная библиотека.

К дефрагментации это не имеет отношения, но всё таки сообщу.

Сувать это всё под нагрузкой в общее хранилище - плохая идея. Большим файлам нужен быстрый последовательный доступ, маленьким - постоянная езда головками в разные стороны, при объединении получается плохо и первое и второе. Раздели на два массива, один для файлов до 1гб (точнее порог зависит от ситуации) допустим, другой для тех что больше.

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

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

А если «Большой файл» это бд ? Не приходится «ездить головками»?

У него файловый сервер с которого скачивают. Скачивают обычно весь файл целиком.

А что касается БД то её лучше тоже на отдельном накопителе делать и лучше если это ссд будет а не раздел на hdd-рейде.