После потрясного доклада Андрея Бородина о WAL-логах в Postgres в кулуарах мы вышли на очень интересную тему - распределённая БД упирается чаще не в диски, а в сеть! При чём даже не на непосредственно трафик самих запросов, а на служебные нужды - наливка новых реплик, бекап, и даже служебная информация (GIN индекс на небольшом изменении данных может очень значительно перестроиться).

Все эти байтики нужно очень быстро и успешно передать на другой инстанс БД, находящийся в другом ДЦ (будьте готовы к латенси 5+мс). Получается, что поток изменений, передаваемый по сети, примерно совпадает с данными, которые мы будем сбрасывать на диски в WAL. И основной вывод - что оптимизироваться, оказывается, надо именно на поточную передачу по сети!

Возвращаясь с Saint Highload 2025 в сапсане мне стало интересно покрутить тему и я полез в советы Oracle как стоит тюнить ZFS для их БД. И там я наткнулся на очень интересный совет - что, дескать, ранее мы советовали выставлять recordsize (размер логического блока на ФС) равным размеру блока файлов данных БД (обычно это 8-16К), А ТЕПЕРЬ стоит выставлять его равным среднему размеру IO по сети (32К для OLTP по их мнению, 128К для OLAP)!


Вот такие интересные реалии - нужно тюнить ФС под профиль нагрузки сети. Оп-ля!

#не_очевидное

Тут из 1)многих 2)уважаемых 3)утюгов говорят про драму Bcachefs и его исключение из ядра в следующем релизе (о боги, хотят выкинуть самую прогрессивную ФС, как они посмели!), цитата от мистера Торвальдса в сторону мистера Оверстрита:

You made it very clear that I can't even question any bug-fixes and I
should just pull anything and everything.

Honestly, at that point, I don't really feel comfortable being
involved at all, and the only thing we both seemed to really
fundamentally agree on in that discussion was "we're done".

В драму играть не хочется, а вот надеть шапочку контрибьютора (не)последней ФС в этом мире OpenZFS очень даже хочется.

Преамбула:
OpenZFS в силу своей лицензии CDDL (словом, такой же опенсорсной, как и GPLv2) имеет ряд нюансов при распространении совместно с ядром, и исторически распространяется для Linux в виде отдельного модуля ядра через DKMS (поставка в виде исходного кода, сборка непосредственно при установке на конечной машине) или KMOD (бинарная поставка, но строго прибит по ABI к конкретному подрелизу ядра), вот их сравнение. И так мы живём уже минимум 10 лет (ого!).

Фабула:
Как бы не был прекрасен или ужасен Bcachefs и его автор, но искренне считаю, что для него лично, так и для его проекта это может пойти на руку:
- делай что хочешь и когда хочешь (и никакой фин не помешает!)
- свой прозрачный релизный цикл, не надо гнаться и ждать следующего релиза ядра
- клиент может спокойно сидеть на LTS ядре и иметь bleeding edge версию ФС с багофиксами любой свежести

Да, теперь твоя ФС не поставляется просто так "из коробки" в любой утюг мира, и её надо доустановить. Но разве это кого-то останавливало от захвата мира? :)

PS: и как бы не звучал страшно DKMS - сборка на конечной машине работает годами и очень стабильно, юзай любое совместимое ядро и не горюй.

PPS: в комментариях @nbykov приложил must-have к прочтению ссылку на открытое письмо Ганса Райзера (того самого автора ReiserFS), качайте софты, коллеги, мы живём в социуме.

#скандалы_интриги_расследования

Этим дождливым летом в default-city продолжаем инфровые митапы, приходите, увидимся!

Привет! VK Tech приглашает на DarkSideoftheCloud, специальный выпуск InfraDev Meetup про «теневую» сетевую сторону облачных сервисов.

Поговорим про то, где сети лежат в архитектуре BareMetal as a Service, какие технологии выбрать для виртуальной частной сети и как справиться с непростой задачей масштабирования межсетевых экранов.

Спикеры:
🕸Кирилл Фролов, эксперт в команде разработки платформы, VK Cloud, VK Tech.
🕸Влад Одинцов, Tech Lead и Product Owner сетевых сервисов, K2 Cloud.
🕸Юрий Дышлевой, инженер, Positive Technologies.
Подробнее о докладах читайте на странице мероприятия.

Когда: 16 июля, с 18:00 до 23:59
Где: Москва, Ленинградский 39, БЦ Skylight, офис VK

Приходите на встречу или участвуйте онлайн.
Зарегистрироваться.

Самый классный вариант что-то мерить - через физику.
Производительность одного потока можно свести к измерению задержек!

Собрал для вас пирамидку средних задержек с флёром облаков:

L1 cache                                    0.5ns
Branch mispredict                           5  ns
L2 cache                                    7  ns 
Mutex lock/unlock                          25  ns
RAM                                       100  ns
Send 1K over 1 Gbps net                10,000  ns 
Read 4K randomly from local fast NVME  20,000  ns
Read 4K randomly from local NVME (VM)  60,000  ns
Read 4K randomly from local SSD       150,000  ns 
Read 1 MB sequentially from RAM       250,000  ns
Read 4K randomly from network NVME    500,000  ns 
Round trip within same datacenter     500,000  ns 
Read 1 MB sequentially from SSD     1,000,000  ns 
HDD seek                           10,000,000  ns
S3 response for 4k object   up to 100,000,000  ns
Send packet CA->Netherlands->CA   150,000,000  ns 

1 second                        1,000,000,000  ns

Против физики не попрёшь!
#занимательное

Интересный кейс подъехал: есть полезный сисколл copy_file_range, и если файловая система позволила принять через него запрос на копирование байтов больше, чем помещается в 32-битное число, то всё остальное будет забито нулями.

Если бы я хотел написать кликбейтный заголовок, то он бы выглядел так: "ZFS опять бьёт данные! Ну что за ненадёжная ФС!"

Вот только это баг в glibc, а ZFS (чуть ли не) единственная позволяет разом скопировать через данный сисколл сильно больше. К слову, фикс уже летит.

Будьте дети аккуратны с жирными операциями больше 32 бит.

Señoras y señores, переворачиваем календарь!

В эту субботу 13 сентября будет бесплатная онлайн-конференция Highload++ Genesis о фундаментальных вещах для нашей сферы: базы, не-базы, сети, ml, облака, контейнеры, нагрузки.

На ней буду "великолепно капитанить" про облака. Регистрируйтесь, услышимся!

#conference

Объявлена неделя многоядерности Multi-kernels, не только лишь один один патч, но целых два были опубликованы на LKML.

Идея интересна - давайте на отдельных ядрах процессора запускать честные копии (может даже разных версий) ядер ОС, каждому отсыпать индивидуально куски памяти, и, в идеальной картине мира, также нарезать и другое железо (сети, диски, GPU, словом - всё что висит на PCIe шине).

Всё это подаётся в основном как замена виртуализации, ожидая минимизацию накладных расходов. НО - кто же будет отвечать за общие компоненты? Да тот же сторадж, локальные файловые системы требуют монопольный доступ. В сетях вроде есть sr-iov, но с ним тоже теряется определённая гибкость. Вообще вырисовывается интересный нюанс - должно быть более главное главное ядро, которое за такие вещи должно отвечать. Тут лично у меня вопрос - а чем общение между ядрами будут отличаться по эффективности от virtio + vhost(-user) у VMок, которые уже по максимуму стараются передавать данные без копирования?

В LKML оставили ещё один очень интересный комментарий на эту тему: Pasha Tatashin когда то уже экспериментировал с этим подходом (уже третий вариант в рамках этого поста 😄 ), и отмечает проблемы:

While this approach was easy to get to the experimental PoC, it has
some fundamental problems that I am not sure can be solved in the long
run, such as handling global machine states like interrupts. I think
the Orphaned VM approach (i.e., keeping VCPUs running through the Live
Update procedure) is more reliable and likely to succeed for
zero-downtime kernel updates.

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

Мне тут стало скучно, и я решил купить самый дешёвый 4ТБ nvme с озона по цене HDD. Наверное, вы уже догадываетесь про что будет пост :)

Начиналось всё не плохо, диск до сих пор виден в системе, отвечает уверенно (смарт в конце поста). Нашёл утилиту f3 , быстрый f3probe даже сказал что всё ок. f3write, оказалось, хочет писать файлы поверх ФС (он генерит сиквенс файлами по 1ГБ, которые потом должен провалидировать f3read). Сначала я подумал отформатировать диск с ext4/xfs, всё равно разово, а потом решил не изменять себе и бахнул ZFS.

За ночь (часов 10) nvme смог принять всего 160ГБ данных (скорее всего итоговый объём около 240ГБ, т.к. я успел один раз перезапустить запись после 60+ГБ), первые 50ГБ влетели на скорости 1ГиБ/сек, а вот на утро я увидел скорость записи в 2МиБ/сек и моргающий красный светодиод на самом nvme... В целом судьба диска к этому моменту стала понятна, я пошёл оформлять возврат.

Параллельно запустил zpool scrub, и тут меня ZFS в очередной раз обрадовал:

root@ubuntu:~# zpool status
  pool: testpool
 state: ONLINE
status: One or more devices has experienced an error resulting in data
        corruption.  Applications may be affected.
action: Restore the file in question if possible.  Otherwise restore the
        entire pool from backup.
   see: https://openzfs.github.io/openzfs-docs/msg/ZFS-8000-8A
  scan: scrub in progress since Fri Sep 26 08:08:22 2025
        163G / 163G scanned, 145G / 163G issued at 16.0M/s
        0B repaired, 89.32% done, 00:18:32 to go
config:

        NAME        STATE     READ WRITE CKSUM
        testpool    ONLINE       0     0     0
          nvme0n1   ONLINE       0     0 54.6K

errors: 27754 data errors, use '-v' for a list

Родимые чексуммы заорали о проблемах, и это скраб ещё не кончился!

Диск представляется как Non-Volatile memory controller: Realtek Semiconductor Co., Ltd. RTS5765DL NVMe SSD Controller (DRAM-less) (rev 01).
Интересные моменты из smartctl для интересующихся уже после тестов, диск считает себя живым (но верить ему, конечно, не стоит):

=== START OF INFORMATION SECTION ===
Model Number: SSD 4TB
Serial Number: 000166
Firmware Version: VC2S038D
PCI Vendor/Subsystem ID: 0x10ec
IEEE OUI Identifier: 0x00e04c
Controller ID: 1
NVMe Version: 1.4
Number of Namespaces: 1
Namespace 1 Size/Capacity: 4,000,787,030,016 [4.00 TB]
Namespace 1 Formatted LBA Size: 512
Namespace 1 IEEE EUI-64: 00e04c 11be335053
...
Supported Power States
St Op Max Active Idle RL RT WL WT Ent_Lat Ex_Lat
0 + 8.00W - - 0 0 0 0 0 0
1 + 4.00W - - 1 1 1 1 0 0
2 + 3.00W - - 2 2 2 2 0 0
3 - 0.0300W - - 3 3 3 3 5000 10000
4 - 0.0050W - - 4 4 4 4 54000 45000

Supported LBA Sizes (NSID 0x1)
Id Fmt Data Metadt Rel_Perf
0 + 512 0 0

=== START OF SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED

SMART/Health Information (NVMe Log 0x02)
Critical Warning: 0x00
Temperature: 40 Celsius
Available Spare: 100%
Available Spare Threshold: 32%
Percentage Used: 0%
Data Units Read: 70,047 [35.8 GB]
Data Units Written: 695,379 [356 GB]
Host Read Commands: 283,235
Host Write Commands: 4,106,990
Controller Busy Time: 0
Power Cycles: 3
Power On Hours: 11
Unsafe Shutdowns: 2
Media and Data Integrity Errors: 0
Error Information Log Entries: 0
Warning Comp. Temperature Time: 0
Critical Comp. Temperature Time: 0

Error Information (NVMe Log 0x01, 8 of 8 entries)
No Errors Logged

Read Self-test Log failed: Invalid Field in Command (0x002)

#баловство #storage

ЦОДы цодами, а в комментах к посту правильно зарубились - сгореть/получить метеорит в лоб может любой ЦОД, что "офисный", что промышленный. Нужны минимум бекапы/async кластеры растянутые меж-ЦОД, но вкуснее смотрятся геораспределённые хранилища (БД/S3).

В общем, очередной срач про "а вы уже делаете бекапы?" вам в ленту.

Про пожар в южнокорейском NIRS (Национальной службе информационных ресурсов) думаю все уже прочитали.
Классика: литий-ионные батареи, пожар, бэкапы в соседней серверной, "что могло пойти не так".

Но самое забавное в другом. Не далее как на прошлой неделе на #dcsummit уважаемый "независимый эксперт" ругал коммерческие ЦОДы за дороговизну. Мол, есть у него одна знакомая компания, которая у себя в офисе "поставила в серверной два бытовых кондиционера, четыре стойки и ИБП - и таких заказчиков будет больше, потому что кое кто зажрался" (с).

Как вы думаете, где будет лучше организована система пожаротушения - в серверной в БЦ или в хорошем коммерческом ЦОДе? А пожарную экспертизу этот БЦ когда последний раз проходил? А что там с огнестойкостью материалов стен и перекрытий?
ЦОДы, конечно, тоже разные бывают, но с пожбезом там всё-таки дела обычно получше, да и гермозоны не зря придумали.

Храните деньги в сберегательной кассе (если, конечно же, они у вас есть), серверы с важными данными - в ЦОДе, а бэкапы - отдельно от прода!

@snakeslair #thereisnoclouds

Увидел в чате уважаемого человека пост про OpenZL, и не смог пройти мимо, т.к. понеслось - уже в ZFS начали его просить :)

Да, это ещё один компрессор, но с нюансом. Yann Collet там тоже отметился, так что давайте и сравним новинку с его произведениями искусства:
- LZ4 - максимально быстро, всё в угоду скорости, даже несжимаемое предпочитает по эвристике пропустить и не пытаться пожать (итого скорость ~memcpy на несжимаемом)*
- ZSTD - очень гибкий, быстрее gzip, эффективнее gzip, на малых режимах сжатия наследует многое от LZ4*. Одна из фишек - сжатие по словарю - т.е. если ваши данные ну очень типовые - составляете словарь наиболее частых вхождений и получаете легко коэффициент х20. Нюанс - словарь надо таскать с собой, что сильно уменьшает удобство.
- новинка OpenZL - читерит и требует знания про ваши структуры данных, но зато может дать огромный выигрыш. Проще всего объяснить на их же примере и вспомнить почему time-series DB умеют ну очень эффективно хранить последовательности: если вы храните упорядоченные числа, то эффективнее всего хранить их... дельту! Ключевое отличие от словарей - что для разжатия вам не нужны дополнительные артефакты.

Новое слово для сжатия известных структур/метаданных?

* на самом деле, грань между LZ4 и ZSTD сильно размылась, у каждого уже есть разные режимы, позволяющие сильно превратить одно в другое

Уважаемый человек побудил меня потратить всё время в сапсане на чтение paper'а об openZL, и я прямо насладился!

Идея - огонь:
- SDDL (язык для описания структуры данных) для парсинга на первом этапе, потом transform (промежуточный кодек), потом графы и итоговые кодеки в них.
- Кодеком может являться любая функция которая что-то сделает с данными (тот же zstd). Элемент графа - тоже кодек, но умеющий построить связь с другими кодеками передающий данные как есть.
- Работаем не с байтами, а со структурированными данными. При чём in-out стримов много! Полезный бонус - данные перед сжатием теперь можно не сериализовывать, а как есть отдать на соответствующий кодек для сжатия.
- Упор на практичность, универсальный декодер (главное чтоб имел нужные кодеки). И это гипер важно - основная проблема сделать новый алгоритм компрессии - в распространении его декомпрессора. OpenZL позволит делать максимально эффективные кодеки, используя один и тот же декодер!

Для меня возможность эффективнее сжать в данном случае выглядит скорее как бонус, а не основная фишка openzl. По сути это новый фреймворк для сжатия, киллер-фича - универсальный декодер без словарей.

Для простоты разберём пример:

csv "ФИО,рост,вес"
- парсим и выделяем каждый столбец отдельно
- теперь, например, столбец "рост" можно преобразовать из ascii/utf в int, может даже - отсортировать, если отсортировали - писать дельту а не значение, и всё это подать в специализированный кодек field_lz
- поле "ФИО" проще воспринимать как текст, тут можно использовать базовый zstd (для примера)
- итог - граф операций над данными, для декомпрессии его надо просто проиграть в обратную сторону (т.е. в итоговом артефакте есть информация о порядке декомпрессии известными декомпрессору кодеками)

А как вы упарываетесь в пути?

Кстати, тут python 3.14 релизнулся, все носятся с перформансом и тредами. Это конечно классно, но в среднем для вас разница будет на уровне погрешности.

Лично я очень ждал (и наконец - дождался):
- zstd из коробки. Король компрессоров in da house
- uuidv7 из коробки. Теперь индексы по uuid будут последовательны и эффективны, особенно это оценит mysql и подобные с gap lock на primary key

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

Уже нащупаны интересные корреляции:
– между скоростью пайплайнов и качеством code review,
– между алертингом и стабильностью релизов,
– между ролями в команде и удовлетворённостью релизным процессом.

Но нужно больше данных, чтобы отделить закономерности от шума.

Пройти анкету можно за 10 минут. Её же можно использовать как мини-чек-лист для самооценки зрелости инженерной культуры.

Принять участие: https://forms.gle/NszR7VDuXL9sBbVAA

Результаты обязательно расскажу, коллеги поделятся.


Чем быстрее CI/CD - чем больше рисков "тестирования на проде"?

Minio "is a source only distribution now, if you want to build containers you need to build them yourselves".

Как выстрелить себе в ногу и не подать виду? Очередная история как опенсорсный проект превращается в проприетарный. А начинали они с вырезания функционала из опенсорса...

#unsource

В этот раз делать отдельный обзор на аварию даже как-то неудобно, DNS всё же :)

Вообще как корректно DNSу ответить именно в случае проблем - это больно, т.к. краткий ответ - ответить кровь из носу, но надо, иначе у всех кеш о записи протухнет и умрёт. Вот и получается, что для самых критичных вещей будь добр имей статичные записи с хорошим таким TTL.

А будущее всё также за cloud-agnostic (да-да, on-prem это тоже облако нынче) и #NoOps .