Ускорение загрузки с HDD за счет специальной дефрагментации

В общем может кто-то уже изобретал

Конечно, изобретал. Твердотельные накопители изобретал.

В общем может кто-то уже изобретал такого рода дефрагментатор

В эру распространенности и доступности SSD дисков, нынче это уже не актуально.

А какой практический смысл всего этого?

Нет, ну так не интересно…

Самый обычный виндовый дефрагментатор со времен 95 винды так и работает, как вы описали в ОП.

Еще небольшой нюанс, с усложнением HDD не всегда возможно точно утверждать как «виртуальные» секторы отображаются в физические (точно знает контроллер диска, но управлять им нельзя), т.е. нельзя быть уверенным что данные перемещаются именно в начало диска или взаимосвязанные данные располагаются рядом на физических секторах.

Опять же, при доступности ОЗУ, кеширование дисковых операций снижает негативный эффект от дефрагментиции.

Опять же, при доступности ОЗУ, кеширование дисковых данных снижает негативный эффект от дефрагментиции.

уже посмотрел в сторону кэширования в том числе и в ОЗУ и на SSD. К сожалению все системы кэширования будь-то bcache, или dm-cache и lvm-cache не рассчитаны на сценарий ускорения загрузки. Или там есть накладки с надежностью в случае пропадания кэширущего устройства. Или накладки с безопаностью, если используется шифрование дисков.

Поэтому самым дружественным к пользователю на HDD ускорителем загрузки будет специальный дефрагментатор, работающий в фоне или по расписанию.

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

поближе к началу диска?

Но зачем? «Поближе к началу диска» - это прежде всего о линейном чтении. Сильно это будет сказываться на считывании какого-нибудь бинарника на пару сотен килобайт из /bin?

Еще можешь поставить

preload - adaptive readahead daemon

Или не страдать фигней и использовать SSD.

Тебе поможет таблица разделов. Корневой раздел должен быть маленьким и хранить как раз примерно то, что ты перечислил. И он будет в начале диска, и эта ситуация будет поддерживаться без доп. усилий. Правда они будут не в том порядке, как нужны при запуске, но с эти сложно что-то поделать.

Еще небольшой нюанс, с усложнением HDD не всегда возможно точно утверждать как «виртуальные» секторы отображаются в физические

Эти небольшие погрешности появляются только у битых дисков и всё равно почти не влияют.

Но зачем? «Поближе к началу диска» - это прежде всего о линейном чтении. Сильно это будет сказываться на считывании какого-нибудь бинарника на пару сотен килобайт из /bin?

Так суть именно в линейном чтении. Чтобы все нужное для загрузки паковалось в одном месте, чтобы можно было условно сделать

dd if=/dev/sda1 of=/dev/null bs=1M count=1000

и быть уверенным что за счет одного линейного чтения, которое у меня проходит за 5 секунд, весь этот гигабайт оказался в page cache, и в этом гигабайте содержались бы все бинарники, либы и конфиги, которые только могли бы потребоваться при загрузке. Чтобы обращений для чтения при загрузке больше не было, ну или их был бы минимум.

preload - adaptive readahead daemon оно решит часть проблемы только. Я могу допустим и так загрузить в page cache все что нужно для загрузки. Но оно не будет последовательно лежать на диске, следовательно будет много лишних перемещений головки.

На самом деле одним из главных побуждений заниматься этой фигней как раз и является желание не иметь разделов. Чтобы был один большой раздел для всего. Это позволяет избегать костылей, когда нужно 200 гб на какой-то торрент или работу, а на одном разделе осталось только 100 а на втором - 150.

SSD на 4+ тб пока еще существенно дороже обычных хардов.

Чтобы был один большой раздел для всего

Плохая идея

Корневому разделу хватит 30гб. Торренты в него класть не надо, всякие базы данных и контейнеры (как по-дефолту делают многие дистры) - тоже.

Это позволяет избегать костылей, когда нужно 200 гб на какой-то торрент или работу, а на одном разделе осталось только 100 а на втором - 150.

Если тебе надо 200гб на что-то, а на диске всего осталось 250 - надо покупать диск побольше, и не важно, на одном разделе эти 250 или на разных.

Смешно, да

Отличная идея. Пользуюсь линуксами уже почти 20 лет, и все возможные недостатки одного раздела лихо перекрывались ситуациями, когда банально не хватало места и жалел, что послушал «правильных» советов.

Ладно, вот пока набор утилит, которые могут быть полезны в этом деле:

vmtouch /usr/bin/perl

Позволяет силой загнать файл в page cache и там его удерживать(см ключи). Есть в стандартных репах дебиана.

filefrag -e /usr/bin/perl

Показывает физические позиции файла на диске и его размер в блоках.

auditd

Демон, который позволяет смотреть какие доступы к каким файлам были. Вроде бы для корректной работы при загрузке нужно в параметры ядра заодно писать audit=1

bootchartd

Демон, что показывает уровень использования IO процессами при загрузке.

Как эти утилиты могут быть полезны? Вы собираетесь вывод auditd анализировать и определять в каких блоках какие файлы? А потом превращать это в большие области и с помощью dd или самописной утилиты читать большими блоками? Зачем тогда vmtouch?

физические позиции файла на диске

Не на диске, а на разделе (смещение от начала ФС). На диске показывает ″hdparm --fibmap″.

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

Дефрагментатора, как вы хотели в стартовом посте, нет. В до SSD эпоху все хотели просто онлайн дефрагментатор и в ext4 сделали поддержку нужных системных вызовов. Но эти вызовы позволяют просто создать нефрагментированный файл, нельзя указать в каком месте ФС (диска) его разместить. Писать оффлайн дефрагментатор ext4 желающих нет.

Зачем писать специальный дефрагментатор ext4, если можно фс-агностически добавить один уровень косвенности, тупо замерить, какие блоки в каком порядке читаются, переложить их подряд на блочном уровне, и получится dm-bootcache?

Ну, чтобы можно было пробовать восстановить хоть что-то сторонними утилитами при сбое НЖМД. хромось — отдельное извращение с запасными rootfs разделами и т.д., а у нас по определению один раздел на весь НЖМД.

Для ext4 есть e4rat, но я не знаю, насколько оно живое еще.

Ускорение загрузки с HDD

заметил что за последние года три скорость загрузги с hdd сильно замедлилась, особенно это заметно на ide винтах

Если таки приспичило - используй прелоад и не майся дефрагментацией.

И после переустановки дистрибутива все данные превращаются в тыкву. Надо просто с запасом места выделить или LVM использовать. Например у меня

Filesystem      Size  Used Avail Use% Mounted on
/dev/root       344G   58G  269G  18% /

Спасибо, походу это как раз то что нужно. Если удастся завести на современных дистрах.

Из того что я прочитал про preload выходит, что на современном десктопе с HDD он имеет смысл только если относительно мало RAM. Если памяти достаточно, то часто используемые программы и так будут сидеть в page cache.

Другой вопрос как уже много лет назад человек добился загрузки Федоров за 2.7 сек. Я пару раз ставил бомжару или ещё какой арчдистр где стартует по дефолту всего штук 5-6 сервисов и то длилось дольше. При том, что у сисьтемды распараллеливание запуска и прочее

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

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

Вроде бы ещё был уреадахеад, который целенаправленно запоминал порядок подтягивания файлов.

А ты не форматируй раздел и всё нормально будет. Файлы дистрибутива за исключением /home и выборочно /var можно и руками подтереть. Переустановка в конце концов - редкая нештатная ситуация, страдать ради которой жонглированием разделами неинтересно.

Переустановка в конце концов - редкая нештатная ситуация

Нет, это штатная ситуация. Есть куча дистрибутивов которые обновляются только переустановкой.

Это либо плохие либо специализированные дистрибутивы. Первые ненужны, для вторых должны быть спец условия.

Это либо плохие либо специализированные дистрибутивы

Это почти все дистрибутивы. Роллинг релизов на самом деле не так много. Так навскидку это CRUX который я использую и убунта. Обновления с версии на версии делаются только переустановкой.

Просто кто-то некомпетентен.

Просто ты рассуждаешь о том о чем не знаешь. Нет смысла плодить велосипеды.

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

Я изобрел, скинул ссылку на github в ЛС

В корпорации M$ изобрели лет ... назад, а что?

кто-то уже изобретал

демон, который именно этим и занимался - складывал

список указанных файлов

туда, где их побыстрее считывать.

потом правда изобрели ещё много всего…

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

Было такое, для reiserfs. Именно в таком виде — список файлов можно было переместить в самое начало. Но результат почему-то не получался таким же впечатляющим, как в рекламных материалах e4rat. Возможно, из-за особенностей HDD, на котором я тестил. HDD был очень тормозной, даже по меркам 15-летней давности.

Сколько-то раз сделал такую операцию, после обновлений, но потом забил. Хотя разница во времени запуска была, с субъективной точки зрения разница была между медленной загрузкой и чуть менее медленной загрузкой. Возня того не стоила.

«В порядке вероятности доступа» — это фигня. Надо, как в Story of Mel — чтобы файл оказывался под головкой именно в тот момент, когда его надо читать. Причём раскладывать так файлы исключительно руками.

Провел эксперимент над директорией с 20 000 мелкими файлами. Сперва читал все подряд в порядке их листинга в директории. Вышло 43 секунды. Потом прогнал их все через скрипт с filefrag, чтобы понять как они расположены на диске. Сделал список файлов в порядке их физического расположения. Выкинул все файлы из кэша с помощью vmtouch -e и прогнал чтение уже в порядке следования на диске. Вышло 28 секунд.

Повторил эксперимент 3 раза и погрешность +/- 1 секунда. Т.е. на 50% медленнее выходит только потому что головка движется в разные стороны, а не в одну. При этом характер папки - почтовый ящик формата maildir с сообщения об ошибках, которые накопились месяца за 3. Т.е. записи туда активно перемежались с записями в другое место.

Перед этим прогнал дефрагментатор, что гарантировало, что не нужно будет скакать по разным диапазонам для одного файла. ФС - ext4, размер жесткого диска - 1 ТБ.

Но пожалуй главное самое главное отличие в юзабилити - это тишина работы. Когда головка идет только в одну сторону диск не «хрустит».

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

Ошибка в измерениях - я включал в скрипт вызовы filefrag, что добавляло время. Более точные цифры - 16 и 29 секунд соответственно, еще быстрее в пользу упорядоченного чтения.

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

Открой для себя e4rat

По поводу e4rat. Во-первых оно требует патчить ядро иначе не заработает в режиме пре-аллокации. При оставшемся режиме оно даже 2 мелких файла не может выстроить рядом.

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

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

как отследить все файлы который процесс считает при загрузке

strace и/или blktrace

Сделал список файлов в порядке их физического расположения.

Стоило собрать адреса фрагментов, и сортировать уже их. Читать можно само блочное устройство.

Спасибо, strace подошел. Если кому-то пригодится на будущее:

strace -o access.log -e trace=open,creat ls /

Стоило собрать адреса фрагментов, и сортировать уже их. Читать можно само блочное устройство.

Так я и собирал адреса фрагментов и сортировал порядок чтения по адресам фрагментов. По поводу чтения самого блочного устройства. Page cache не работает при прямом доступе диску, только к файлам. Т.е. если сделаю dd if=/dev/sda bs=4096 count=1 skip=12345 of=/dev/null по смещению файла, чтобы прочитать его, то данные в page cache не попадут. Но если я сделаю cat /tmp/file, то он будет в кэше.

По поводу чтения самого блочного устройства. Page cache не работает при прямом доступе диску, только к файлам

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

Когда-то было что-то такое. Но после каждого обновления надо было повторять дефрагментацию, вручную включив опцию во время загрузки. Муторно. И прирост был не ахти.

Я, конечно, извиняюсь, а банальный e4defrag ты пробовал?

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