sea

Filesystems for SSD

Для реализации уровня выше Tier 0 необходима какая-то ФС, так как все файловые системы были спроектированы без учета "физической геометрии" твердотельных накопитлей, то тут открыто большое пространство для творчества. Пока столбы забили следующие системы: F2FS от самсунга и UBIFS. Остальное такое себе.

Все SSD используют трехуровневую систему страниц (так как и в RAM контроллерах): Page, Block, Plane. Механизм трансляции этого в LBA называется FTL (Flast Translation Layer), и если файловая система не aware про эту адресацию, то вряд ли она будет эффективной. Состояния у страницы тоже интересные: при апдейте создается отдельная страница (реврайтов страниц не бывает), а старая маркируется как Stale, и когда набертся достаточное количество Stale страниц в реалоцированом блоке — они "удаляются" и помечаются как Erased. Это в принципе вся архитектура. Есть еще пяток простых мнемонических правил:

1. Всегда работать с большимы блоками (батчинг, накапливание сообщений в блобы).
2. Разделять холодные и горячие данные.
3. Много мелких запросов паралелить по ядрам
4. Дата локалити (имеет смысл в основном для ФС-писателей)
5. Разделять врайтеров и ридеров во времени

Свойство условно-хорошего слоя FS со стороны хоста зеркалировать эту FTL адресацию, поэтому в сущности UBIFS повторяет алгоритм FTL, с поправкой на требования хоста. Вопрос синхронизации буферов на концах соединения тоже интересный. Ясно что для ACHI и NVMe должны быть разные параметры у алгоритма, так как в NVMe 64K глубина очереди, а в ACHI всего 32.

А пока для режима Tier 0 я вышел на стабильные 340MB/s из теоретических 700MB/s (как говрит Андрей, коэфициент рукожопости у меня 48%), еще попробую одну идейку, а потом буду на С++ переписывать наверное. Свой ивент рекордер я переписал, убрал все OTP нахуй, сделал идиоматический эрланг, который можно теперь переписывать на другие языки. Кто хочет померятся хуйями на Node, CLR, JVM, Lua дайте знать, я тогда составлю документ "условия соревнований". Вся проблема — накопить быстро достаточно большой бинарь из миллиарда маленьких сообщений чтобы флашнуть его на диск. Код на современных языках не выходит за рамки 100-200 строк. Подойдут и фьючеры и акторы. Все языки пишут одинаково быстро через File:Write[append], так что тут проблем тоже нет.

У моего вариативного алгоритма всего два параметра: msg_size и block_size. Первый означает по сколько склеивать сообщений на клиенте еще до отправки на сервер (чтобы разгрузить копирование в языке или виртуальной машине), а второй по сколько пихать в SSD, чтобы снизить нагрузку на контроллер. Вариатор по этим двум осям ищет максимум.

_______________
[1]. http://www.linux-mtd.infradead.org/doc/ubidesign/ubidesign.pdf
[2]. https://www.usenix.org/system/files/conference/fast15/fast15-paper-lee.pdf
Buy for 10 tokens
Buy promo for minimal price.
sea

KVS STREAMS

TL;DR — Постановка задачи: выжать максимум из эрланга в плане производительности записи абстрактных сообщений (например из gen_server) на диск. Область применения: базостроение и хранение первичных транзакционных цепочек. Условия использования: много маленьких сообщений, которые нужно склеивать в буфера или накапливать, а потом быстро сбрасывать на диск.

Цифры (пропускная способность) относительно MBA 2013:

— просто raw recieve: 1M msgs/s msg_size=128
— просто raw prim_file write: 700 MB/s, msg_size=8MB/s код тут
накапливание сообщений: 231941 msgs/s msg_size=128
сброс на диск с вариативным буфером: 200 MB/s в 2 потоках msg_size=4K

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

Пока ситуация такая, что выжать максимум можно 200MB/s в двух потоках, в четырех потоках пропускная способность на поток падает, но вцелом получаются те же 200MB/s.

Пример сессии:

1> observer:start().
ok

2> writer:test(1).
whereis writer: <0.386.0>
<0.386.0>
Written writer1: rate 185 MB/s messages 6149 in 0 sec
Written writer1: rate 182 MB/s messages 45368 in 2 sec

3> writer:test(2).
whereis writer: <0.499.0>
<0.499.0>
Written writer2: rate 171 MB/s messages 6149 in 0 sec
Written writer1: rate 158 MB/s messages 44676 in 2 sec
Written writer2: rate 156 MB/s messages 42105 in 2 sec
Written writer1: rate 144 MB/s messages 38833 in 2 sec
Written writer2: rate 147 MB/s messages 38278 in 2 sec
Written writer1: rate 147 MB/s messages 35481 in 2 sec




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

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

Если кому интересно, можно почитать код тут: https://github.com/5HT/streams
Там его как всегда мало. Написано без OTP, на самопальном gen_server (как бонус). Т.е. использовалось только:

— spawn/receive/send
— gen_server:call как клиент (streams — OTP compatible)
— register/unregister/whereis

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

LUA.EFI

Я все-таки упоролся и скачал EDK2 от Intel.



Скомпилировал Lua и запустил на FAT32, к сожалению все остальные драйвера FS только в режиме Read-Only, а как писать из EFI Shell на HFS+ (встроенный драйвер эппловского EFI) пока не нашел как (если кто-то знает скажите мне).

Shell> type test.lua

s = string.rep("Q",8000000)
f = io.open("lua.bin","a")
for i=0,4000/8,1 do f:write(s) end
f:close()

Таким образом концепция Erlang.EFI очень реальная. LUA вот работает, без OS. Дальше буду пробовать всякие TCP/IP, тут столько написали всякого стаффа для EFI (Например есть еще Pyhton и какой-то WebServer, я его еще не смотрел). Вообщем это намного прикольнее чем свою OS писать. Надо только драйвер для блочной GooFS, которая в LING/Xen используется.

Все знают, что я очень впечатлительный, но по-моему EFI — годная, hackable штука, которую можно хачить под clang/gcc/cl.

P.S. Нашел пацанов у нас, которые по UEFI упарываются: http://jelezo.com.ua
И даже полезные диагностические утилиты пишут. Надо им предложить стартап: Erlang to EBC Byte Code Compiler. Ну и LING.EFI конечно же, теперь я точно уверен как надо LING паковать и запускать.
sea

N2O + PHP = ♡

TL;DR -- Теперь вы можете использовать WebSockets из PHP и других веб стеков, где есть поддержка FCGI, т.е. вы шлете запрос на сервер к N2O по WebSocket, а PHP обрабатывает запрос как полученный по ajax.

Причем использовать не просто так, а с самым быстрым Erlang веб фреймворком (который работает без gen_server, исключительно в процессах ковбоя, в отличии от PhoenixFramework и его gen_server каналов) -- N2O. Вот примеры для испльзования из PHP: https://github.com/AstRonin/sgi/tree/master/samples/fcgi-scripts

NGINX vs Cowboy+N2O+FCGI (Тестировал не я, я то знаю, что PHP сдыхает при -c 1000 или выше).

$ ab -n 20000 -c 40 http://localhost:8000/site.php
cowboy call time - 16c. without fcgi

Empty file
nginx: 13c
sgi: 18c

Non-empty file - 38 kb
nginx: 19c
sgi: 24c

$ ab -n 16000 -c 40 http://localhost:8000/site.php
cowboy call time - 11c. without fcgi

Empty file
nginx: 9c
sgi: 13c

Non-empty file - 38 kb
nginx: 14c
sgi: 24c (16с without fcgi) ~19c


Тут и vhosts и вроде даже полная имплементация FCGI. Мы думаем о PHP программистах!
Автор проекта: http://github.com/AstRonin
sea

Состояние EFI в 2016

TL;DR -- жить можна

Решил я поставить Linux на Mac. Во-первых чтобы проверить какая разница между HFS+ и BTRFS на аппенде (впринципе можно и ZFS накатить, на последние Ubuntu это делается, правда там же zfs маунт несовместимый, зато дедупликация есть, но EFI драйвера ZFS наверно не скоро появятся), а во-вторых чтобы расчистить свои завалы. А то уже жался на пятачке в несколько Гб. Скопировал все фотки, статьи и накачанные образы на домашний веник и начал читать.

Чтобы поставить Linux, можно и Bootcamp обойтись, но интересно же что нам предлагают open source решения. Их немного, из актуальных только rEFInd и Clover. Первый -- чисто EFI решение, которое может линковаться с двумя основными EFI либами: 1) GNU-EFI 2) Tianocore EDK2 от Intel. Кроме того может собираться и под Mac и под Linux. Вообщем взрослая штука, чистенькая. Clover показался карго культом, но почитав подробнее я поонял, что там больше ориентируются на совместимость с legacy машиными с BIOS и MBR. Поверьте, имея EFI вся эта хуйня уже не нужна.

GNU-EFI библиотека предлагает базовые штуки, в то время как Tianocore предлагает не только способы линковки, но и целые утилиты-расширения, такие например как EFI Shell, Memtest86 или PXE Boot. Зато GNU-EFI меньше гораздо. А шелл там все равно рагульский похожий на command.com, правда с хекс эдиторами и скриптами, без edlin или той хуйни что была в OpenFirmware. Сразу представил себе Erlang в виде UEFI шелла. Сделать можно -- продать невозможно :-)

А что, представьте себе эрланг, который работает поверх EFI. Драйвера файловых систем в refind надерганы с линукса, поэтому я попробовал поставить ubuntu на btrfs, с этим проблем нет. Сеть там тоже есть, но с другой стороны сетка то вся нам не нужна, можно сделать специализированный протокол или тот же LING-овский плановский 9p и делать связь нод EFI-эрлангов без всякого TCP/IP. Но это такое, фантазии. Да и файловые системы тоже не нужны, думаю из того, что написано под EFI, по любому есть что-то, что предоставляяет возможность как-то работать напрямую с SSD контроллером. Поэтому достаточно в эрланге иметь только это, а prim_file и prim_inet ненужны особо.

Значи, чтобы поставить EFI бутлоадер, надо загрузится в Command+R (т.е. стартануть с Apple Recovery HD, где будут находится все лоадеры всех EFI систем, еще этот раздел обычно называется ESP (EFI System Partition). Качаем бинарный дистрибутив rEFInd (можно и собрать), ставим его, он как раз в процессе инсталла копирует файлы на ESP. Потом с помощью efibootmgr или bless ставит метку что грузится нада с ESP теперь. После того как поставили rEFInd, пишем на флешку Ubuntu и грузимся с бутменю rEFInd, и выбираем Ubuntu. В ней выбираем и форматируем раздел:



Когда убунту поставится поставит флаг загрузки на свой раздел в EFI, поэтому нужно будет вернуться в Command+R и сделать Verify Macintosh HD, чтобы он поставил загрузку на себя и потом вернуться в Мак чтобы оттуда еще раз накатить rEFInd (тупо, но так вроде было с примордиальных времен, каждая ОС всегда думает, что она главная и единственная, workaround существует -- поставить rEFInd на системный Macintosh HD). Но я попробовал также собрать rEFInd под линуксом, линковался с GNU-EFI. А EFI Shell спиздил просто с бинарного дистрибутива Tianocore EDK II и положил в папку fs0:/boot/efi/EFI/tools/shellx64.efi

Вот как выглядит моя ESP FAT32 партиция.

/boot/efi
├── BOOTLOG
└── EFI
    ├── APPLE
    │   ├── CACHES
    │   ├── EXTENSIONS
    │   │   └── Firmware.scap
    │   ├── FIRMWARE
    │   │   └── MBA61_0099_B22_LOCKED.scap
    │   └── UPDATERS
    ├── refind
    │   ├── drivers_x64
    │   │   ├── btrfs_x64.efi
    │   │   ├── ext2_x64.efi
    │   │   ├── ext4_x64.efi
    │   │   ├── hfs_x64.efi
    │   │   ├── iso9660_x64.efi
    │   │   ├── LICENSE_GPL.txt
    │   │   ├── LICENSE.txt
    │   │   ├── ntfs_x64.efi
    │   │   └── reiserfs_x64.efi
    │   ├── icons
    │   ├── icons-backup
    │   ├── keys
    │   ├── refind.conf
    │   ├── refind.conf-sample
    │   ├── refind_x64.efi
    │   ├── snowy
    │   └── tools_x64
    ├── tools
    │   ├── gptsync_x64.efi
    │   └── shellx64.efi
    └── ubuntu
        ├── fw
        ├── fwupx64.efi
        ├── grub.cfg
        ├── grubx64.efi
        ├── MokManager.efi
        └── shimx64.efi


При запуске мне доступен оригинальный интеловский EFI shell, GPTsync утилита и MOK менеджер ключей. Вообщем сюда думаю можно было бы тетрис написать и Erlang. EFI шелл выглядит вот так https://software.intel.com/en-us/articles/uefi-shell, его надо обязательно в файл с окончанием "x64.efi" переименовать. Что такое Firmware Update убутновский я так и не понял fwupx64.efi, неужели эта штука может обновить любой EFI-совместимый BIOS ? Маковский она точно не может, я пробовал.

Пост написан из Ubuntu на Mac. Подумываю еще накатить Windows 10. Из того, что заметил с прошлых времен когда сидел на Ubuntu, это то, что по дефаулту раскладка клавиатуры теперь тут Command+Space.
sea

STREAMS: gen_server will be recorded, stay tuned.

Решил я все-таки написать уничтожитель SSD дисков свою библиотеку аппенд бинари логов. Одна есть неплохая в составе hanoidb, а вторая неплохая в составе rafter имплементации которая включена в cr. В мире сишечки есть eblob в организации reverbrain, которая юзается в Coub, Sputnik и других яндексах. Что хочется от этой библиотеки?

1. Максимум в два раза падение по сравнению с физической на блочном устройстве. Да, конечно хочется интеловские SSD SDK для прямого управления контроллером посекторным, но это будет работать только на линуксе.

2. Простая и понятная привязка к эрланг процессу, т.е. мы стримим все эффекты эрланг процесса. Сколько эфектов навешано на процесс, столько и цепочек. Каждая цепочка отдельный файл. Т.е. N очередей ограничено (например N=500, для сервисов кольца [vnode] ). Это не должно скейлиться на миллионы. Кстати для кольца должна быть отдельная библиотека synrc/ring (вакантное название, желательно из трех букв), которая по заданному имени и степени двойки генерирует совместимые наборы vnode в хеш-кольце и стартует для них по одному gen_server. Эти сервера тоже персистентные, как и цепочки master_node серверов. Т.е. DHT — это просто pub sub такой (пока на эрланг ремоутинге, его обещали в R20 починить и заскейлить до 100 нод лохобаны эриксоновские), где все всё пишут и могут работать в зависимости от CAP конфигурации по разных протоколах-алгоритмах. Алгоритмы эти не влияют никак на библиотеку кольца. В идеале конечно было бы на каждую vnode свой SSD диск. Также vnode могут выступать и в виде виртуальных машин которые уже держат по отдельному процессу для каждого пользователя. Но это хай-энд, незнаю или кто-то уговорит меня такое сделать. Как алоцировать vnode — это отдельный вопрос к трактовкам цепочных схем хранения. Тут тоже могут быть свои протоколы.

3. Эта библиотека должна стать системообразующей наравне с новым gen_server+streams — это как пи и сигма (одно работает, второе пишет), поэтому примитивы должны быть хорошо проработаны чтобы составить основу для EXE примитива персистентного процесса. Это персистентные видимые и индексируемые эффекты процесса. Т.е. — это как примитивная сущность виртуальной машины рассматривается, а не как прикладная библиотека. По крайней мере должно так быть.

Я собрал PoC:
>  boot:test(boot:start(1)).
flush: {{<<99,97,108,1,2,3,4,5,6,7,8,1,1,1,1,1>>},
        {ecirca,#Ref<0.0.3.168>,<<>>,<0.196.0>,medium}}
2000100 messages sent in 2s with 847824 m/s rate
Disk write performance: 170 MB/s
ok

Если склеивать сообщения таким образом (буферезировать):
append(Circ,Record) -> <<(term_to_binary(Record))/binary, Circ>> .

То процесс вообще виснет. Если склеивать с помощью листов:
append(Circ,Record) -> [term_to_binary(Record)|Circ].

То упираемся в фольклерные эрланговые 50MB/s. Но если взять библиотеку si14 ecirca:
append(Circ,Record) -> ecirca:push_list(Circ, binary_to_list(term_to_binary(Record))).

То мы уже можем достигать 250МБ/s — это половина линейной сторости моего SSD. С учетом на виртуальную машину и операционную систему (в два раза !!!!). А вы говорите зачем юникернелы.



Есть еще идея писать выровненные данные по колонкам. Но тогда без компрессии. Но зато с мнгновенными операциями get/put, так как оффсет высчитывается по номеру сообщения.

Заметьте, что хотя эрланговый процесс через себя пропускает миллион сообщений, будучи склеинные в цепочки (cons) эти сообщения могут записываться при максимальном рейте 50MB/s. Вот такой эрланговый лимит. Так что либо ecirca либо emmap. Я выбрал ecirca так как она менее системнозависима, ecirca работает только с BIF эрланговыми, а emmap с API ОС.

P.S. Писал я все это на конференции http://OSDN.org.ua, которая сегодня была. Там Влад опять рассказывал про zalora/upcast который оказывается сменили на terraform.
sea

Minimal gen_server

Подумал о том, как можно формализировать gen_server используя EXE. Правда не до конца, большой case еще не написан. Но в целом упрощено все до максимума, прототип работает с вызовами OTP-шного gen_server.

http://5ht.co/gen_server.htm
sea

Новый сезон канала HBO

В связи с тем, что последний математик в Groupoid Infinity не выдержал и сошел с ума бросив работу над проектом, я, в индуктивно-индуктивной обсессивно-компульсивной попытке спасти проект, решил привести другого математика в проект. А именно себя.

С этого момента деканат прикладной математики КПИ величает вашего покорного слугу-грфомана аспирантом (теперь я официально ебанат). В этом году сдают экзамены как на кандидатский (англ., специальность, у меня обе А, готовился чесно, ебанул 50 страниц матфизики вплоть до ядер интегральных операторов и функциональных пространств L2), ну и как всегда на ПМ только дневная форма обучения. Так как это последний год (мне 35) когда я могу поступить в аспирантуру (да да, сейчас КПИ дает PhD дипломы, а не галимого к.ф-м.н). Придется теперь срать тут и везде про рекурсоры и индукции в промышленных масштабах всея ЖЖ и на нескольких языках, чтобы до Андрея Байера слух дошел. Ну и на пары ходить, лекции читать, телочек в КПИ крутезных просто дофига, и все стартапы мутят и матан шарят. Ах Ах Ах.

С кодировками (хотябы CiC, не говоря уже про HIT и QIT) пока не понятно, что буду делать, буду делать pivot наверное. Возьму для начала ебану экстракт Lean, а потом плавно перейду к модифицированому тайпчекеру с Self типами уважаемых Пенг Фу и Аарона Стампа. Если найду хрошего категорщика может продолжу проект о суперкомпактном чистейшем как слеза PTS ядре. Времени дают 3 года.

Мне уже на кафедре посоветовали двух бодхисаттв. Первый бодхисаттва — правая рука Лямбдагарбхи — Любашенко Владимир (Институт Математики НАН Украины), а второй бодхисаттва — Лялецкий Александр (и его сын) из Института Глушкова (тот который придумал кибернетику в СССР Украине). Вот видео Любашенко из цикла лекций про Теорию Гомотопий https://www.youtube.com/watch?v=h2eU6OxHr3c Лялецкий по слухам тоже прувер пишет.

Поэтому, троли — расчехляйте ваши клавиатуры, контентом мы вас завалим сполна. Благо лямбда термы в нашей PTS действительного большого размера.
sea

ADM вебсокет дашборд

Сделали концепт админки для KVS. Графика на D3.js, CSS на flexbox. Так как не хочется тянуть N2O вместе c KVS и BPE, то оформили в виде отдельного приложения ADM, которое будет поставлятся сразу со всеми виджетами и дашбордами для продуктов Synrc.

___________
[1]. http://ns.synrc.com:8108
[2]. https://github.com/synrc/adm



Language       LOC
------------- ----
CSS            148
Javascript/D3   49
HTML            53
Erlang         144


Feedbacks are welcome. Как хотите так и будет.