LINUX.ORG.RU

Как отговорить себя от написания своей ФС

 , high performance,


1

4

Моя идея о том, чтобы переписать наш Flussonic с Erlang на Rust оказалась совершенно прекрасной и у меня совершенно прекрасные результаты. Захват 10 000 камер на сервер - это прямо скажем серьезный результат, на рынке таких предложений мало.

Однако трафик записи в 16-17 гигабит на 38 шпинделей - не предел возможности диска, это порядка 420 мегабит, а в теории шпиндель может принять и до 2 000 мегабит.

Единственная мысль, которая осталась после всех оптимизаций (выравнивание по границе блока, fadvise) - это хранение данных в одном файле в interleaved режиме, т.е. все камеры на одном диске держать в одном файле.

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

Давайте 3 причины не лезть в этот блуд.

Ответ на: комментарий от Enthusiast

Можно же в каждом ангаре поставить отдельный сервер

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

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

на шпиндель может оказаться очень много параллельных задач, от чего существующиеиФС/планировщики не очень понимают «как оптимально».

Мммм… вместо написания своей ФС напишем свой планировщик? Звучит как план. И, кстати, куда менее безумный.

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

ИМХО можно попробовать для начала вообще noop поставить. Из соображений потестить формат «нафиг планировщики, как себя ведёт банальное FIFO».

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

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

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

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

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

mkv - это бесполезный, неудобный, переусложненный и недоделанный хлам.

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

Раздельные файлы, потому что надо в один писать данные, в другой индекс. Они по размеру где-то в 10-100 тыс раз отличаются.

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

Раздельные файлы, потому что надо в один писать данные, в другой индекс. Они по размеру где-то в 10-100 тыс раз отличаются.

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

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

Индексы, очевидно, надо хранить на другом носителе, как раз там же где и данные о размещении потоков по блокам на дисках с данными. Если у тебя 38 больших дисков, то «в 10000 раз» это будет один диск в 300 раз меньшего размера.

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

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

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

Да. Называется 6G (ISAC). Вышка сотовой связи в своей зоне покрытия с частотой около 1000 кадров в секунду видит всё, что не находится под водой или в металлическом ящике, вплоть до сердцебиения у кожаных. Мало того, обработкой всей этой безумной картинки обязан заниматься ИИ в режиме реального времени (т.к. там основной прикол в направленной связи, кажется на фазированных решётках, и разделении частот, ИИ-шка должна следить за положением мобилок, чтоб гарантировать что у каждой будет полный канал и минимальные помехи). Заодно роботы будут видеть всё вокруг, даже то что ты в спальне с женой делаешь. Идеальный паноптикум и нет, это не фантастика.

anonymous
()
Ответ на: комментарий от GPFault

В идеале задачи должны быть по продолжительности на единицы мс (скажем 20МБ)

Посмотри на диск в /sys/block/sd***. Увидишь там всякие max_XYZ - вот оно и будет по сути верхним порогом выше которого нет смысла агрегировать - все равно оно поделит на такие куски.

А вообще, мы у себя по результатпм тестов в свое время пришли к выводу, что нет смысла агрегировать более чем до 512КБ. Да, иопсов получается меньше, но время каждой операции вырастает.

Если уж хочется оптимизаций для борьбы с фрагментацией - есть fallocate который позволяет разом зарезервировать сколько надо места и потом в него писать, для не-CoW файловых систем (читай для всех кроме log-based извращений, ZFS и BTRFS) - то есть для этих вот всяких ext3/4 и xfs, fallocate практически полностью решает проблему фрагментации. Добавил 16MB и пишешь, добрался до конца - еще раз рашсирил и так далее. А в конце транкейтнул до фактического размера данных и готово.

no-dashi-v2 ★★★★
()
Последнее исправление: no-dashi-v2 (всего исправлений: 1)
Ответ на: комментарий от Dimez

Ты бы всё же почитал… Если что простенький радарчик даже на ESP собирается, можешь сам проверить, всё удовольствие порядка 6-8 килорублей и доступно уже любителям. Понятно что там качество и расстояние намного ниже. А поднятие частот и мощностей до тех цифр что уже в стандарте 6G как раз даёт огромную точность с несколькими миллиметрами погрешности. Если что прототипы уже есть и всё работает, ссылки на научные статьи сам найдёшь в интернете.

anonymous
()
Ответ на: комментарий от Dimez

Таки ознакомься с официальной теорией. Я 5 лет назад общался с разработчикам 6G ИРЛ, там очень много интересного.

peregrine ★★★★★
()
Ответ на: комментарий от no-dashi-v2

Посмотри на диск в /sys/block/sd***. Увидишь там всякие max_XYZ

Посмотрел, оно одинаковое для 20+летнего HDD на 250, для 7летних SSD на 1TB, HDD на 8TB. Кажется оно не отражает реальных параметров железа

GPFault ★★★★
()
  • Markdown
Пустая строка (два раза Enter) начинает новый абзац. Знак '>' в начале абзаца выделяет абзац курсивом цитирования.
Внимание: прочитайте описание разметки Markdown.
Используйте Ctrl-Enter для размещения комментария