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 ★★★★
()
Ответ на: комментарий от max_lapshin

Если у вас «тупой» диск без поддержки Zones, в DeviceMapper есть всякие интересные модули, вроде unstriped: https://docs.kernel.org/admin-guide/device-mapper/unstriped.html

Может, вам он подойдёт? Он позволит разделить диск на несколько «дисков» по шпинделям.

Intel NVMe drives contain two cores on the physical device. Each core of the drive has segregated access to its LBA range. The current LBA model has a RAID 0 128k chunk on each core, resulting in a 256k stripe across the two cores:

Core 0:       Core 1:
__________    __________
| LBA 512|    | LBA 768|
| LBA 0  |    | LBA 256|
----------    ----------

The purpose of this unstriping is to provide better QoS in noisy neighbor environments. When two partitions are created on the aggregate drive without this unstriping, reads on one partition can affect writes on another partition. This is because the partitions are striped across the two cores. When we unstripe this hardware RAID 0 and make partitions on each new exposed device the two partitions are now physically separated.

With the dm-unstriped target we’re able to segregate an fio script that has read and write jobs that are independent of each other. Compared to when we run the test on a combined drive with partitions, we were able to get a 92% reduction in read latency using this device mapper target.

А если «умный» с поддержкой zones, то нужно их использовать.
Я с ними не знаком, но почитайте:

ValdikSS ★★★★★
()

Не думаю что это очень страшно, написать (относительно) простую fuse fs, а данные наваливать потоком в блочное устройство. Как раз wrap around по индексам блоков решит задачу перезаписи старых данных. Можно в каждом блоке держать указатель на предыдущий этого конкретного видеопотока, получится такой связный список из блоков, а потоки камер идентифицировать числовыми id. Место продолжения записи ищется бинарным поиском по всему диску, нужно найти то самое место где будет разрыв таймштампов. Если какие-то блоки побились по какой-то причине, то всё равно останутся другие блоки с неповреждённой видеозаписью, главное чтобы ключевые кадры были достаточно часто и где-нибудь в хедере блока было на него смещение.

Ну то есть в сухом остатке фактически никакой ФС нет, но логически есть N видеофайлов (возможно побитых на даты), которые через fuse можно просматривать.

neumond ★★
()

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

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

Но иногда достаточно писать в файл с direct io. Можно брокер завести, который будет потоки собирать и писать последовательно, а раз в час файл ротейтить. Я подозреваю, ты сильно выиграешь в скорости (и проиграешь в надёжности хранения, когда электричество вырубят или диск отвалится).

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

подскажи мне, пожалуйста, алгоритм, как среди потока таких шмотков найти смещение следующей группы блоков от этой камеры?

Кроме как писать рядом на SSD смещения таких фрагментов, у меня соображений нет, впрочем они итак пишутся в индекс.

Но дальше начинается следующий интересный вопрос: а как это всё стирать =)

max_lapshin ★★★★★
() автор топика

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

  1. Это дополнительная работа, потенциально бесполезная.
  2. Может понадобиться аналог fsck для проверки после сбоев. Проверка может оказаться до-о-олгой.
  3. Увеличивается объём кода, увеличивается вероятность багов.
i-rinat ★★★★★
()
Ответ на: комментарий от anonymous

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

max_lapshin ★★★★★
() автор топика

Надо просто использовать ext4 с большим размером кластера (фича bigalloc). В результате дисковое пространство будет фрагментировано по файлам не блоками по 4K, а кластерами (скажем, по 2M). А если хочется делать меньше системных вызовов (писать в несколько файлов за один визит из юзерспейса в ядро), то можно использовать io_uring.

iliyap ★★★★★
()

Поток с 10к камер, плюс пара просматривающих пользователей, плюс удаление старых записей – это многопользовательская нагрузка, т.е. случайный I/O. Механические диски медленно обрабатывают случайный I/O мелким блоком. Например, мой WD Passport (2.5", 5400 rpm, USB 3.0) показывает 700 KiB/s на random read 4K qd32 и 55 MiB/s на random read 512K qd32. Поэтому надо просто использовать большой кластер, чтобы случайный I/O шёл с крупным блоком.

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

ты его не подначивай. За неделю он точно что-нибудь наслопит, а ты можешь допрыгаться до того, что тебе ревью доверят.

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

Здесь только линейно вычитывать вперёд. Можно конечно время от времени записывать навигационные блоки с локальными индексами.

А что нужно стирать? Не проще дождаться когда само перезапишет со временем? Или нужно иногда уничтожать доказательства? :)

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