Add documentation

2022-01-29 23:43:22 +03:00 · 2022-01-29 23:43:22 +03:00 · 5d47bbe04c
parent 93a9f1ef89
commit 5d47bbe04c
74 changed files with 5012 additions and 1296 deletions
--- a/README-ru.md
+++ b/README-ru.md
@ -4,674 +4,68 @@

 ## Идея

-Я всего лишь хочу сделать качественную блочную SDS!
+Вернём былую скорость кластерному блочному хранилищу!

-Vitastor - распределённая блочная SDS, прямой аналог Ceph RBD и внутренних СХД популярных
-облачных провайдеров. Однако, в отличие от них, Vitastor быстрый и при этом простой.
-Только пока маленький :-).
+Vitastor - распределённая блочная SDS (программная СХД), прямой аналог Ceph RBD и
+внутренних СХД популярных облачных провайдеров. Однако, в отличие от них, Vitastor
+быстрый и при этом простой. Только пока маленький :-).

-Архитектурная схожесть с Ceph означает заложенную на уровне алгоритмов записи строгую консистентность,
+Vitastor архитектурно похож на Ceph, что означает атомарность и строгую консистентность,
 репликацию через первичный OSD, симметричную кластеризацию без единой точки отказа
 и автоматическое распределение данных по любому числу дисков любого размера с настраиваемыми схемами
 избыточности - репликацией или с произвольными кодами коррекции ошибок.

-## Возможности
-
-Vitastor на данный момент находится в статусе предварительного выпуска, расширенные
-возможности пока отсутствуют, а в будущих версиях вероятны "ломающие" изменения.
-
-Однако следующее уже реализовано:
-
- Базовая часть - надёжное кластерное блочное хранилище без единой точки отказа
- Производительность ;-D
- Несколько схем отказоустойчивости: репликация, XOR n+1 (1 диск чётности), коды коррекции ошибок
-  Рида-Соломона на основе библиотеки jerasure с любым числом дисков данных и чётности в группе
- Конфигурация через простые человекочитаемые JSON-структуры в etcd
- Автоматическое распределение данных по OSD, с поддержкой:
-  - Математической оптимизации для лучшей равномерности распределения и минимизации перемещений данных
-  - Нескольких пулов с разными схемами избыточности
-  - Дерева распределения, выбора OSD по тегам / классам устройств (только SSD, только HDD) и по поддереву
-  - Настраиваемых доменов отказа (диск/сервер/стойка и т.п.)
- Восстановление деградированных блоков
- Ребаланс, то есть перемещение данных между OSD (дисками)
- Поддержка "ленивого" fsync (fsync не на каждую операцию)
- Сбор статистики ввода/вывода в etcd
- Клиентская библиотека режима пользователя для ввода/вывода
- Драйвер диска для QEMU (собирается вне дерева исходников QEMU)
- Драйвер диска для утилиты тестирования производительности fio (также собирается вне дерева исходников fio)
- NBD-прокси для монтирования образов ядром ("блочное устройство в режиме пользователя")
- Утилита для удаления образов/инодов (vitastor-cli rm-data)
- Пакеты для Debian и CentOS
- Статистика операций ввода/вывода и занятого места в разрезе инодов
- Именование инодов через хранение их метаданных в etcd
- Снапшоты и copy-on-write клоны
- Сглаживание производительности случайной записи в SSD+HDD конфигурациях
- Поддержка RDMA/RoCEv2 через libibverbs
- CSI-плагин для Kubernetes
- Базовая поддержка OpenStack: драйвер Cinder, патчи для Nova и libvirt
- Слияние снапшотов (vitastor-cli {snap-rm,flatten,merge})
- Консольный интерфейс для управления образами (vitastor-cli {ls,create,modify})
- Плагин для Proxmox
- Упрощённая NFS-прокси для эмуляции файлового доступа к образам (подходит для VMWare)
-
-## Планы развития
-
- Более корректные скрипты разметки дисков и автоматического запуска OSD
- Другие инструменты администрирования
- Плагины для OpenNebula и других облачных систем
- iSCSI-прокси
- Более быстрое переключение при отказах
- Фоновая проверка целостности без контрольных сумм (сверка реплик)
- Контрольные суммы
- Поддержка SSD-кэширования (tiered storage)
- Поддержка NVDIMM
- Web-интерфейс
- Возможно, сжатие
- Возможно, поддержка кэширования данных через системный page cache
-
-## Архитектура
-
-Так же, как и в Ceph, в Vitastor:
-
- Есть пулы (pools), PG, OSD, мониторы, домены отказа, дерево распределения (аналог crush-дерева).
- Образы делятся на блоки фиксированного размера (объекты), и эти объекты распределяются по OSD.
- У OSD есть журнал и метаданные и они тоже могут размещаться на отдельных быстрых дисках.
- Все операции записи тоже транзакционны. В Vitastor, правда, есть режим отложенного/ленивого fsync
-  (коммита), в котором fsync не вызывается на каждую операцию записи, что делает его более
-  пригодным для использования на "плохих" (десктопных) SSD. Однако все операции записи
-  в любом случае атомарны.
- Клиентская библиотека тоже старается ждать восстановления после любого отказа кластера, то есть,
-  вы тоже можете перезагрузить хоть весь кластер разом, и клиенты только на время зависнут,
-  но не отключатся.
-
-Некоторые базовые термины для тех, кто не знаком с Ceph:
-
- OSD (Object Storage Daemon) - процесс, который хранит данные на одном диске и обрабатывает
-  запросы чтения/записи от клиентов.
- Пул (Pool) - контейнер для данных, имеющих одну и ту же схему избыточности и правила распределения по OSD.
- PG (Placement Group) - группа объектов, хранимых на одном и том же наборе реплик (OSD).
-  Несколько PG могут храниться на одном и том же наборе реплик, но объекты одной PG
-  в норме не хранятся на разных наборах OSD.
- Монитор - демон, хранящий состояние кластера.
- Домен отказа (Failure Domain) - группа OSD, которым вы разрешаете "упасть" всем вместе.
-  Иными словами, это группа OSD, в которые СХД не помещает разные копии одного и того же
-  блока данных. Например, если домен отказа - сервер, то на двух дисках одного сервера
-  никогда не окажется 2 и более копий одного и того же блока данных, а значит, даже
-  если в этом сервере откажут все диски, это будет равносильно потере только 1 копии
-  любого блока данных.
- Дерево распределения (Placement Tree / CRUSH Tree) - иерархическая группировка OSD
-  в узлы, которые далее можно использовать как домены отказа. То есть, диск (OSD) входит в
-  сервер, сервер входит в стойку, стойка входит в ряд, ряд в датацентр и т.п.
-
-Чем Vitastor отличается от Ceph:
-
- Vitastor в первую очередь сфокусирован на SSD. Также Vitastor, вероятно, должен неплохо работать
-  с комбинацией SSD и HDD через bcache, а в будущем, возможно, будут добавлены и нативные способы
-  оптимизации под SSD+HDD. Однако хранилище на основе одних лишь жёстких дисков, вообще без SSD,
-  не в приоритете, поэтому оптимизации под этот кейс могут вообще не состояться.
- OSD Vitastor однопоточный и всегда таким останется, так как это самый оптимальный способ работы.
-  Если вам не хватает 1 ядра на 1 диск, просто делите диск на разделы и запускайте на нём несколько OSD.
-  Но, скорее всего, вам хватит и 1 ядра - Vitastor не так прожорлив к ресурсам CPU, как Ceph.
- Журнал и метаданные всегда размещаются в памяти, благодаря чему никогда не тратится лишнее время
-  на чтение метаданных с диска. Размер метаданных линейно зависит от размера диска и блока данных,
-  который задаётся в конфигурации кластера и по умолчанию составляет 128 КБ. С блоком 128 КБ метаданные
-  занимают примерно 512 МБ памяти на 1 ТБ дискового пространства (и это всё равно меньше, чем нужно Ceph-у).
-  Журнал вообще не должен быть большим, например, тесты производительности в данном документе проводились
-  с журналом размером всего 16 МБ. Большой журнал, вероятно, даже вреден, т.к. "грязные" записи (записи,
-  не сброшенные из журнала) тоже занимают память и могут немного замедлять работу.
- В Vitastor нет внутреннего copy-on-write. Я считаю, что реализация CoW-хранилища гораздо сложнее,
-  поэтому сложнее добиться устойчиво хороших результатов. Возможно, в один прекрасный день
-  я придумаю красивый алгоритм для CoW-хранилища, но пока нет - внутреннего CoW в Vitastor не будет.
-  Всё это не относится к "внешнему" CoW (снапшотам и клонам).
- Базовый слой Vitastor - простое блочное хранилище с блоками фиксированного размера, а не сложное
-  объектное хранилище с расширенными возможностями, как в Ceph (RADOS).
- В Vitastor есть режим "ленивых fsync", в котором OSD группирует запросы записи перед сбросом их
-  на диск, что позволяет получить лучшую производительность с дешёвыми настольными SSD без конденсаторов
-  ("Advanced Power Loss Protection" / "Capacitor-Based Power Loss Protection").
-  Тем не менее, такой режим всё равно медленнее использования нормальных серверных SSD и мгновенного
-  fsync, так как приводит к дополнительным операциям передачи данных по сети, поэтому рекомендуется
-  всё-таки использовать хорошие серверные диски, тем более, стоят они почти так же, как десктопные.
- PG эфемерны. Это означает, что они не хранятся на дисках и существуют только в памяти работающих OSD.
- Процессы восстановления оперируют отдельными объектами, а не целыми PG.
- PGLOG-ов нет.
- "Мониторы" не хранят данные. Конфигурация и состояние кластера хранятся в etcd в простых человекочитаемых
-  JSON-структурах. Мониторы Vitastor только следят за состоянием кластера и управляют перемещением данных.
-  В этом смысле монитор Vitastor не является критичным компонентом системы и больше похож на Ceph-овский
-  менеджер (MGR). Монитор Vitastor написан на node.js.
- Распределение PG не основано на консистентных хешах. Вместо этого все маппинги PG хранятся прямо в etcd
-  (ибо нет никакой проблемы сохранить несколько сотен-тысяч записей в памяти, а не считать каждый раз хеши).
-  Перераспределение PG по OSD выполняется через математическую оптимизацию,
-  а конкретно, сведение задачи к ЛП (задаче линейного программирования) и решение оной с помощью утилиты
-  lp_solve. Такой подход позволяет обычно выравнивать распределение места почти идеально - равномерность
-  обычно составляет 96-99%, в отличие от Ceph, где на голом CRUSH-е без балансировщика обычно выходит 80-90%.
-  Также это позволяет минимизировать объём перемещения данных и случайность связей между OSD, а также менять
-  распределение вручную, не боясь сломать логику перебалансировки. В таком подходе есть и потенциальный
-  недостаток - есть предположение, что в очень большом кластере он может сломаться - однако вплоть до
-  нескольких сотен OSD подход точно работает нормально. Ну и, собственно, при необходимости легко
-  реализовать и консистентные хеши.
- Отдельный слой, подобный слою "CRUSH-правил", отсутствует. Вы настраиваете схемы отказоустойчивости,
-  домены отказа и правила выбора OSD напрямую в конфигурации пулов.
-
-## Понимание сути производительности систем хранения
-
-Вкратце: для быстрой хранилки задержки важнее, чем пиковые iops-ы.
-
-Лучшая возможная задержка достигается при тестировании в 1 поток с глубиной очереди 1,
-что приблизительно означает минимально нагруженное состояние кластера. В данном случае
-IOPS = 1/задержка. Ни числом серверов, ни дисков, ни серверных процессов/потоков
-задержка не масштабируется... Она зависит только от того, насколько быстро один
-серверный процесс (и клиент) обрабатывают одну операцию.
-
-Почему задержки важны? Потому, что некоторые приложения *не могут* использовать глубину
-очереди больше 1, ибо их задача не параллелизуется. Важный пример - это все СУБД
-с поддержкой консистентности (ACID), потому что все они обеспечивают её через
-журналирование, а журналы пишутся последовательно и с fsync() после каждой операции.
-
-fsync, кстати - это ещё одна очень важная вещь, про которую почти всегда забывают в тестах.
-Смысл в том, что все современные диски имеют кэши/буферы записи и не гарантируют, что
-данные реально физически записываются на носитель до того, как вы делаете fsync(),
-который транслируется в команду сброса кэша операционной системой.
-
-Дешёвые SSD для настольных ПК и ноутбуков очень быстрые без fsync - NVMe диски, например,
-могут обработать порядка 80000 операций записи в секунду с глубиной очереди 1 без fsync.
-Однако с fsync, когда они реально вынуждены писать каждый блок данных во флеш-память,
-они выжимают лишь 1000-2000 операций записи в секунду (число практически постоянное
-для всех моделей SSD).
-
-Серверные SSD часто имеют суперконденсаторы, работающие как встроенный источник
-бесперебойного питания и дающие дискам успеть сбросить их DRAM-кэш в постоянную
-флеш-память при отключении питания. Благодаря этому диски с чистой совестью
-*игнорируют fsync*, так как точно знают, что данные из кэша доедут до постоянной
-памяти.
-
-Все наиболее известные программные СХД, например, Ceph и внутренние СХД, используемые
-такими облачными провайдерами, как Amazon, Google, Яндекс, медленные в смысле задержки.
-В лучшем случае они дают задержки от 0.3мс на чтение и 0.6мс на запись 4 КБ блоками
-даже при условии использования наилучшего возможного железа.
-
-И это в эпоху SSD, когда вы можете пойти на рынок и купить там SSD, задержка которого
-на чтение будет 0.1мс, а на запись - 0.04мс, за 100$ или даже дешевле.
-
-Когда мне нужно быстро протестировать производительность дисковой подсистемы, я
-использую следующие 6 команд, с небольшими вариациями:
-
- Линейная запись:
-  `fio -ioengine=libaio -direct=1 -invalidate=1 -name=test -bs=4M -iodepth=32 -rw=write -runtime=60 -filename=/dev/sdX`
- Линейное чтение:
-  `fio -ioengine=libaio -direct=1 -invalidate=1 -name=test -bs=4M -iodepth=32 -rw=read -runtime=60 -filename=/dev/sdX`
- Запись в 1 поток (T1Q1):
-  `fio -ioengine=libaio -direct=1 -invalidate=1 -name=test -bs=4k -iodepth=1 -fsync=1 -rw=randwrite -runtime=60 -filename=/dev/sdX`
- Чтение в 1 поток (T1Q1):
-  `fio -ioengine=libaio -direct=1 -invalidate=1 -name=test -bs=4k -iodepth=1 -rw=randread -runtime=60 -filename=/dev/sdX`
- Параллельная запись (numjobs используется, когда 1 ядро CPU не может насытить диск):
-  `fio -ioengine=libaio -direct=1 -invalidate=1 -name=test -bs=4k -iodepth=128 [-numjobs=4 -group_reporting] -rw=randwrite -runtime=60 -filename=/dev/sdX`
- Параллельное чтение (numjobs - аналогично):
-  `fio -ioengine=libaio -direct=1 -invalidate=1 -name=test -bs=4k -iodepth=128 [-numjobs=4 -group_reporting] -rw=randread -runtime=60 -filename=/dev/sdX`
-
-## Теоретическая максимальная производительность Vitastor
-
-При использовании репликации:
- Задержка чтения в 1 поток (T1Q1): 1 сетевой RTT + 1 чтение с диска.
- Запись+fsync в 1 поток:
-  - С мгновенным сбросом: 2 RTT + 1 запись.
-  - С отложенным ("ленивым") сбросом: 4 RTT + 1 запись + 1 fsync.
- Параллельное чтение: сумма IOPS всех дисков либо производительность сети, если в сеть упрётся раньше.
- Параллельная запись: сумма IOPS всех дисков / число реплик / WA либо производительность сети, если в сеть упрётся раньше.
-
-При использовании кодов коррекции ошибок (EC):
- Задержка чтения в 1 поток (T1Q1): 1.5 RTT + 1 чтение.
- Запись+fsync в 1 поток:
-  - С мгновенным сбросом: 3.5 RTT + 1 чтение + 2 записи.
-  - С отложенным ("ленивым") сбросом: 5.5 RTT + 1 чтение + 2 записи + 2 fsync.
- Под 0.5 на самом деле подразумевается (k-1)/k, где k - число дисков данных,
-  что означает, что дополнительное обращение по сети не нужно, когда операция
-  чтения обслуживается локально.
- Параллельное чтение: сумма IOPS всех дисков либо производительность сети, если в сеть упрётся раньше.
- Параллельная запись: сумма IOPS всех дисков / общее число дисков данных и чётности / WA либо производительность сети, если в сеть упрётся раньше.
-  Примечание: IOPS дисков в данном случае надо брать в смешанном режиме чтения/записи в пропорции, аналогичной формулам выше.
-
-WA (мультипликатор записи) для 4 КБ блоков в Vitastor обычно составляет 3-5:
-1. Запись метаданных в журнал
-2. Запись блока данных в журнал
-3. Запись метаданных в БД
-4. Ещё одна запись метаданных в журнал при использовании EC
-5. Запись блока данных на диск данных
-
-Если вы найдёте SSD, хорошо работающий с 512-байтными блоками данных (Optane?),
-то 1, 3 и 4 можно снизить до 512 байт (1/8 от размера данных) и получить WA всего 2.375.
-
-Кроме того, WA снижается при использовании отложенного/ленивого сброса при параллельной
-нагрузке, т.к. блоки журнала записываются на диск только когда они заполняются или явным
-образом запрашивается fsync.
-
-## Пример сравнения с Ceph
-
-Железо - 4 сервера, в каждом:
- 6x SATA SSD Intel D3-4510 3.84 TB
- 2x Xeon Gold 6242 (16 cores @ 2.8 GHz)
- 384 GB RAM
- 1x 25 GbE сетевая карта (Mellanox ConnectX-4 LX), подключённая к свитчу Juniper QFX5200
-
-Экономия энергии CPU отключена. В тестах и Vitastor, и Ceph развёрнуто по 2 OSD на 1 SSD.
-
-Все результаты ниже относятся к случайной нагрузке 4 КБ блоками (если явно не указано обратное).
-
-Производительность голых дисков:
- T1Q1 запись ~27000 iops (задержка ~0.037ms)
- T1Q1 чтение ~9800 iops (задержка ~0.101ms)
- T1Q32 запись ~60000 iops
- T1Q32 чтение ~81700 iops
-
-Ceph 15.2.4 (Bluestore):
- T1Q1 запись ~1000 iops (задержка ~1ms)
- T1Q1 чтение ~1750 iops (задержка ~0.57ms)
- T8Q64 запись ~100000 iops, потребление CPU процессами OSD около 40 ядер на каждом сервере
- T8Q64 чтение ~480000 iops, потребление CPU процессами OSD около 40 ядер на каждом сервере
-
-Тесты в 8 потоков проводились на 8 400GB RBD образах со всех хостов (с каждого хоста запускалось 2 процесса fio).
-Это нужно потому, что в Ceph несколько RBD-клиентов, пишущих в 1 образ, очень сильно замедляются.
-
-Настройки RocksDB и Bluestore в Ceph не менялись, единственным изменением было отключение cephx_sign_messages.
-
-На самом деле, результаты теста не такие уж и плохие для Ceph (могло быть хуже).
-Собственно говоря, эти серверы как раз хорошо сбалансированы для Ceph - 6 SATA SSD как раз
-утилизируют 25-гигабитную сеть, а без 2 мощных процессоров Ceph-у бы не хватило ядер,
-чтобы выдать пристойный результат. Собственно, что и показывает жор 40 ядер в процессе
-параллельного теста.
-
-Vitastor:
- T1Q1 запись: 7087 iops (задержка 0.14ms)
- T1Q1 чтение: 6838 iops (задержка 0.145ms)
- T2Q64 запись: 162000 iops, потребление CPU - 3 ядра на каждом сервере
- T8Q64 чтение: 895000 iops, потребление CPU - 4 ядра на каждом сервере
- Линейная запись (4M T1Q32): 2800 МБ/с
- Линейное чтение (4M T1Q32): 1500 МБ/с
-
-Тест на чтение в 8 потоков проводился на 1 большом образе (3.2 ТБ) со всех хостов (опять же, по 2 fio с каждого).
-В Vitastor никакой разницы между 1 образом и 8-ю нет. Естественно, примерно 1/4 запросов чтения
-в такой конфигурации, как и в тестах Ceph выше, обслуживалась с локальной машины. Если проводить
-тест так, чтобы все операции всегда обращались к первичным OSD по сети - тест сильнее упирался
-в сеть и результат составлял примерно 689000 iops.
-
-Настройки Vitastor: `--disable_data_fsync true --immediate_commit all --flusher_count 8
-  --disk_alignment 4096 --journal_block_size 4096 --meta_block_size 4096
-  --journal_no_same_sector_overwrites true --journal_sector_buffer_count 1024
-  --journal_size 16777216`.
-
-### EC/XOR 2+1
-
-Vitastor:
- T1Q1 запись: 2808 iops (задержка ~0.355ms)
- T1Q1 чтение: 6190 iops (задержка ~0.16ms)
- T2Q64 запись: 85500 iops, потребление CPU - 3.4 ядра на каждом сервере
- T8Q64 чтение: 812000 iops, потребление CPU - 4.7 ядра на каждом сервере
- Линейная запись (4M T1Q32): 3200 МБ/с
- Линейное чтение (4M T1Q32): 1800 МБ/с
-
-Ceph:
- T1Q1 запись: 730 iops (задержка ~1.37ms latency)
- T1Q1 чтение: 1500 iops с холодным кэшем метаданных (задержка ~0.66ms), 2300 iops через 2 минуты прогрева (задержка ~0.435ms)
- T4Q128 запись (4 RBD images): 45300 iops, потребление CPU - 30 ядер на каждом сервере
- T8Q64 чтение (4 RBD images): 278600 iops, потребление CPU - 40 ядер на каждом сервере
- Линейная запись (4M T1Q32): 1950 МБ/с в пустой образ, 2500 МБ/с в заполненный образ
- Линейное чтение (4M T1Q32): 2400 МБ/с
-
-### NBD
-
-NBD расшифровывается как "сетевое блочное устройство", но на самом деле оно также
-работает просто как аналог FUSE для блочных устройств, то есть, представляет собой
-"блочное устройство в пространстве пользователя".
-
-NBD - на данный момент единственный способ монтировать Vitastor ядром Linux.
-NBD немного снижает производительность, так как приводит к дополнительным копированиям
-данных между ядром и пространством пользователя. Тем не менее, способ достаточно оптимален,
-а производительность случайного доступа вообще затрагивается слабо.
-
-Vitastor с однопоточной NBD прокси на том же стенде:
- T1Q1 запись: 6000 iops (задержка 0.166ms)
- T1Q1 чтение: 5518 iops (задержка 0.18ms)
- T1Q128 запись: 94400 iops
- T1Q128 чтение: 103000 iops
- Линейная запись (4M T1Q128): 1266 МБ/с (в сравнении с 2800 МБ/с через fio)
- Линейное чтение (4M T1Q128): 975 МБ/с (в сравнении с 1500 МБ/с через fio)
-
-## Установка
-
-### Debian
-
- Добавьте ключ репозитория Vitastor:
-  `wget -q -O - https://vitastor.io/debian/pubkey | sudo apt-key add -`
- Добавьте репозиторий Vitastor в /etc/apt/sources.list:
-  - Debian 11 (Bullseye/Sid): `deb https://vitastor.io/debian bullseye main`
-  - Debian 10 (Buster): `deb https://vitastor.io/debian buster main`
- Для Debian 10 (Buster) также включите репозиторий backports:
-  `deb http://deb.debian.org/debian buster-backports main`
- Установите пакеты: `apt update; apt install vitastor lp-solve etcd linux-image-amd64 qemu`
-
-### CentOS
-
- Добавьте в систему репозиторий Vitastor:
-  - CentOS 7: `yum install https://vitastor.io/rpms/centos/7/vitastor-release-1.0-1.el7.noarch.rpm`
-  - CentOS 8: `dnf install https://vitastor.io/rpms/centos/8/vitastor-release-1.0-1.el8.noarch.rpm`
- Включите EPEL: `yum/dnf install epel-release`
- Включите дополнительные репозитории CentOS:
-  - CentOS 7: `yum install centos-release-scl`
-  - CentOS 8: `dnf install centos-release-advanced-virtualization`
- Включите elrepo-kernel:
-  - CentOS 7: `yum install https://www.elrepo.org/elrepo-release-7.el7.elrepo.noarch.rpm`
-  - CentOS 8: `dnf install https://www.elrepo.org/elrepo-release-8.el8.elrepo.noarch.rpm`
- Установите пакеты: `yum/dnf install vitastor lpsolve etcd kernel-ml qemu-kvm`
-
-### Установка из исходников
-
- Установите ядро 5.4 или более новое, для поддержки io_uring. Желательно 5.8 или даже новее,
-  так как в 5.4 есть как минимум 1 известный баг, ведущий к зависанию с io_uring и контроллером HP SmartArray.
- Установите liburing 0.4 или более новый и его заголовки.
- Установите lp_solve.
- Установите etcd, версии не ниже 3.4.15. Более ранние версии работать не будут из-за различных багов,
-  например [#12402](https://github.com/etcd-io/etcd/pull/12402). Также вы можете взять версию 3.4.13 с
-  этим конкретным исправлением из ветки release-3.4 репозитория https://github.com/vitalif/etcd/.
- Установите node.js 10 или новее.
- Установите gcc и g++ 8.x или новее.
- Склонируйте данный репозиторий с подмодулями: `git clone https://yourcmc.ru/git/vitalif/vitastor/`.
- Желательно пересобрать QEMU с патчем, который делает необязательным запуск через LD_PRELOAD.
-  См `patches/qemu-*.*-vitastor.patch` - выберите версию, наиболее близкую вашей версии QEMU.
- Установите QEMU 3.0 или новее, возьмите исходные коды установленного пакета, начните его пересборку,
-  через некоторое время остановите её и скопируйте следующие заголовки:
-   - `<qemu>/include` &rarr; `<vitastor>/qemu/include`
-   - Debian:
-      * Берите qemu из основного репозитория
-      * `<qemu>/b/qemu/config-host.h` &rarr; `<vitastor>/qemu/b/qemu/config-host.h`
-      * `<qemu>/b/qemu/qapi` &rarr; `<vitastor>/qemu/b/qemu/qapi`
-   - CentOS 8:
-      * Берите qemu из репозитория Advanced-Virtualization. Чтобы включить его, запустите
-        `yum install centos-release-advanced-virtualization.noarch` и далее `yum install qemu`
-      * `<qemu>/config-host.h` &rarr; `<vitastor>/qemu/b/qemu/config-host.h`
-      * Для QEMU 3.0+: `<qemu>/qapi` &rarr; `<vitastor>/qemu/b/qemu/qapi`
-      * Для QEMU 2.0+: `<qemu>/qapi-types.h` &rarr; `<vitastor>/qemu/b/qemu/qapi-types.h`
-   - `config-host.h` и `qapi` нужны, т.к. в них содержатся автогенерируемые заголовки
- Установите fio 3.7 или новее, возьмите исходники пакета и сделайте на них симлинк с `<vitastor>/fio`.
- Соберите и установите Vitastor командой `mkdir build && cd build && cmake .. && make -j8 && make install`.
-  Обратите внимание на переменную cmake `QEMU_PLUGINDIR` - под RHEL её нужно установить равной `qemu-kvm`.
-
-## Запуск
-
-Внимание: процедура пока что достаточно нетривиальная, задавать конфигурацию и смещения
-на диске нужно почти вручную. Это будет исправлено в ближайшем будущем.
-
- Желательны SATA SSD или NVMe диски с конденсаторами (серверные SSD). Можно использовать и
-  десктопные SSD, включив режим отложенного fsync, но производительность однопоточной записи
-  в этом случае пострадает.
- Быстрая сеть, минимум 10 гбит/с
- Для наилучшей производительности нужно отключить энергосбережение CPU: `cpupower idle-set -D 0 && cpupower frequency-set -g performance`.
- На хостах мониторов:
-  - Пропишите нужные вам значения в файле `/usr/lib/vitastor/mon/make-units.sh`
-  - Создайте юниты systemd для etcd и мониторов: `/usr/lib/vitastor/mon/make-units.sh`
- Запустите etcd и мониторы: `systemctl start etcd vitastor-mon`
- Пропишите etcd_address и osd_network в `/etc/vitastor/vitastor.conf`. Например:
-  ```
-  {
-    "etcd_address": ["10.200.1.10:2379","10.200.1.11:2379","10.200.1.12:2379"],
-    "osd_network": "10.200.1.0/24"
-  }
-  ```
- Инициализуйте OSD:
-  - SSD: `/usr/lib/vitastor/make-osd.sh /dev/disk/by-partuuid/XXX [/dev/disk/by-partuuid/YYY ...]`
-  - Гибридные, HDD+SSD: `/usr/lib/vitastor/mon/make-osd-hybrid.js /dev/sda /dev/sdb ...` - передайте
-    все ваши SSD и HDD скрипту в командной строке подряд, скрипт автоматически выделит разделы под
-    журналы на SSD и данные на HDD. Скрипт пропускает HDD, на которых уже есть разделы
-    или вообще какие-то данные, поэтому если диски непустые, сначала очистите их с помощью
-    `wipefs -a`. SSD с таблицей разделов не пропускаются, но так как скрипт создаёт новые разделы
-    для журналов, на SSD должно быть доступно свободное нераспределённое место.
- Вы можете менять параметры OSD в юнитах systemd или в `vitastor.conf`. Смысл некоторых параметров:
-  - `disable_data_fsync 1` - отключает fsync, используется с SSD с конденсаторами.
-  - `immediate_commit all` - используется с SSD с конденсаторами.
-    Внимание: если установлено, также нужно установить его в то же значение в etcd в /vitastor/config/global
-  - `disable_device_lock 1` - отключает блокировку файла устройства, нужно, только если вы запускаете
-    несколько OSD на одном блочном устройстве.
-  - `flusher_count 256` - "flusher" - микропоток, удаляющий старые данные из журнала.
-    Не волнуйтесь об этой настройке, 256 теперь достаточно практически всегда.
-  - `disk_alignment`, `journal_block_size`, `meta_block_size` следует установить равными размеру
-    внутреннего блока SSD. Это почти всегда 4096.
-  - `journal_no_same_sector_overwrites true` запрещает перезапись одного и того же сектора журнала подряд
-    много раз в процессе записи. Большинство (99%) SSD не нуждаются в данной опции. Однако выяснилось, что
-    диски, используемые на одном из тестовых стендов - Intel D3-S4510 - очень сильно не любят такую
-    перезапись, и для них была добавлена эта опция. Когда данный режим включён, также нужно поднимать
-    значение `journal_sector_buffer_count`, так как иначе Vitastor не хватит буферов для записи в журнал.
- Создайте глобальную конфигурацию в etcd: `etcdctl --endpoints=... put /vitastor/config/global '{"immediate_commit":"all"}'`
-  (если все ваши диски - серверные с конденсаторами).
- Создайте пулы: `etcdctl --endpoints=... put /vitastor/config/pools '{"1":{"name":"testpool","scheme":"replicated","pg_size":2,"pg_minsize":1,"pg_count":256,"failure_domain":"host"}}'`.
-  Для jerasure EC-пулов конфигурация должна выглядеть так: `2:{"name":"ecpool","scheme":"jerasure","pg_size":4,"parity_chunks":2,"pg_minsize":2,"pg_count":256,"failure_domain":"host"}`.
- Запустите все OSD: `systemctl start vitastor.target`
- Ваш кластер должен быть готов - один из мониторов должен уже сконфигурировать PG, а OSD должны запустить их.
- Вы можете проверить состояние PG прямо в etcd: `etcdctl --endpoints=... get --prefix /vitastor/pg/state`. Все PG должны быть 'active'.
-
-### Задать имя образу
-
-```
-etcdctl --endpoints=<etcd> put /vitastor/config/inode/<pool>/<inode> '{"name":"<name>","size":<size>[,"parent_id":<parent_inode_number>][,"readonly":true]}'
-```
-
-Например:
-
-```
-etcdctl --endpoints=http://10.115.0.10:2379/v3 put /vitastor/config/inode/1/1 '{"name":"testimg","size":2147483648}'
-```
-
-Если вы зададите parent_id, то образ станет CoW-клоном, т.е. все новые запросы записи пойдут в новый инод, а запросы
-чтения будут проверять сначала его, а потом родительские слои по цепочке вверх. Чтобы случайно не перезаписать данные
-в родительском слое, вы можете переключить его в режим "только чтение", добавив флаг `"readonly":true` в его запись
-метаданных. В таком случае родительский образ становится просто снапшотом.
-
-Таким образом, для создания снапшота вам нужно просто переименовать предыдущий inode (например, из testimg в testimg@0),
-сделать его readonly и создать новый слой с исходным именем образа (testimg), ссылающийся на только что переименованный
-в качестве родительского.
-
-### Запуск тестов с fio
-
-Пример команды для запуска тестов:
-
-```
-fio -thread -ioengine=libfio_vitastor.so -name=test -bs=4M -direct=1 -iodepth=16 -rw=write -etcd=10.115.0.10:2379/v3 -image=testimg
-```
-
-Если вы не хотите обращаться к образу по имени, вместо `-image=testimg` можно указать номер пула, номер инода и размер:
-`-pool=1 -inode=1 -size=400G`.
-
-### Загрузить образ диска ВМ в/из Vitastor
-
-Используйте qemu-img и строку `vitastor:etcd_host=<HOST>:image=<IMAGE>` в качестве имени файла диска. Например:
-
-```
-qemu-img convert -f qcow2 debian10.qcow2 -p -O raw 'vitastor:etcd_host=10.115.0.10\:2379/v3:image=testimg'
-```
-
-Обратите внимание, что если вы используете немодифицированный QEMU, потребуется установить переменную окружения
-`LD_PRELOAD=/usr/lib/x86_64-linux-gnu/qemu/block-vitastor.so`.
-
-Если вы не хотите обращаться к образу по имени, вместо `:image=<IMAGE>` можно указать номер пула, номер инода и размер:
-`:pool=<POOL>:inode=<INODE>:size=<SIZE>`.
-
-### Запустить ВМ
-
-Для запуска QEMU используйте опцию `-drive file=vitastor:etcd_host=<HOST>:image=<IMAGE>` (аналогично qemu-img)
-и физический размер блока 4 KB.
-
-Например:
-
-```
-qemu-system-x86_64 -enable-kvm -m 1024
-  -drive 'file=vitastor:etcd_host=10.115.0.10\:2379/v3:image=testimg',format=raw,if=none,id=drive-virtio-disk0,cache=none
-  -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x5,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1,write-cache=off,physical_block_size=4096,logical_block_size=512
-  -vnc 0.0.0.0:0
-```
-
-Обращение по номерам (`:pool=<POOL>:inode=<INODE>:size=<SIZE>` вместо `:image=<IMAGE>`) работает аналогично qemu-img.
-
-### Удалить образ
-
-Используйте утилиту vitastor-cli rm-data. Например:
-
-```
-vitastor-cli rm-data --etcd_address 10.115.0.10:2379/v3 --pool 1 --inode 1 --parallel_osds 16 --iodepth 32
-```
-
-### NBD
-
-Чтобы создать локальное блочное устройство, используйте NBD. Например:
-
-```
-vitastor-nbd map --etcd_address 10.115.0.10:2379/v3 --image testimg
-```
-
-Команда напечатает название устройства вида /dev/nbd0, которое потом можно будет форматировать
-и использовать как обычное блочное устройство.
-
-Для обращения по номеру инода, аналогично другим командам, можно использовать опции
-`--pool <POOL> --inode <INODE> --size <SIZE>` вместо `--image testimg`.
-
-### NFS
-
-В Vitastor реализована упрощённая NFS 3.0 прокси для эмуляции файлового доступа к образам.
-Это не полноценная файловая система, т.к. метаданные всех файлов (образов) сохраняются
-в etcd и всё время хранятся в оперативной памяти - то есть, положить туда много файлов
-не получится.
-
-Однако в качестве способа доступа к образам виртуальных машин NFS прокси прекрасно подходит
-и позволяет подключить Vitastor, например, к VMWare.
-
-При этом, если вы используете режим immediate_commit=all (для SSD с конденсаторами или HDD
-с отключённым кэшем), то NFS-сервер не имеет состояния и вы можете свободно поднять
-его в нескольких экземплярах и использовать поверх них сетевой балансировщик нагрузки или
-схему с отказоустойчивостью.
-
-Использование vitastor-nfs:
-
-```
-vitastor-nfs [--etcd_address ADDR] [ДРУГИЕ ОПЦИИ]
-
--subdir <DIR>    экспортировать "поддиректорию" - образы с префиксом имени <DIR>/ (по умолчанию пусто - экспортировать все образы)
--portmap 0       отключить сервис portmap/rpcbind на порту 111 (по умолчанию включён и требует root привилегий)
--bind <IP>       принимать соединения по адресу <IP> (по умолчанию 0.0.0.0 - на всех)
--nfspath <PATH>  установить путь NFS-экспорта в <PATH> (по умолчанию /)
--port <PORT>     использовать порт <PORT> для NFS-сервисов (по умолчанию 2049)
--pool <POOL>     исползовать пул <POOL> для новых образов (обязательно, если пул в кластере не один)
--foreground 1    не уходить в фон после запуска
-```
-
-Пример монтирования Vitastor через NFS:
-
-```
-vitastor-nfs --etcd_address 192.168.5.10:2379 --portmap 0 --port 2050 --pool testpool
-```
-
-```
-mount localhost:/ /mnt/ -o port=2050,mountport=2050,nfsvers=3,soft,nolock,tcp
-```
-
-### Kubernetes
-
-У Vitastor есть CSI-плагин для Kubernetes, поддерживающий RWO, а также блочные RWX, тома.
-
-Для установки возьмите манифесты из директории [csi/deploy/](csi/deploy/), поместите
-вашу конфигурацию подключения к Vitastor в [csi/deploy/001-csi-config-map.yaml](001-csi-config-map.yaml),
-настройте StorageClass в [csi/deploy/009-storage-class.yaml](009-storage-class.yaml)
-и примените все `NNN-*.yaml` к вашей инсталляции Kubernetes.
-
-```
-for i in ./???-*.yaml; do kubectl apply -f $i; done
-```
-
-После этого вы сможете создавать PersistentVolume. Пример смотрите в файле [csi/deploy/example-pvc.yaml](csi/deploy/example-pvc.yaml).
-
-### OpenStack
-
-Чтобы подключить Vitastor к OpenStack:
-
- Установите пакеты vitastor-client, libvirt и QEMU из DEB или RPM репозитория Vitastor
- Примените патч `patches/nova-21.diff` или `patches/nova-23.diff` к вашей инсталляции Nova.
-  nova-21.diff подходит для Nova 21-22, nova-23.diff подходит для Nova 23-24.
- Скопируйте `patches/cinder-vitastor.py` в инсталляцию Cinder как `cinder/volume/drivers/vitastor.py`
- Создайте тип томов в cinder.conf (см. ниже)
- Обязательно заблокируйте доступ от виртуальных машин к сети Vitastor (OSD и etcd), т.к. Vitastor (пока) не поддерживает аутентификацию
- Перезапустите Cinder и Nova
-
-Пример конфигурации Cinder:
-
-```
-[DEFAULT]
-enabled_backends = lvmdriver-1, vitastor-testcluster
-# ...
-
-[vitastor-testcluster]
-volume_driver = cinder.volume.drivers.vitastor.VitastorDriver
-volume_backend_name = vitastor-testcluster
-image_volume_cache_enabled = True
-volume_clear = none
-vitastor_etcd_address = 192.168.7.2:2379
-vitastor_etcd_prefix =
-vitastor_config_path = /etc/vitastor/vitastor.conf
-vitastor_pool_id = 1
-image_upload_use_cinder_backend = True
-```
-
-Чтобы помещать в Vitastor Glance-образы, нужно использовать
-[https://docs.openstack.org/cinder/pike/admin/blockstorage-volume-backed-image.html](образы на основе томов Cinder),
-однако, поддержка этой функции ещё не проверялась.
-
-### Proxmox
-
-Чтобы подключить Vitastor к Proxmox Virtual Environment (поддерживаются версии 6.4 и 7.1):
-
- Добавьте соответствующий Debian-репозиторий Vitastor в sources.list на хостах Proxmox
-  (buster для 6.4, bullseye для 7.1)
- Установите пакеты vitastor-client, pve-qemu-kvm, pve-storage-vitastor (* или см. сноску) из репозитория Vitastor
- Определите тип хранилища в `/etc/pve/storage.cfg` (см. ниже)
- Обязательно заблокируйте доступ от виртуальных машин к сети Vitastor (OSD и etcd), т.к. Vitastor (пока) не поддерживает аутентификацию
- Перезапустите демон Proxmox: `systemctl restart pvedaemon`
-
-Пример `/etc/pve/storage.cfg` (единственная обязательная опция - vitastor_pool, все остальные
-перечислены внизу для понимания значений по умолчанию):
-
-```
-vitastor: vitastor
-    # Пул, в который будут помещаться образы дисков
-    vitastor_pool testpool
-    # Путь к файлу конфигурации
-    vitastor_config_path /etc/vitastor/vitastor.conf
-    # Адрес(а) etcd, нужны, только если не указаны в vitastor.conf
-    vitastor_etcd_address 192.168.7.2:2379/v3
-    # Префикс ключей метаданных в etcd
-    vitastor_etcd_prefix /vitastor
-    # Префикс имён образов
-    vitastor_prefix pve/
-    # Монтировать образы через NBD прокси, через ядро (нужно только для контейнеров)
-    vitastor_nbd 0
-```
-
-\* Примечание: вместо установки пакета pve-storage-vitastor вы можете вручную скопировать файл
-[patches/PVE_VitastorPlugin.pm](patches/PVE_VitastorPlugin.pm) на хосты Proxmox как
-`/usr/share/perl5/PVE/Storage/Custom/VitastorPlugin.pm`.
-
-## Известные проблемы
-
- Запросы удаления объектов могут в данный момент приводить к "неполным" объектам в EC-пулах,
-  если в процессе удаления произойдут отказы OSD или серверов, потому что правильная обработка
-  запросов удаления в кластере должна быть "трёхфазной", а это пока не реализовано. Если вы
-  столкнётесь с такой ситуацией, просто повторите запрос удаления.
-
-## Принципы реализации
-
- Я люблю архитектурно простые решения. Vitastor проектируется именно так и я намерен
-  и далее следовать данному принципу.
- Если вы пришли сюда за идеальным кодом на C++, вы, вероятно, не по адресу. "Общепринятые"
-  практики написания C++ кода меня не очень волнуют, так как зачастую, опять-таки, ведут к
-  излишним усложнениям и код получается красивый... но медленный.
- По той же причине в коде иногда можно встретить велосипеды типа собственного упрощённого
-  HTTP-клиента для работы с etcd. Зато эти велосипеды маленькие и компактные и не требуют
-  использования десятка внешних библиотек.
- node.js для монитора - не случайный выбор. Он очень быстрый, имеет встроенную событийную
-  машину, приятный нейтральный C-подобный язык программирования и развитую инфраструктуру.
+Vitastor нацелен на SSD и SSD+HDD кластеры с как минимум 10 Гбит/с сетью, поддерживает
+TCP и RDMA и на хорошем железе может достигать задержки 4 КБ чтения и записи на уровне ~0.1 мс,
+что примерно в 10 раз быстрее, чем Ceph и другие популярные программные СХД.
+
+Vitastor поддерживает QEMU-драйвер, протоколы NBD и NFS, драйверы OpenStack, Proxmox, Kubernetes.
+Другие драйверы могут также быть легко реализованы.
+
+Подробности смотрите в документации по ссылкам ниже.
+
+## Презентации и записи докладов
+
+- DevOpsConf'2021: презентация ([на русском](https://vitastor.io/presentation/devopsconf/devopsconf.html),
+  [на английском](https://vitastor.io/presentation/devopsconf/devopsconf_en.html)),
+  [видео](https://vitastor.io/presentation/devopsconf/talk.webm)
+- Highload'2022: презентация ([на русском](https://vitastor.io/presentation/highload/highload.html)),
+  [видео](https://vitastor.io/presentation/highload/talk.webm)
+
+## Документация
+
+- Введение
+  - [Быстрый старт](docs/intro/quickstart.ru.md)
+  - [Возможности](docs/intro/features.ru.md)
+  - [Архитектура](docs/intro/architecture.ru.md)
+  - [Автор и лицензия](docs/intro/author.ru.md)
+- Установка
+  - [Пакеты](docs/installation/packages.ru.md)
+  - [Proxmox](docs/installation/proxmox.ru.md)
+  - [OpenStack](docs/installation/openstack.ru.md)
+  - [Kubernetes CSI](docs/installation/kubernetes.ru.md)
+  - [Сборка из исходных кодов](docs/installation/source.ru.md)
+- Конфигурация
+  - [Обзор](docs/config.ru.md)
+  - Параметры
+    - [Общие](docs/config/common.ru.md)
+    - [Сетевые](docs/config/network.ru.md)
+    - [Глобальные дисковые параметры](docs/config/layout-cluster.ru.md)
+    - [Дисковые параметры OSD](docs/config/layout-osd.ru.md)
+    - [Прочие параметры OSD](docs/config/osd.ru.md)
+    - [Параметры мониторов](docs/config/monitor.ru.md)
+  - [Настройки пулов](docs/config/pool.ru.md)
+  - [Метаданные образов в etcd](docs/config/inode.ru.md)
+- Использование
+  - [vitastor-cli](docs/usage/cli.ru.md) (консольный интерфейс)
+  - [fio](docs/usage/fio.ru.md) для тестов производительности
+  - [NBD](docs/usage/nbd.ru.md) для монтирования ядром
+  - [QEMU и qemu-img](docs/usage/qemu.ru.md)
+  - [NFS](docs/usage/nfs.ru.md)-прокси для VMWare и подобных
+- Производительность
+  - [Понимание сути производительности](docs/performance/understanding.ru.md)
+  - [Теоретический максимум](docs/performance/theoretical.ru.md)
+  - [Пример сравнения с Ceph](docs/performance/comparison1.ru.md)

 ## Автор и лицензия

--- a/README.md
+++ b/README.md
@ -1,626 +1,71 @@
-## Vitastor
+# Vitastor

 [Читать на русском](README-ru.md)

 ## The Idea

-Make Software-Defined Block Storage Great Again.
-
-Vitastor is a small, simple and fast clustered block storage (storage for VM drives),
-architecturally similar to Ceph which means strong consistency, primary-replication, symmetric
-clustering and automatic data distribution over any number of drives of any size
-with configurable redundancy (replication or erasure codes/XOR).
-
-## Features
-
-Vitastor is currently a pre-release, a lot of features are missing and you can still expect
-breaking changes in the future. However, the following is implemented:
-
- Basic part: highly-available block storage with symmetric clustering and no SPOF
- Performance ;-D
- Multiple redundancy schemes: Replication, XOR n+1, Reed-Solomon erasure codes
-  based on jerasure library with any number of data and parity drives in a group
- Configuration via simple JSON data structures in etcd
- Automatic data distribution over OSDs, with support for:
-  - Mathematical optimization for better uniformity and less data movement
-  - Multiple pools
-  - Placement tree, OSD selection by tags (device classes) and placement root
-  - Configurable failure domains
- Recovery of degraded blocks
- Rebalancing (data movement between OSDs)
- Lazy fsync support
- I/O statistics reporting to etcd
- Generic user-space client library
- QEMU driver (built out-of-tree)
- Loadable fio engine for benchmarks (also built out-of-tree)
- NBD proxy for kernel mounts
- Inode removal tool (vitastor-cli rm-data)
- Packaging for Debian and CentOS
- Per-inode I/O and space usage statistics
- Inode metadata storage in etcd
- Snapshots and copy-on-write image clones
- Write throttling to smooth random write workloads in SSD+HDD configurations
- RDMA/RoCEv2 support via libibverbs
- CSI plugin for Kubernetes
- Basic OpenStack support: Cinder driver, Nova and libvirt patches
- Snapshot merge tool (vitastor-cli {snap-rm,flatten,merge})
- Image management CLI (vitastor-cli {ls,create,modify})
- Proxmox storage plugin
- Simplified NFS proxy for file-based image access emulation (suitable for VMWare)
-
-## Roadmap
-
- Better OSD creation and auto-start tools
- Other administrative tools
- Plugins for OpenNebula and other cloud systems
- iSCSI proxy
- Faster failover
- Scrubbing without checksums (verification of replicas)
- Checksums
- Tiered storage
- NVDIMM support
- Web GUI
- Compression (possibly)
- Read caching using system page cache (possibly)
-
-## Architecture
-
-Similarities:
-
- Just like Ceph, Vitastor has Pools, PGs, OSDs, Monitors, Failure Domains, Placement Tree.
- Just like Ceph, Vitastor is transactional (even though there's a "lazy fsync mode" which
-  doesn't implicitly flush every operation to disks).
- OSDs also have journal and metadata and they can also be put on separate drives.
- Just like in Ceph, client library attempts to recover from any cluster failure so
-  you can basically reboot the whole cluster and only pause, but not crash, your clients
-  (I consider this a bug if the client crashes in that case).
-
-Some basic terms for people not familiar with Ceph:
-
- OSD (Object Storage Daemon) is a process that stores data and serves read/write requests.
- PG (Placement Group) is a container for data that (normally) shares the same replicas.
- Pool is a container for data that has the same redundancy scheme and placement rules.
- Monitor is a separate daemon that watches cluster state and handles failures.
- Failure Domain is a group of OSDs that you allow to fail. It's "host" by default.
- Placement Tree groups OSDs in a hierarchy to later split them into Failure Domains.
-
-Architectural differences from Ceph:
-
- Vitastor's primary focus is on SSDs. Proper SSD+HDD optimizations may be added in the future, though.
- Vitastor OSD is (and will always be) single-threaded. If you want to dedicate more than 1 core
-  per drive you should run multiple OSDs each on a different partition of the drive.
-  Vitastor isn't CPU-hungry though (as opposed to Ceph), so 1 core is sufficient in a lot of cases.
- Metadata and journal are always kept in memory. Metadata size depends linearly on drive capacity
-  and data store block size which is 128 KB by default. With 128 KB blocks metadata should occupy
-  around 512 MB per 1 TB (which is still less than Ceph wants). Journal doesn't have to be big,
-  the example test below was conducted with only 16 MB journal. A big journal is probably even
-  harmful as dirty write metadata also take some memory.
- Vitastor storage layer doesn't have internal copy-on-write or redirect-write. I know that maybe
-  it's possible to create a good copy-on-write storage, but it's much harder and makes performance
-  less deterministic, so CoW isn't used in Vitastor.
- The basic layer of Vitastor is block storage with fixed-size blocks, not object storage with
-  rich semantics like in Ceph (RADOS).
- There's a "lazy fsync" mode which allows to batch writes before flushing them to the disk.
-  This allows to use Vitastor with desktop SSDs, but still lowers performance due to additional
-  network roundtrips, so use server SSDs with capacitor-based power loss protection
-  ("Advanced Power Loss Protection") for best performance.
- PGs are ephemeral. This means that they aren't stored on data disks and only exist in memory
-  while OSDs are running.
- Recovery process is per-object (per-block), not per-PG. Also there are no PGLOGs.
- Monitors don't store data. Cluster configuration and state is stored in etcd in simple human-readable
-  JSON structures. Monitors only watch cluster state and handle data movement.
-  Thus Vitastor's Monitor isn't a critical component of the system and is more similar to Ceph's Manager.
-  Vitastor's Monitor is implemented in node.js.
- PG distribution isn't based on consistent hashes. All PG mappings are stored in etcd.
-  Rebalancing PGs between OSDs is done by mathematical optimization - data distribution problem
-  is reduced to a linear programming problem and solved by lp_solve. This allows for almost
-  perfect (96-99% uniformity compared to Ceph's 80-90%) data distribution in most cases, ability
-  to map PGs by hand without breaking rebalancing logic, reduced OSD peer-to-peer communication
-  (on average, OSDs have fewer peers) and less data movement. It also probably has a drawback -
-  this method may fail in very large clusters, but up to several hundreds of OSDs it's perfectly fine.
-  It's also easy to add consistent hashes in the future if something proves their necessity.
- There's no separate CRUSH layer. You select pool redundancy scheme, placement root, failure domain
-  and so on directly in pool configuration.
-
-## Understanding Storage Performance
-
-The most important thing for fast storage is latency, not parallel iops.
-
-The best possible latency is achieved with one thread and queue depth of 1 which basically means
-"client load as low as possible". In this case IOPS = 1/latency, and this number doesn't
-scale with number of servers, drives, server processes or threads and so on.
-Single-threaded IOPS and latency numbers only depend on *how fast a single daemon is*.
-
-Why is it important? It's important because some of the applications *can't* use
-queue depth greater than 1 because their task isn't parallelizable. A notable example
-is any ACID DBMS because all of them write their WALs sequentially with fsync()s.
-
-fsync, by the way, is another important thing often missing in benchmarks. The point is
-that drives have cache buffers and don't guarantee that your data is actually persisted
-until you call fsync() which is translated to a FLUSH CACHE command by the OS.
-
-Desktop SSDs are very fast without fsync - NVMes, for example, can process ~80000 write
-operations per second with queue depth of 1 without fsync - but they're really slow with
-fsync because they have to actually write data to flash chips when you call fsync. Typical
-number is around 1000-2000 iops with fsync.
-
-Server SSDs often have supercapacitors that act as a built-in UPS and allow the drive
-to flush its DRAM cache to the persistent flash storage when a power loss occurs.
-This makes them perform equally well with and without fsync. This feature is called
-"Advanced Power Loss Protection" by Intel; other vendors either call it similarly
-or directly as "Full Capacitor-Based Power Loss Protection".
-
-All software-defined storages that I currently know are slow in terms of latency.
-Notable examples are Ceph and internal SDSes used by cloud providers like Amazon, Google,
-Yandex and so on. They're all slow and can only reach ~0.3ms read and ~0.6ms 4 KB write latency
-with best-in-slot hardware.
-
-And that's in the SSD era when you can buy an SSD that has ~0.04ms latency for 100 $.
-
-I use the following 6 commands with small variations to benchmark any storage:
-
- Linear write:
-  `fio -ioengine=libaio -direct=1 -invalidate=1 -name=test -bs=4M -iodepth=32 -rw=write -runtime=60 -filename=/dev/sdX`
- Linear read:
-  `fio -ioengine=libaio -direct=1 -invalidate=1 -name=test -bs=4M -iodepth=32 -rw=read -runtime=60 -filename=/dev/sdX`
- Random write latency (T1Q1, this hurts storages the most):
-  `fio -ioengine=libaio -direct=1 -invalidate=1 -name=test -bs=4k -iodepth=1 -fsync=1 -rw=randwrite -runtime=60 -filename=/dev/sdX`
- Random read latency (T1Q1):
-  `fio -ioengine=libaio -direct=1 -invalidate=1 -name=test -bs=4k -iodepth=1 -rw=randread -runtime=60 -filename=/dev/sdX`
- Parallel write iops (use numjobs if a single CPU core is insufficient to saturate the load):
-  `fio -ioengine=libaio -direct=1 -invalidate=1 -name=test -bs=4k -iodepth=128 [-numjobs=4 -group_reporting] -rw=randwrite -runtime=60 -filename=/dev/sdX`
- Parallel read iops (use numjobs if a single CPU core is insufficient to saturate the load):
-  `fio -ioengine=libaio -direct=1 -invalidate=1 -name=test -bs=4k -iodepth=128 [-numjobs=4 -group_reporting] -rw=randread -runtime=60 -filename=/dev/sdX`
-
-## Vitastor's Theoretical Maximum Random Access Performance
-
-Replicated setups:
- Single-threaded (T1Q1) read latency: 1 network roundtrip + 1 disk read.
- Single-threaded write+fsync latency:
-  - With immediate commit: 2 network roundtrips + 1 disk write.
-  - With lazy commit: 4 network roundtrips + 1 disk write + 1 disk flush.
- Saturated parallel read iops: min(network bandwidth, sum(disk read iops)).
- Saturated parallel write iops: min(network bandwidth, sum(disk write iops / number of replicas / write amplification)).
-
-EC/XOR setups:
- Single-threaded (T1Q1) read latency: 1.5 network roundtrips + 1 disk read.
- Single-threaded write+fsync latency:
-  - With immediate commit: 3.5 network roundtrips + 1 disk read + 2 disk writes.
-  - With lazy commit: 5.5 network roundtrips + 1 disk read + 2 disk writes + 2 disk fsyncs.
-  - 0.5 in actually (k-1)/k which means that an additional roundtrip doesn't happen when
-    the read sub-operation can be served locally.
- Saturated parallel read iops: min(network bandwidth, sum(disk read iops)).
- Saturated parallel write iops: min(network bandwidth, sum(disk write iops * number of data drives / (number of data + parity drives) / write amplification)).
-  In fact, you should put disk write iops under the condition of ~10% reads / ~90% writes in this formula.
-
-Write amplification for 4 KB blocks is usually 3-5 in Vitastor:
-1. Journal block write
-2. Journal data write
-3. Metadata block write
-4. Another journal block write for EC/XOR setups
-5. Data block write
-
-If you manage to get an SSD which handles 512 byte blocks well (Optane?) you may
-lower 1, 3 and 4 to 512 bytes (1/8 of data size) and get WA as low as 2.375.
-
-Lazy fsync also reduces WA for parallel workloads because journal blocks are only
-written when they fill up or fsync is requested.
-
-## Example Comparison with Ceph
-
-Hardware configuration: 4 nodes, each with:
- 6x SATA SSD Intel D3-4510 3.84 TB
- 2x Xeon Gold 6242 (16 cores @ 2.8 GHz)
- 384 GB RAM
- 1x 25 GbE network interface (Mellanox ConnectX-4 LX), connected to a Juniper QFX5200 switch
-
-CPU powersaving was disabled. Both Vitastor and Ceph were configured with 2 OSDs per 1 SSD.
-
-All of the results below apply to 4 KB blocks and random access (unless indicated otherwise).
-
-Raw drive performance:
- T1Q1 write ~27000 iops (~0.037ms latency)
- T1Q1 read ~9800 iops (~0.101ms latency)
- T1Q32 write ~60000 iops
- T1Q32 read ~81700 iops
-
-Ceph 15.2.4 (Bluestore):
- T1Q1 write ~1000 iops (~1ms latency)
- T1Q1 read ~1750 iops (~0.57ms latency)
- T8Q64 write ~100000 iops, total CPU usage by OSDs about 40 virtual cores on each node
- T8Q64 read ~480000 iops, total CPU usage by OSDs about 40 virtual cores on each node
-
-T8Q64 tests were conducted over 8 400GB RBD images from all hosts (every host was running 2 instances of fio).
-This is because Ceph has performance penalties related to running multiple clients over a single RBD image.
-
-cephx_sign_messages was set to false during tests, RocksDB and Bluestore settings were left at defaults.
-
-In fact, not that bad for Ceph. These servers are an example of well-balanced Ceph nodes.
-However, CPU usage and I/O latency were through the roof, as usual.
-
-Vitastor:
- T1Q1 write: 7087 iops (0.14ms latency)
- T1Q1 read: 6838 iops (0.145ms latency)
- T2Q64 write: 162000 iops, total CPU usage by OSDs about 3 virtual cores on each node
- T8Q64 read: 895000 iops, total CPU usage by OSDs about 4 virtual cores on each node
- Linear write (4M T1Q32): 2800 MB/s
- Linear read (4M T1Q32): 1500 MB/s
-
-T8Q64 read test was conducted over 1 larger inode (3.2T) from all hosts (every host was running 2 instances of fio).
-Vitastor has no performance penalties related to running multiple clients over a single inode.
-If conducted from one node with all primary OSDs moved to other nodes the result was slightly lower (689000 iops),
-this is because all operations resulted in network roundtrips between the client and the primary OSD.
-When fio was colocated with OSDs (like in Ceph benchmarks above), 1/4 of the read workload actually
-used the loopback network.
-
-Vitastor was configured with: `--disable_data_fsync true --immediate_commit all --flusher_count 8
-  --disk_alignment 4096 --journal_block_size 4096 --meta_block_size 4096
-  --journal_no_same_sector_overwrites true --journal_sector_buffer_count 1024
-  --journal_size 16777216`.
-
-### EC/XOR 2+1
-
-Vitastor:
- T1Q1 write: 2808 iops (~0.355ms latency)
- T1Q1 read: 6190 iops (~0.16ms latency)
- T2Q64 write: 85500 iops, total CPU usage by OSDs about 3.4 virtual cores on each node
- T8Q64 read: 812000 iops, total CPU usage by OSDs about 4.7 virtual cores on each node
- Linear write (4M T1Q32): 3200 MB/s
- Linear read (4M T1Q32): 1800 MB/s
-
-Ceph:
- T1Q1 write: 730 iops (~1.37ms latency)
- T1Q1 read: 1500 iops with cold cache (~0.66ms latency), 2300 iops after 2 minute metadata cache warmup (~0.435ms latency)
- T4Q128 write (4 RBD images): 45300 iops, total CPU usage by OSDs about 30 virtual cores on each node
- T8Q64 read (4 RBD images): 278600 iops, total CPU usage by OSDs about 40 virtual cores on each node
- Linear write (4M T1Q32): 1950 MB/s before preallocation, 2500 MB/s after preallocation
- Linear read (4M T1Q32): 2400 MB/s
-
-### NBD
-
-NBD is currently required to mount Vitastor via kernel, but it imposes additional overhead
-due to additional copying between the kernel and userspace. This mostly hurts linear
-bandwidth, not iops.
-
-Vitastor with single-thread NBD on the same hardware:
- T1Q1 write: 6000 iops (0.166ms latency)
- T1Q1 read: 5518 iops (0.18ms latency)
- T1Q128 write: 94400 iops
- T1Q128 read: 103000 iops
- Linear write (4M T1Q128): 1266 MB/s (compared to 2800 MB/s via fio)
- Linear read (4M T1Q128): 975 MB/s (compared to 1500 MB/s via fio)
-
-## Installation
-
-### Debian
-
- Trust Vitastor package signing key:
-  `wget -q -O - https://vitastor.io/debian/pubkey | sudo apt-key add -`
- Add Vitastor package repository to your /etc/apt/sources.list:
-  - Debian 11 (Bullseye/Sid): `deb https://vitastor.io/debian bullseye main`
-  - Debian 10 (Buster): `deb https://vitastor.io/debian buster main`
- For Debian 10 (Buster) also enable backports repository:
-  `deb http://deb.debian.org/debian buster-backports main`
- Install packages: `apt update; apt install vitastor lp-solve etcd linux-image-amd64 qemu`
-
-### CentOS
-
- Add Vitastor package repository:
-  - CentOS 7: `yum install https://vitastor.io/rpms/centos/7/vitastor-release-1.0-1.el7.noarch.rpm`
-  - CentOS 8: `dnf install https://vitastor.io/rpms/centos/8/vitastor-release-1.0-1.el8.noarch.rpm`
- Enable EPEL: `yum/dnf install epel-release`
- Enable additional CentOS repositories:
-  - CentOS 7: `yum install centos-release-scl`
-  - CentOS 8: `dnf install centos-release-advanced-virtualization`
- Enable elrepo-kernel:
-  - CentOS 7: `yum install https://www.elrepo.org/elrepo-release-7.el7.elrepo.noarch.rpm`
-  - CentOS 8: `dnf install https://www.elrepo.org/elrepo-release-8.el8.elrepo.noarch.rpm`
- Install packages: `yum/dnf install vitastor lpsolve etcd kernel-ml qemu-kvm`
-
-### Building from Source
-
- Install Linux kernel 5.4 or newer, for io_uring support. 5.8 or later is highly recommended because
-  there is at least one known io_uring hang with 5.4 and an HP SmartArray controller.
- Install liburing 0.4 or newer and its headers.
- Install lp_solve.
- Install etcd, at least version 3.4.15. Earlier versions won't work because of various bugs,
-  for example [#12402](https://github.com/etcd-io/etcd/pull/12402). You can also take 3.4.13
-  with this specific fix from here: https://github.com/vitalif/etcd/, branch release-3.4.
- Install node.js 10 or newer.
- Install gcc and g++ 8.x or newer.
- Clone https://yourcmc.ru/git/vitalif/vitastor/ with submodules.
- Install QEMU 3.0+, get its source, begin to build it, stop the build and copy headers:
-   - `<qemu>/include` &rarr; `<vitastor>/qemu/include`
-   - Debian:
-      * Use qemu packages from the main repository
-      * `<qemu>/b/qemu/config-host.h` &rarr; `<vitastor>/qemu/b/qemu/config-host.h`
-      * `<qemu>/b/qemu/qapi` &rarr; `<vitastor>/qemu/b/qemu/qapi`
-   - CentOS 8:
-      * Use qemu packages from the Advanced-Virtualization repository. To enable it, run
-        `yum install centos-release-advanced-virtualization.noarch` and then `yum install qemu`
-      * `<qemu>/config-host.h` &rarr; `<vitastor>/qemu/b/qemu/config-host.h`
-      * For QEMU 3.0+: `<qemu>/qapi` &rarr; `<vitastor>/qemu/b/qemu/qapi`
-      * For QEMU 2.0+: `<qemu>/qapi-types.h` &rarr; `<vitastor>/qemu/b/qemu/qapi-types.h`
-   - `config-host.h` and `qapi` are required because they contain generated headers
- You can also rebuild QEMU with a patch that makes LD_PRELOAD unnecessary to load vitastor driver.
-  See `patches/qemu-*.*-vitastor.patch`.
- Install fio 3.7 or later, get its source and symlink it into `<vitastor>/fio`.
- Build & install Vitastor with `mkdir build && cd build && cmake .. && make -j8 && make install`.
-  Pay attention to the `QEMU_PLUGINDIR` cmake option - it must be set to `qemu-kvm` on RHEL.
-
-## Running
-
-Please note that startup procedure isn't currently simple - you specify configuration
-and calculate disk offsets almost by hand. This will be fixed in near future.
-
- Get some SATA or NVMe SSDs with capacitors (server-grade drives). You can use desktop SSDs
-  with lazy fsync, but prepare for inferior single-thread latency.
- Get a fast network (at least 10 Gbit/s).
- Disable CPU powersaving: `cpupower idle-set -D 0 && cpupower frequency-set -g performance`.
- On the monitor hosts:
-  - Edit variables at the top of `/usr/lib/vitastor/mon/make-units.sh` to desired values.
-  - Create systemd units for the monitor and etcd: `/usr/lib/vitastor/mon/make-units.sh`
- Start etcd and monitors: `systemctl start etcd vitastor-mon`
- Put etcd_address and osd_network into `/etc/vitastor/vitastor.conf`. Example:
-  ```
-  {
-    "etcd_address": ["10.200.1.10:2379","10.200.1.11:2379","10.200.1.12:2379"],
-    "osd_network": "10.200.1.0/24"
-  }
-  ```
- Initialize OSDs:
-  - Simplest, SSD-only: `/usr/lib/vitastor/mon/make-osd.sh /dev/disk/by-partuuid/XXX [/dev/disk/by-partuuid/YYY ...]`
-  - Hybrid, HDD+SSD: `/usr/lib/vitastor/mon/make-osd-hybrid.js /dev/sda /dev/sdb ...` - pass all your
-    devices (HDD and SSD) to this script - it will partition disks and initialize journals on its own.
-    This script skips HDDs which are already partitioned so if you want to use non-empty disks for
-    Vitastor you should first wipe them with `wipefs -a`. SSDs with GPT partition table are not skipped,
-    but some free unpartitioned space must be available because the script creates new partitions for journals.
- You can change OSD configuration in units or in `vitastor.conf`. Notable configuration variables:
-  - `disable_data_fsync 1` - only safe with server-grade drives with capacitors.
-  - `immediate_commit all` - use this if all your drives are server-grade.
-    If all OSDs have it set to all then you should also put the same value in etcd into /vitastor/config/global
-  - `disable_device_lock 1` - only required if you run multiple OSDs on one block device.
-  - `flusher_count 256` - flusher is a micro-thread that removes old data from the journal.
-    You don't have to worry about this parameter anymore, 256 is enough.
-  - `disk_alignment`, `journal_block_size`, `meta_block_size` should be set to the internal
-    block size of your SSDs which is 4096 on most drives.
-  - `journal_no_same_sector_overwrites true` prevents multiple overwrites of the same journal sector.
-    Most (99%) SSDs don't need this option. But Intel D3-4510 does because it doesn't like when you
-    overwrite the same sector twice in a short period of time. The setting forces Vitastor to never
-    overwrite the same journal sector twice in a row which makes D3-4510 almost happy. Not totally
-    happy, because overwrites of the same block can still happen in the metadata area... When this
-    setting is set, it is also required to raise `journal_sector_buffer_count` setting, which is the
-    number of dirty journal sectors that may be written to at the same time.
- `systemctl start vitastor.target` everywhere.
- Create global configuration in etcd: `etcdctl --endpoints=... put /vitastor/config/global '{"immediate_commit":"all"}'`
-  (if all your drives have capacitors).
- Create pool configuration in etcd: `etcdctl --endpoints=... put /vitastor/config/pools '{"1":{"name":"testpool","scheme":"replicated","pg_size":2,"pg_minsize":1,"pg_count":256,"failure_domain":"host"}}'`.
-  For jerasure pools the configuration should look like the following: `2:{"name":"ecpool","scheme":"jerasure","pg_size":4,"parity_chunks":2,"pg_minsize":2,"pg_count":256,"failure_domain":"host"}`.
- At this point, one of the monitors will configure PGs and OSDs will start them.
- You can check PG states with `etcdctl --endpoints=... get --prefix /vitastor/pg/state`. All PGs should become 'active'.
-
-### Name an image
-
-```
-etcdctl --endpoints=<etcd> put /vitastor/config/inode/<pool>/<inode> '{"name":"<name>","size":<size>[,"parent_id":<parent_inode_number>][,"readonly":true]}'
-```
-
-For example:
-
-```
-etcdctl --endpoints=http://10.115.0.10:2379/v3 put /vitastor/config/inode/1/1 '{"name":"testimg","size":2147483648}'
-```
-
-If you specify parent_id the image becomes a CoW clone. I.e. all writes go to the new inode and reads first check it
-and then upper layers. You can then make parent readonly by updating its entry with `"readonly":true` for safety and
-basically treat it as a snapshot.
-
-So to create a snapshot you basically rename the previous upper layer (for example from testimg to testimg@0), make it readonly
-and create a new top layer with the original name (testimg) and the previous one as a parent.
-
-### Run fio benchmarks
-
-fio command example:
-
-```
-fio -thread -ioengine=libfio_vitastor.so -name=test -bs=4M -direct=1 -iodepth=16 -rw=write -etcd=10.115.0.10:2379/v3 -image=testimg
-```
-
-If you don't want to access your image by name, you can specify pool number, inode number and size
-(`-pool=1 -inode=1 -size=400G`) instead of the image name (`-image=testimg`).
-
-### Upload VM image
-
-Use qemu-img and `vitastor:etcd_host=<HOST>:image=<IMAGE>` disk filename. For example:
-
-```
-qemu-img convert -f qcow2 debian10.qcow2 -p -O raw 'vitastor:etcd_host=10.115.0.10\:2379/v3:image=testimg'
-```
-
-Note that the command requires to be run with `LD_PRELOAD=/usr/lib/x86_64-linux-gnu/qemu/block-vitastor.so qemu-img ...`
-if you use unmodified QEMU.
-
-You can also specify `:pool=<POOL>:inode=<INODE>:size=<SIZE>` instead of `:image=<IMAGE>`
-if you don't want to use inode metadata.
-
-### Start a VM
-
-Run QEMU with `-drive file=vitastor:etcd_host=<HOST>:image=<IMAGE>` and use 4 KB physical block size.
-
-For example:
-
-```
-qemu-system-x86_64 -enable-kvm -m 1024
-  -drive 'file=vitastor:etcd_host=10.115.0.10\:2379/v3:image=testimg',format=raw,if=none,id=drive-virtio-disk0,cache=none
-  -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x5,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1,write-cache=off,physical_block_size=4096,logical_block_size=512
-  -vnc 0.0.0.0:0
-```
-
-You can also specify `:pool=<POOL>:inode=<INODE>:size=<SIZE>` instead of `:image=<IMAGE>`,
-just like in qemu-img.
-
-### Remove inode
-
-Use vitastor-rm / vitastor-cli rm-data. For example:
-
-```
-vitastor-cli rm-data --etcd_address 10.115.0.10:2379/v3 --pool 1 --inode 1 --parallel_osds 16 --iodepth 32
-```
-
-### NBD
-
-To create a local block device for a Vitastor image, use NBD. For example:
-
-```
-vitastor-nbd map --etcd_address 10.115.0.10:2379/v3 --image testimg
-```
-
-It will output the device name, like /dev/nbd0 which you can then format and mount as a normal block device.
-
-Again, you can use `--pool <POOL> --inode <INODE> --size <SIZE>` insteaf of `--image <IMAGE>` if you want.
-
-### NFS
-
-Vitastor has a simplified NFS 3.0 proxy for file-based image access emulation. It's not
-suitable as a full-featured file system, at least because all file/image metadata is stored
-in etcd and kept in memory all the time - thus you can't put a lot of files in it.
-
-However, NFS proxy is totally fine as a method to provide VM image access and allows to
-plug Vitastor into, for example, VMWare. It's important to note that for VMWare it's a much
-better access method than iSCSI, because with iSCSI we'd have to put all VM images into one
-Vitastor image exported as a LUN to VMWare and formatted with VMFS. VMWare doesn't use VMFS
-over NFS.
-
-NFS proxy is stateless if you use immediate_commit=all mode (for SSD with capacitors or
-HDDs with disabled cache), so you can run multiple NFS proxies and use a network load
-balancer or any failover method you want to in that case.
-
-vitastor-nfs usage:
-
-```
-vitastor-nfs [--etcd_address ADDR] [OTHER OPTIONS]
-
--subdir <DIR>    export images prefixed <DIR>/ (default empty - export all images)
--portmap 0       do not listen on port 111 (portmap/rpcbind, requires root)
--bind <IP>       bind service to <IP> address (default 0.0.0.0)
--nfspath <PATH>  set NFS export path to <PATH> (default is /)
--port <PORT>     use port <PORT> for NFS services (default is 2049)
--pool <POOL>     use <POOL> as default pool for new files (images)
--foreground 1    stay in foreground, do not daemonize
-```
-
-Example start and mount commands:
-
-```
-vitastor-nfs --etcd_address 192.168.5.10:2379 --portmap 0 --port 2050 --pool testpool
-```
-
-```
-mount localhost:/ /mnt/ -o port=2050,mountport=2050,nfsvers=3,soft,nolock,tcp
-```
-
-### Kubernetes
-
-Vitastor has a CSI plugin for Kubernetes which supports RWO (and block RWX) volumes.
-
-To deploy it, take manifests from [csi/deploy/](csi/deploy/) directory, put your
-Vitastor configuration in [csi/deploy/001-csi-config-map.yaml](001-csi-config-map.yaml),
-configure storage class in [csi/deploy/009-storage-class.yaml](009-storage-class.yaml)
-and apply all `NNN-*.yaml` manifests to your Kubernetes installation:
-
-```
-for i in ./???-*.yaml; do kubectl apply -f $i; done
-```
-
-After that you'll be able to create PersistentVolumes. See example in [csi/deploy/example-pvc.yaml](csi/deploy/example-pvc.yaml).
-
-### OpenStack
-
-To enable Vitastor support in an OpenStack installation:
-
- Install vitastor-client, patched QEMU and libvirt packages from Vitastor DEB or RPM repository
- Use `patches/nova-21.diff` or `patches/nova-23.diff` to patch your Nova installation.
-  Patch 21 fits Nova 21-22, patch 23 fits Nova 23-24.
- Install `patches/cinder-vitastor.py` as `..../cinder/volume/drivers/vitastor.py`
- Define a volume type in cinder.conf (see below)
- Block network access from VMs to Vitastor network (to OSDs and etcd), because Vitastor doesn't support authentication (yet)
- Restart Cinder and Nova
-
-Cinder volume type configuration example:
-
-```
-[DEFAULT]
-enabled_backends = lvmdriver-1, vitastor-testcluster
-# ...
-
-[vitastor-testcluster]
-volume_driver = cinder.volume.drivers.vitastor.VitastorDriver
-volume_backend_name = vitastor-testcluster
-image_volume_cache_enabled = True
-volume_clear = none
-vitastor_etcd_address = 192.168.7.2:2379
-vitastor_etcd_prefix =
-vitastor_config_path = /etc/vitastor/vitastor.conf
-vitastor_pool_id = 1
-image_upload_use_cinder_backend = True
-```
-
-To put Glance images in Vitastor, use [https://docs.openstack.org/cinder/pike/admin/blockstorage-volume-backed-image.html](volume-backed images),
-although the support has not been verified yet.
-
-### Proxmox
-
-To enable Vitastor support in Proxmox Virtual Environment (6.4 and 7.1 are supported):
-
- Add the corresponding Vitastor Debian repository into sources.list on Proxmox hosts
-  (buster for 6.4, bullseye for 7.1)
- Install vitastor-client, pve-qemu-kvm, pve-storage-vitastor (* or see note) packages from Vitastor repository
- Define storage in `/etc/pve/storage.cfg` (see below)
- Block network access from VMs to Vitastor network (to OSDs and etcd), because Vitastor doesn't support authentication (yet)
- Restart pvedaemon: `systemctl restart pvedaemon`
-
-`/etc/pve/storage.cfg` example (the only required option is vitastor_pool, all others
-are listed below with their default values):
-
-```
-vitastor: vitastor
-    # pool to put new images into
-    vitastor_pool testpool
-    # path to the configuration file
-    vitastor_config_path /etc/vitastor/vitastor.conf
-    # etcd address(es), required only if missing in the configuration file
-    vitastor_etcd_address 192.168.7.2:2379/v3
-    # prefix for keys in etcd
-    vitastor_etcd_prefix /vitastor
-    # prefix for images
-    vitastor_prefix pve/
-    # use NBD mounter (only required for containers)
-    vitastor_nbd 0
-```
-
-\* Note: you can also manually copy [patches/PVE_VitastorPlugin.pm](patches/PVE_VitastorPlugin.pm) to Proxmox hosts
-as `/usr/share/perl5/PVE/Storage/Custom/VitastorPlugin.pm` instead of installing pve-storage-vitastor.
-
-## Known Problems
-
- Object deletion requests may currently lead to 'incomplete' objects in EC pools
-  if your OSDs crash during deletion because proper handling of object cleanup
-  in a cluster should be "three-phase" and it's currently not implemented.
-  Just repeat the removal request again in this case.
-
-## Implementation Principles
-
- I like architecturally simple solutions. Vitastor is and will always be designed
-  exactly like that.
- I also like reinventing the wheel to some extent, like writing my own HTTP client
-  for etcd interaction instead of using prebuilt libraries, because in this case
-  I'm confident about what my code does and what it doesn't do.
- I don't care about C++ "best practices" like RAII or proper inheritance or usage of
-  smart pointers or whatever and I don't intend to change my mind, so if you're here
-  looking for ideal reference C++ code, this probably isn't the right place.
- I like node.js better than any other dynamically-typed language interpreter
-  because it's faster than any other interpreter in the world, has neutral C-like
-  syntax and built-in event loop. That's why Monitor is implemented in node.js.
+Make Clustered Block Storage Fast Again.
+
+Vitastor is a distributed block SDS, direct replacement of Ceph RBD and internal SDS's
+of public clouds. However, in contrast to them, Vitastor is fast and simple at the same time.
+The only thing is it's slightly young :-).
+
+Vitastor is architecturally similar to Ceph which means strong consistency,
+primary-replication, symmetric clustering and automatic data distribution over any
+number of drives of any size with configurable redundancy (replication or erasure codes/XOR).
+
+Vitastor targets SSD and SSD+HDD clusters with at least 10 Gbit/s network, supports
+TCP and RDMA and may achieve 4 KB read and write latency as low as ~0.1 ms
+with proper hardware which is ~10 times faster than other popular SDS's like Ceph
+or internal systems of public clouds.
+
+Vitastor supports QEMU, NBD, NFS protocols, OpenStack, Proxmox, Kubernetes drivers.
+More drivers may be created easily.
+
+Read more details below in the documentation.
+
+## Talks and presentations
+
+- DevOpsConf'2021: presentation ([in Russian](https://vitastor.io/presentation/devopsconf/devopsconf.html),
+  [in English](https://vitastor.io/presentation/devopsconf/devopsconf_en.html)),
+  [video](https://vitastor.io/presentation/devopsconf/talk.webm)
+- Highload'2022: presentation ([in Russian](https://vitastor.io/presentation/highload/highload.html)),
+  [video](https://vitastor.io/presentation/highload/talk.webm)
+
+## Documentation
+
+- Introduction
+  - [Quick Start](docs/intro/quickstart.en.md)
+  - [Features](docs/intro/features.en.md)
+  - [Architecture](docs/intro/architecture.en.md)
+  - [Author and license](docs/intro/author.en.md)
+- Installation
+  - [Packages](docs/installation/packages.en.md)
+  - [Proxmox](docs/installation/proxmox.en.md)
+  - [OpenStack](docs/installation/openstack.en.md)
+  - [Kubernetes CSI](docs/installation/kubernetes.en.md)
+  - [Building from Source](docs/installation/source.en.md)
+- Configuration
+  - [Overview](docs/config.en.md)
+  - Parameter Reference
+    - [Common](docs/config/common.en.md)
+    - [Network](docs/config/network.en.md)
+    - [Global Disk Layout](docs/config/layout-cluster.en.md)
+    - [OSD Disk Layout](docs/config/layout-osd.en.md)
+    - [OSD Runtime Parameters](docs/config/osd.en.md)
+    - [Monitor](docs/config/monitor.en.md)
+  - [Pool configuration](docs/config/pool.en.md)
+  - [Image metadata in etcd](docs/config/inode.en.md)
+- Usage
+  - [vitastor-cli](docs/usage/cli.en.md) (command-line interface)
+  - [fio](docs/usage/fio.en.md) for benchmarks
+  - [NBD](docs/usage/nbd.en.md) for kernel mounts
+  - [QEMU and qemu-img](docs/usage/qemu.en.md)
+  - [NFS](docs/usage/nfs.en.md) emulator for VMWare and similar
+- Performance
+  - [Understanding storage performance](docs/performance/understanding.en.md)
+  - [Theoretical performance](docs/performance/theoretical.en.md)
+  - [Example comparison with Ceph](docs/performance/comparison1.en.md)

 ## Author and License

--- a/docs/config.en.md
+++ b/docs/config.en.md
@ -0,0 +1,38 @@
+[Documentation](../README.md#documentation) → Configuration Reference
+
+-----
+
+[Читать на русском](config.ru.md)
+
+# Configuration Reference
+
+Vitastor configuration consists of:
+- Configuration parameters (key-value), described here
+- [Pool configuration](config/pool.en.md)
+- OSD placement tree configuration
+- [Inode configuration](config/inode.en.md) i.e. image metadata like name, size and parent reference
+
+Configuration parameters can be set in 3 places:
+- Configuration file (`/etc/vitastor/vitastor.conf` or other path)
+- etcd key `/vitastor/config/global`. Most variables can be set there, but etcd
+  connection parameters should obviously be set in the configuration file.
+- Command line of Vitastor components: OSD, mon, fio and QEMU options,
+  OpenStack/Proxmox/etc configuration. The latter doesn't allow to set all
+  variables directly, but it allows to override the configuration file and
+  set everything you need inside it.
+
+In the future, additional configuration methods may be added:
+- OSD superblock which will, by design, contain parameters related to the disk
+  layout and to one specific OSD.
+- OSD-specific keys in etcd like `/vitastor/config/osd/<number>`.
+
+## Parameter Reference
+
+- [Common](config/common.en.md)
+- [Network](config/network.en.md)
+- [Global Disk Layout](config/layout-cluster.en.md)
+- [OSD Disk Layout](config/layout-osd.en.md)
+- [OSD Runtime Parameters](config/osd.en.md)
+- [Monitor](config/monitor.en.md)
+- [Pool configuration](config/pool.en.md)
+- [Inode metadata in etcd](docs/config/inode.en.md)
--- a/docs/config.ru.md
+++ b/docs/config.ru.md
@ -0,0 +1,39 @@
+[Документация](../README-ru.md#документация) → Конфигурация Vitastor
+
+-----
+
+[Read in English](config.en.md)
+
+# Конфигурация Vitastor
+
+Конфигурация Vitastor состоит из:
+- Параметров (ключ-значение), описанных на данной странице
+- [Настроек пулов](config/pool.ru.md)
+- Настроек дерева OSD
+- [Настроек инодов](config/inode.ru.md), т.е. метаданных образов, таких, как имя, размер и ссылки на
+  родительский образ
+
+Параметры конфигурации могут задаваться в 3 местах:
+- Файле конфигурации (`/etc/vitastor/vitastor.conf` или по другому пути)
+- Ключе в etcd `/vitastor/config/global`. Большая часть параметров может
+  задаваться там, кроме, естественно, самих параметров соединения с etcd,
+  которые должны задаваться в файле конфигурации
+- В командной строке компонентов Vitastor: OSD, монитора, опциях fio и QEMU,
+  настроек OpenStack, Proxmox и т.п. Последние, как правило, не включают полный
+  набор параметров напрямую, но разрешают определить путь к файлу конфигурации
+  и задать любые параметры в нём.
+
+В будущем также могут быть добавлены другие способы конфигурации:
+- Суперблок OSD, в котором будут храниться параметры OSD, связанные с дисковым
+  форматом и с этим конкретным OSD.
+- OSD-специфичные ключи в etcd типа `/vitastor/config/osd/<номер>`.
+
+## Список параметров
+
+- [Общие](config/common.ru.md)
+- [Сеть](config/network.ru.md)
+- [Глобальные дисковые параметры](config/layout-cluster.ru.md)
+- [Дисковые параметры OSD](config/layout-osd.ru.md)
+- [Прочие параметры OSD](config/osd.ru.md)
+- [Параметры мониторов](config/monitor.ru.md)
+- [Настройки пулов](config/pool.ru.md)
--- a/docs/config/common.en.md
+++ b/docs/config/common.en.md
@ -0,0 +1,46 @@
+[Documentation](../../README.md#documentation) → [Configuration](../config.en.md) → Common Parameters
+
+-----
+
+[Читать на русском](common.ru.md)
+
+# Common Parameters
+
+These are the most common parameters which apply to all components of Vitastor.
+
+- [config_path](#config_path)
+- [etcd_address](#etcd_address)
+- [etcd_prefix](#etcd_prefix)
+- [log_level](#log_level)
+
+## config_path
+
+- Type: string
+- Default: /etc/vitastor/vitastor.conf
+
+Path to the JSON configuration file. Configuration file is optional,
+a non-existing configuration file does not prevent Vitastor from
+running if required parameters are specified.
+
+## etcd_address
+
+- Type: string or array of strings
+
+etcd connection endpoint(s). Multiple endpoints may be delimited by "," or
+specified in a JSON array `["10.0.115.10:2379/v3","10.0.115.11:2379/v3"]`.
+Note that https is not supported for etcd connections yet.
+
+## etcd_prefix
+
+- Type: string
+- Default: /vitastor
+
+Prefix for all keys in etcd used by Vitastor. You can change prefix and, for
+example, use a single etcd cluster for multiple Vitastor clusters.
+
+## log_level
+
+- Type: integer
+- Default: 0
+
+Log level. Raise if you want more verbose output.
--- a/docs/config/common.ru.md
+++ b/docs/config/common.ru.md
@ -0,0 +1,45 @@
+[Документация](../../README-ru.md#документация) → [Конфигурация](../config.ru.md) → Общие параметры
+
+-----
+
+[Read in English](common.en.md)
+
+# Общие параметры
+
+Это наиболее общие параметры, используемые всеми компонентами Vitastor.
+
+- [config_path](#config_path)
+- [etcd_address](#etcd_address)
+- [etcd_prefix](#etcd_prefix)
+- [log_level](#log_level)
+
+## config_path
+
+- Тип: строка
+- Значение по умолчанию: /etc/vitastor/vitastor.conf
+
+Путь к файлу конфигурации в формате JSON. Файл конфигурации необязателен,
+без него Vitastor тоже будет работать, если переданы необходимые параметры.
+
+## etcd_address
+
+- Тип: строка или массив строк
+
+Адрес(а) подключения к etcd. Несколько адресов могут разделяться запятой
+или указываться в виде JSON-массива `["10.0.115.10:2379/v3","10.0.115.11:2379/v3"]`.
+
+## etcd_prefix
+
+- Тип: строка
+- Значение по умолчанию: /vitastor
+
+Префикс для ключей etcd, которые использует Vitastor. Вы можете задать другой
+префикс, например, чтобы запустить несколько кластеров Vitastor с одним
+кластером etcd.
+
+## log_level
+
+- Тип: целое число
+- Значение по умолчанию: 0
+
+Уровень логгирования. Повысьте, если хотите более подробный вывод.
--- a/docs/config/inode.en.md
+++ b/docs/config/inode.en.md
@ -0,0 +1,32 @@
+[Documentation](../../README.md#documentation) → [Configuration](../config.en.md) → Image metadata in etcd
+
+-----
+
+[Читать на русском](inode.ru.md)
+
+# Image metadata in etcd
+
+Image list is stored in etcd in `/vitastor/config/inode/<pool>/<inode>` keys.
+
+You can even create images manually: