Как я преисполнился решимости осилить Gentoo arm64/musl
Года два назад переехал дома на Debian arm64. Но, ещё в тот момент, это мне казалось недостаточным, ввиду тех изменений, что произошли в дистрибутиве (в Debian’е): одноплатный компьютер, работающий роутером, внутри которого заправляет всем systemd, – ну это как-то странно. Про обилие X’овых библиотек в системе, с которой работаешь только по ssh или по uart, – это мы ещё с Debian 6 привыкли. «Universal operation system» же. Но уж очень хотелось не столь универсальный инструмент применить!
Пустота и Альпы
Я поискал дистрибутивы, которые не пытаются быть столь многофункциональными, как Debian, Red Hat или Arch. Больше всего мне приглянулись Void и Alpine. Но первый, на поверку, оказался всего-лишь игрушкой, в которой нет ни рецензирования принятия решений, ни тестирования… Вообще ничего, что есть у зрелого дистрибутива. Ну а второй… Второй просто узко ориентирован на встраиваемые системы. Это не плохо, но мне этого не нужно. Тем более имеющиеся у меня одноплатные компьютеры не поддерживаются из коробки в Alpine Linux.
Gentoo? Gentoo!
В любой непонятной ситуации ставь gentoo. Но не забывай, что как-только тебе понадобится что-то не стандартное, вся эта гибкость, которую тебе преподносят как достоинство, вот сразу она исчезнет. А головная боль, которую она привносила, только усилится. Потому что ты не сможешь собирать систему на каждом однопалатном компьютере. Он работать должен по назначению, а не компилятором 24/7 греть корпус. Значит придётся делать сборочную ферму. Значит как-то придётся на все одноплатники затягивать не только готовые бинарные пакеты, но и все конфиги portage, а так же тот срез архива ebuild’ов и всех оверлеев, из которых пакеты собирались. Нет, apt и yum в этом отношении значительно больше подходят для работы с бинарными пакетами.
Хранилище, наконец-то! И первая просадка во времени.
Сборка у нас только нативная, во имя качественного кода. Собирать назначены одноплатные обогреватели на Allwinner A64. И пока они, подключённые по AoE к SSD на настольном компьютере, молотили сборку первичных образов моей hardened/musl arm64 gentoo (полный фарш же!), я начал собирать СХД, чтобы закинуть оное на антресоль. Ну не вечно же держать настольный компьютер включённым?
И, внезапно, в ящике стола были найдены копеечные usb-sata переходники. А в нижнем ящике — снятые в запас НЖМД на 2ТБ. Отлично! Вопрос был только в одном — как запитывать НЖМД? 5В от USB там не достаточно… Да и нужную силу тока с одного разъёма USB не достанешь. Принято было решение поднять ножки разъёмов USB на переходниках, чтобы разорвать цепи питания. Питание же подавать напрямую, сразу на разъём SATA переходника, напаяв на ножки провода. На антресоли уже был установлен БП 12В 100Ватт. Он питает роутер и зеркало Debian (они тоже исполнены на базе одноплатных компьютеров). Значит к каждому НЖМД нужен ещё dc-dc с 12в -> 5в. И реле, которое было бы подцеплено к входу питания USB от одноплатного компьютера, чтобы обесточивать НЖМД, когда отключается подача питания на разъём USB-хоста.
Ну… Паяю то я хорошо, и даже быстро. Просто когда ты работаешь на предприятии, где все твои хотелки разработчика запрещено тебе паять лично, и паяют их монтажницы (это называется разделением труда), то иногда оценка трудозатратности может тебя подвести. Так, неожиданно для себя, выпал почти на день. И, когда я всё это запустил, уже начал думать, что это — победа. Ну правда. Что там осталось? Raid собрать? Это же просто сутки треска жёстких дисков! Но через те самые сутки, когда raid собрался, была обнаружена отвратительная проблема — скорость чтения и записи значительно отличались от расчётных. Сильно отличались. И всё бы ничего, но дело было не в ограничениях I/O по портам USB для данного SoC. Я скорость одновременной записи предварительно проверил, такой проблемы не наблюдалось.
Не буду сильно тайну раздувать: проблема оказалась в размере chunk’а raid’а. Он по-умолчанию нынче равен 512КБ. И для arm-машинки это оказалось оооочень много. Уменьшение размера chunk до 64КБ полностью решил проблему. Оконечная скорость линейной записи на массив составила около 2.5Х скоростей записи на одиночный диск. Ну и чтение, выше всех похвал, – четырёхкратная скорость, относительно одного диска! То есть raid5 на четырёх дисках, подключенных через USB к SBC на Allwinner H5, имеет производительность удовлетворительную для сетевого хранилища. Для условий, когда СХД собиралось практически из того, что найдено в тумбочке бесхозного, – отличный результат. Потом пересоберу на более производительной платформе. Или с USB3.0, или с PCI-SATA. А может и SoC с встроенным SATA найду доступный…
Неожиданные грани качества кода
И пока я ковырялся с тем, что делал что-то ответственное из того, что для этого не предусмотрено, сборочная ферма продолжала эксплуатировать SSD’шник моей рабочей станции, используя AoE. И вот, ввожу я в строй СХД, настраиваю AoE на нём, и… внезапно AoE показывает запись на СХД около 3МБ/с. А до этого, когда сервером трудилась рабочая станция, было не менее 90МБ/с. Начал я искать причину, и нашёл! Проблема проявлялась, когда vblade собирался с musl. Скорость записи на блочное устройство через AoE моментально падала до 5МБ/с.
Никогда я не видел столь наглядной иллюстрации всех проблем использования плохо переносимых программных решений! Ну вот чтобы так явно-то! AoE пока мне не светит. У него конечно есть ядерная реализация kvblade, но она не собирается для ядер старше 4.19. Надо потом подумать об портировании в свежие ядра. Но это сложно, да и не выполнимо с наскока.
Следующим был на очереди iSCSI. Но open-iscsi не собирался. Причина была в том, что автор кода умудрился указать long unsigned в sprintf для переменной, которая в заголовочных файлах была определена как long long unsigned. Переносимость? Не, не слышали! Началась пляска вокруг патчей и ebuild’ов. Собрал. Запустил. Помучился с настройкой.
Опытным путём установлено, что при работе с mdadm raid, когда уровень raid подразумевает наличие кешей для chunk’ов (raid5 и raid6), выбор block/io для iscsi target убивает на корню все потуги по настройке производительности raid-массива. Так что с mdadm выбираем только fileio! Так работает более или менее прилично.
Кстати! Я, интереса ради, решил попробовать NBD. Таки великолепно работает. Производительно почти как с AoE. Утилизирует без малейших проблем целиком на запись массив, и упирается в 85 МБ/с на чтение. Тоже TCP, как и iSCSI. Но я, пожалуй, выберу iSCSI. Потому что NBD, это нечто среднее, между iSCSI и AoE, но про надёжность, в отличии от этих двух, ничего не известно.
И как там с продвижением в процессе?
Разложенное на картонках СХД гудит дисками, сборочная ферма формирует чистовой набор пакетов, а потом ещё и stage4 из них сформирует. Используя его, я перетащу роутер и зеркало Debian. Последнее должно ещё и стать зеркалом для всего того, что понадобится для распространения пакетов, собранных portage.
Дорогу осилит идущий!