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

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

А я об этом же, bigfile может быть размазан на тысячи частей по фс, в то время как тысяча мелких файлов лежать последовательно.

Проблема в том, что в хранилище находится книжная библиотека и медиатека. Если второе - все понятно файлы большие, то с первым не все так просто. Библиотека состоит как из книг так и из архивированных видеокурсов, что автоматом превращает их в большие файлы. Если делить хранилище на две части и раскидывать в одно большие, а в другое маленькие файлы - получается абсолютная каша. И это не совсем найс

Оставь в покое массив на пару суток. Ты его активно юзаешь и не даешь ему прочухаться после дефрагментации

Да я уже половину с него выкачал) дурная голова же рукам покоя не дает) я испытаю дефрагментацию и ожидание на пару недель на стендовом компе, чтобы убедиться, что просто нужно время

Нам только не забудь сообщить о результатах)

Ну тогда эту тему пока лучше не закрывать) У меня как раз послезавтра отпуск и будет время поиграться со всем этим

Если файл туда положили за 1 раз, то он будет более-менее последовательно лежать. А тысяча последовательных мелких файлов ничему не поможет, т.к. скачивать их будут в рандомном порядке и крайне маловероятно что он совпадёт с расположением на диске.

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

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

Одна директория в которой 1000 мелких файлов, как положил последовательно, так и будут лежать.

Яблочник?

Во-во-во, молодец. В аккурат под отпуск. Как раз есть чем занять весь отпуск :). Лучше отложить, конечно же и поиграться после отпуска

Причём тут это?

А это вообще о чём?

А что непонятно было? Я вроде вашу цитату привел.

Извините, значит ошибся... Попробую второй вариант: Изобретатель колеса?

Цитата то моя, а вот ответ на неё непонятно к чему был.

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

Чем эта «рандомность» блоков, если она есть, будет отличаться от рандомности блоков одного большого файла?

Тем что эти файлы в целом могут качать как попало. А с одним большим шансы на это куда меньше.

Чисто теоретически запуск e4defrag мог сделать фрагментацию хуже, но это маловероятно. И это скорее бы испортило чтение фрагментов отдельных файлов, а не чтение файлов целиком. При обработке каждого файла e4defrag выделяет место под размер файла и перемещает содержимое файла в новое место. Но перемещение выполняется только если число фрагментов нового места файла меньше текущего числа. Если, скажем, изначально файл был побит на 100 кусков по одному мегабайту, а новое место состоит из 98 кусочков по 4 килобайта и одному сплошному куску на 99 с чем-то там мегабайт, то для e4defrag это выглядит как выгодная сделка, хотя в реальности чтение нового места будет вызывать знатный хруст. Но чтобы аллокатор ext4 выделил настолько странное место, хранилище должно быть забито почти под завязку. Обычно размеры кусочков примерно одинаковые, поэтому эвристика основанная исключительно на числе фрагментов в среднем работает.

Я думаю, что тут дело в том, что до фрагментации проверку проводили на одном наборе файлов, а после фрагментации продолжили на другом. Первый читался хорошо, а второй читается хуже. Например, первый набор данных представлял большие файлы по несколько гигабайт, а второй — большое число разбросанных по диску мелких файлов. Ещё и процесс ext4lazyinit довольно сильно роняет производительность жёстких дисков, если пытаться читать-писать, пока он не закончил читать битмапы. Это ещё добавляет ощущения «а-а-а, всё сломалось». Но его легко переждать, это всего лишь несколько минут после холодной перезагрузки.

Так что вряд ли запуск e4defrag как-то повлиял.

Тем что эти файлы в целом могут качать как попало. А с одним большим шансы на это куда меньше.

Та ладно?

У меня после удаления больших файлов еще некоторое время(от часа и более) диск подхрюкивает. Хр-хр-хр-хр. Через определенный интервал опять Хр-хр-хр-хр. При этом в iotop какой-то процесс связанный с диском появляется и немного io забивает.

Похоже, что накопители сами инициируют этот хруст. У меня подобное воспроизводилось, даже когда я накопитель отмонтировал, а blktrace не показывал никакого доступа к диску со стороны хоста. Контроллер диска просто сам решает пошуршать головками. Судя по спискам, диски у меня CMR.

Похоже, что накопители сами инициируют этот хруст.

Это автоматическая термокалибровка IMHO

Это из него песок сыпался :)
А без шуток:

даже когда я накопитель отмонтировал
Судя по спискам
спискам
диски

Вы на основании чего решали, что именно отмонтированный шуршал?

на основании чего решали, что именно отмонтированный шуршал?

┌──────────────────────────┐
│                          │
│       Laptop             │     ┌───────────────────┐
│                          │     │   USB enclosure   │
│     ┌──────────┐         │     │                   │
│     │   SSD    │         ├─────┤   ┌────────┐      │
│     └──────────┘         │     │   │  HDD   │      │
│                          │     │   └────────┘      │
└──────────────────────────┘     └───────────────────┘

Оочень интересно. Никогда такого не встречал, а на каком дистре/ведре это было?

USB enclosure

Если внешний диск не самосбор, то вероятность SMR увеличивается (даже если такой же диск, продаваемый отдельно, без коробочки, CMR).

Какое там ядро актуальным было где-то год назад? Вот начиная с него, почти все подряд. Как минимум те, что были в Debian testing.

Поясните плиз.

Читал историю в те годы, когда буквы SMR только начинали становиться известными. Кто-то купил внешний HDD (например, от Сигейт) по цене ниже, чем просто диск такой же ёмкости, вытащил диск из коробочки, и некоторое время радовался, пока не начались странности, присущие SMR. Так партнамбер диска был, вроде бы, такой же, как у обычного диска, продаваемого отдельно и без черепичной технологии.

Контроллер диска просто сам решает пошуршать головками

Да. Этот процесс именно внутренний. Но иногда после удаления что-то на уровне фс происходит. В iotop висит процесс, который io потребляет

При термокалибровке тоже диск хрустит, но чуть-чуть по-другому

Да, тоже припоминаю, вроде поначалу была какая-то фигня с неявной маркировкой или что-то в таком же духе.

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

Может, файлы сначала лежат ближе к внешнему краю блинов
к внешнему краю блинов

ГеОмерт?

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

Так файлы же не линейно записываются на диск

Итак дамы (если тут есть дамы) и господа! После тщательных проверок, тонны инициализаций и переинициализаций, проверок, записей и чтений в разных приложениях, операционках и файловых системах, пришел к выводу, что проблема была отнюдь не в фрагментации данных. Дело в том, что у меня аппаратный контроллер и у него есть такая функция как «Patrol Read» (Для незнающих: помогает обнаруживать и исправлять плохие блоки на жестких дисках и предотвращать возможную потерю данных. Patrol Read генерирует значительное количество запросов к диску, которые могут уменьшить производительность RAID контроллера). Когда он включен - скорость записи и чтения о-о-очень существенно снижается. При выключенном состоянии данной функции - все считывается и записывается мега-быстро (скорость записи достигает 450 мб/с, а скорость чтения при включенном кэше на дисках может подниматься и до 700-800). Думаю данную тему можно считать закрытой. Всем спасибо за участие и да прибудет с вами сила

А я предупреждал: MD спасет этот мир.

Patrol Read после перемещений файлов начал шуршать по диску? Или ты попутно дефрагментации включил Patrol Read и перевозбудил половину ЛОРа? :)

Patrol Read работал все время) Он включился скорее всего тогда, когда я сбросил все настройки контроллера некоторое время назад. А поскольку я не знал о такой функции - возникло непонимание, почему так происходило. По всей видимости Patrol Read начинает мешать работе дисков после дефрагментации особенно сильно. Но вот что интересно… На ext4 эта функция мешает ТОЛЬКО после дефрагментации. Именно после нее включается процесс «ext4lazyinit». Если брать во внимание NTFS, то эта функция мешает с самого начала. С чем связано такое поведение - не знаю. Но как только я ее отключил все стало прекрасно. Не скажу, удалось ли победить «ext4lazyinit», потому что конечные тесты проводил внутри Windows (особенно при помощи сторонней утилиты). Планирую на днях провести аналогичную проверку на Linux, чтобы понять, будет ли каким-либо образом мешать «ext4lazyinit»

Хотя, возможно, «ext4lazyinit» срабатывает каждый раз при запуске системы, но при включенном Patrol Read этот процесс особенно заметен и особенно мешает

после дефрагментации. Именно после нее включается процесс «ext4lazyinit»

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

Единственная связь с фрагментацией — чтение битовых карт свободного места, которое производится внутри нити ext4lazyinit, снижает шанс фрагментации при записи новых файлов на ФС. С кешированными картами распределитель с большим шансом найдёт сплошное свободное место. Без кешированных карт будет использовано почти любое подходяещее свободное место, которое может оказаться сильно раздробленным.

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

Тем более на хардварном RAID-0. (%