Update cinder driver workaround

.gitea/workflows/buildenv.Dockerfile

@@ -1,36 +0,0 @@
-FROM node:16-bullseye
-
-WORKDIR /root
-
-ADD ./docker/vitastor.gpg /etc/apt/trusted.gpg.d
-
-RUN echo 'deb http://deb.debian.org/debian bullseye-backports main' >> /etc/apt/sources.list; \
-    echo 'deb http://vitastor.io/debian bullseye main' >> /etc/apt/sources.list; \
-    echo >> /etc/apt/preferences; \
-    echo 'Package: *' >> /etc/apt/preferences; \
-    echo 'Pin: release a=bullseye-backports' >> /etc/apt/preferences; \
-    echo 'Pin-Priority: 500' >> /etc/apt/preferences; \
-    echo >> /etc/apt/preferences; \
-    echo 'Package: *' >> /etc/apt/preferences; \
-    echo 'Pin: origin "vitastor.io"' >> /etc/apt/preferences; \
-    echo 'Pin-Priority: 1000' >> /etc/apt/preferences; \
-    grep '^deb ' /etc/apt/sources.list | perl -pe 's/^deb/deb-src/' >> /etc/apt/sources.list; \
-    echo 'APT::Install-Recommends false;' >> /etc/apt/apt.conf; \
-    echo 'APT::Install-Suggests false;' >> /etc/apt/apt.conf
-
-RUN apt-get update
-RUN apt-get -y install etcd qemu-system-x86 qemu-block-extra qemu-utils fio libasan5 \
-    liburing1 liburing-dev libgoogle-perftools-dev devscripts libjerasure-dev cmake libibverbs-dev libisal-dev
-RUN apt-get -y build-dep fio qemu=`dpkg -s qemu-system-x86|grep ^Version:|awk '{print $2}'`
-RUN apt-get update && apt-get -y install jq lp-solve sudo nfs-common fdisk parted
-RUN apt-get --download-only source fio qemu=`dpkg -s qemu-system-x86|grep ^Version:|awk '{print $2}'`
-
-RUN set -ex; \
-    mkdir qemu-build; \
-    cd qemu-build; \
-    dpkg-source -x /root/qemu*.dsc; \
-    cd qemu*/; \
-    debian/rules configure-qemu || debian/rules b/configure-stamp; \
-    cd b/qemu; \
-    make -j8 config-poison.h || true; \
-    make -j8 qapi/qapi-builtin-types.h

.gitea/workflows/test.Dockerfile

@@ -1,19 +0,0 @@
-FROM git.yourcmc.ru/vitalif/vitastor/buildenv
-
-ADD . /root/vitastor
-
-RUN set -e -x; \
-    mkdir -p /root/fio-build/; \
-    cd /root/fio-build/; \
-    dpkg-source -x /root/fio*.dsc; \
-    cd /root/vitastor; \
-    ln -s /root/fio-build/fio-*/ ./fio; \
-    ln -s /root/qemu-build/qemu-*/ ./qemu; \
-    ls /usr/include/linux/raw.h || cp ./debian/raw.h /usr/include/linux/raw.h; \
-    cd mon; \
-    npm install; \
-    cd ..; \
-    mkdir build; \
-    cd build; \
-    cmake .. -DWITH_ASAN=yes -DWITH_QEMU=yes; \
-    make -j16

.gitea/workflows/tests-to-yaml.pl

@@ -1,83 +0,0 @@
-#!/usr/bin/perl
-
-use strict;
-
-for my $line (<>)
-{
-    if ($line =~ /\.\/(test_[^\.]+)/s)
-    {
-        chomp $line;
-        my $base_name = $1;
-        my $test_name = $base_name;
-        my $timeout = 3;
-        if ($test_name eq 'test_etcd_fail' || $test_name eq 'test_heal' || $test_name eq 'test_add_osd' ||
-            $test_name eq 'test_interrupted_rebalance' || $test_name eq 'test_rebalance_verify')
-        {
-            $timeout = 10;
-        }
-        while ($line =~ /([^\s=]+)=(\S+)/gs)
-        {
-            if ($1 eq 'TEST_NAME')
-            {
-                $test_name = $base_name.'_'.$2;
-                last;
-            }
-            elsif ($1 eq 'SCHEME' && $2 eq 'ec')
-            {
-                $test_name .= '_ec';
-            }
-            elsif ($1 eq 'SCHEME' && $2 eq 'xor')
-            {
-                $test_name .= '_xor';
-            }
-            elsif ($1 eq 'IMMEDIATE_COMMIT')
-            {
-                $test_name .= '_imm';
-            }
-            elsif ($1 eq 'ANTIETCD')
-            {
-                $test_name .= '_antietcd';
-            }
-            else
-            {
-                $test_name .= '_'.lc($1).'_'.$2;
-            }
-        }
-        if ($test_name eq 'test_snapshot_chain_ec')
-        {
-            $timeout = 6;
-        }
-        $line =~ s!\./test_!/root/vitastor/tests/test_!;
-        # Gitea CI doesn't support artifacts yet, lol
-        #- name: Upload results
-        #  uses: actions/upload-artifact\@v3
-        #  if: always()
-        #  with:
-        #    name: ${test_name}_result
-        #    path: |
-        #      /root/vitastor/testdata
-        #      !/root/vitastor/testdata/*.bin
-        #    retention-days: 5
-        print <<"EOF"
-  $test_name:
-    runs-on: ubuntu-latest
-    needs: build
-    container: \${{env.TEST_IMAGE}}:\${{github.sha}}
-    steps:
-    - name: Run test
-      id: test
-      timeout-minutes: $timeout
-      run: $line
-    - name: Print logs
-      if: always() && steps.test.outcome == 'failure'
-      run: |
-        for i in /root/vitastor/testdata/*.log /root/vitastor/testdata/*.txt; do
-          echo "-------- \$i --------"
-          cat \$i
-          echo ""
-        done
-
-EOF
-;
-    }
-}

.gitignore

@@ -3,3 +3,16 @@
 package-lock.json
 fio
 qemu
+osd
+stub_osd
+stub_uring_osd
+stub_bench
+osd_test
+osd_peering_pg_test
+dump_journal
+nbd_proxy
+rm_inode
+test_allocator
+test_blockstore
+test_shit
+osd_rmw_test

CLA-en.md

@@ -1,115 +0,0 @@
-## Contributor License Agreement
-
-> This Agreement is made in the Russian and English languages. **The English
-text of Agreement is for informational purposes only** and is not binding
-for the Parties.
->
-> In the event of a conflict between the provisions of the Russian and
-English versions of this Agreement, the **Russian version shall prevail**.
->
-> Russian version is published at https://git.yourcmc.ru/vitalif/vitastor/src/branch/master/CLA-ru.md
-
-This document represents the offer of Filippov Vitaliy Vladimirovich
-("Author"), author and copyright holder of Vitastor software ("Program"),
-acknowledged by a certificate of Federal Service for Intellectual
-Property of Russian Federation (Rospatent) # 2021617829 dated 20 May 2021,
-to "Contributors" to conclude this license agreement as follows
-("Agreement" or "Offer").
-
-In accordance with Art. 435, Art. 438 of the Civil Code of the Russian
-Federation, this Agreement is an offer and in case of acceptance of the
-offer, an agreement is considered concluded on the conditions specified
-in the offer.
-
-1. Applicable Terms. \
-   1.1. "Official Repository" shall mean the computer storage, operated by
-        the Author, containing all prior and future versions of the Source
-        Code of the Program, at Internet addresses https://git.yourcmc.ru/vitalif/vitastor/
-        or https://github.com/vitalif/vitastor/. \
-   1.2. "Contributions" shall mean results of intellectual activity
-        (including, but not limited to, source code, libraries, components,
-        texts, documentation) which can be software or elements of the software
-        and which are provided by Contributors to the Author for inclusion
-        in the Program. \
-   1.3. "Contributor" shall mean a person who provides Contributions to
-        the Author and agrees with all provisions of this Agreement.
-        A Сontributor can be: 1) an individual; or 2) a legal entity or an
-        individual entrepreneur in case when an individual provides Contributions
-        on behalf of third parties, including on behalf of his employer.
-
-2. Subject of the Agreement. \
-   2.1. Subject of the Agreement shall be the Contributions sent to the Author by Contributors. \
-   2.2. The Contributor grants to the Author the right to use Contributions at his own
-        discretion and without any necessity to get a prior approval from Contributor or
-        any other third party in any way, under a simple (non-exclusive), royalty-free,
-        irrevocable license throughout the world by all means not contrary to law, in whole
-        or as a part of the Program, or other open-source or closed-source computer programs,
-        products or services (hereinafter -- the "License"), including, but not limited to: \
-        2.2.1. to execute Contributions and use them for any tasks; \
-        2.2.2. to publish and distribute Contributions in modified or unmodified form and/or to rent them; \
-        2.2.3. to modify Contributions, add comments, illustrations or any explanations to Contributions while using them; \
-        2.2.4. to create other results of intellectual activity based on Contributions, including derivative works and composite works; \
-        2.2.5. to translate Contributions into other languages, including other programming languages; \
-        2.2.6. to carry out rental and public display of Contributions; \
-        2.2.7. to use Contributions under the trade name and/or any trademark or any other label, or without it, as the Author thinks fit; \
-   2.3. The Contributor grants to the Author the right to sublicense any of the aforementioned
-        rights to third parties on any terms at the Author's discretion. \
-   2.4. The License is provided for the entire duration of Contributor's
-        exclusive intellectual property rights to the Contributions. \
-   2.5. The Contributor grants to the Author the right to decide how and where to mention,
-        or to not mention at all, the fact of his authorship, name, nickname and/or company
-        details when including Contributions into the Program or in any other computer
-        programs, products or services.
-
-3. Acceptance of the Offer \
-   3.1. The Contributor may provide Contributions to the Author in the form of
-        a "Pull Request" in an Official Repository of the Program or by any
-        other electronic means of communication, including, but not limited to,
-        E-mail or messenger applications. \
-   3.2. The acceptance of the Offer shall be the fact of provision of Contributions
-        to the Author by the Contributor by any means with the following remark:
-        “I accept Vitastor CLA agreement: https://git.yourcmc.ru/vitalif/vitastor/src/branch/master/CLA-en.md”
-        or “Я принимаю соглашение Vitastor CLA: https://git.yourcmc.ru/vitalif/vitastor/src/branch/master/CLA-ru.md”. \
-   3.3. Date of acceptance of the Offer shall be the date of such provision.
-
-4. Rights and obligations of the parties. \
-   4.1. The Contributor reserves the right to use Contributions by any lawful means
-        not contrary to this Agreement. \
-   4.2. The Author has the right to refuse to include Contributions into the Program
-        at any moment with no explanation to the Contributor.
-
-5. Representations and Warranties. \
-   5.1. The person providing Contributions for the purpose of their inclusion
-        in the Program represents and warrants that he is the Contributor
-        or legally acts on the Contributor's behalf. Name or company details
-        of the Contributor shall be provided with the Contribution at the moment
-        of their provision to the Author. \
-   5.2. The Contributor represents and warrants that he legally owns exclusive
-        intellectual property rights to the Contributions. \
-   5.3. The Contributor represents and warrants that any further use of
-        Contributions by the Author as provided by Contributor under the terms
-        of the Agreement does not infringe on intellectual and other rights and
-        legitimate interests of third parties. \
-   5.4. The Contributor represents and warrants that he has all rights and legal
-        capacity needed to accept this Offer; \
-   5.5. The Contributor represents and warrants that Contributions don't
-        contain malware or any information considered illegal under the law
-        of Russian Federation.
-
-6. Termination of the Agreement \
-   6.1. The Agreement may be terminated at will of both Author and Contributor,
-        formalised in the written form or if the Agreement is terminated on
-        reasons prescribed by the law of Russian Federation.
-
-7. Final Clauses \
-   7.1. The Contributor may optionally sign the Agreement in the written form. \
-   7.2. The Agreement is deemed to become effective from the Date of signing of
-        the Agreement and until the expiration of Contributor's exclusive
-        intellectual property rights to the Contributions. \
-   7.3. The Author may unilaterally alter the Agreement without informing Contributors.
-        The new version of the document shall come into effect 3 (three) days after
-        being published in the Official Repository of the Program at Internet address
-        [https://git.yourcmc.ru/vitalif/vitastor/src/branch/master/CLA-en.md](https://git.yourcmc.ru/vitalif/vitastor/src/branch/master/CLA-en.md).
-        Contributors should keep informed about the actual version of the Agreement themselves. \
-   7.4. If the Author and the Contributor fail to agree on disputable issues,
-        disputes shall be referred to the Moscow Arbitration court.

CLA-ru.md

@@ -1,108 +0,0 @@
-## Лицензионное соглашение с участником
-
-> Данная Оферта написана в Русской и Английской версиях. **Версия на английском
-языке предоставляется в информационных целях** и не связывает стороны договора.
->
-> В случае несоответствий между положениями Русской и Английской версий Договора,
-**Русская версия имеет приоритет**.
->
-> Английская версия опубликована по адресу https://git.yourcmc.ru/vitalif/vitastor/src/branch/master/CLA-en.md
-
-Настоящий договор-оферта (далее по тексту – Оферта, Договор) адресована физическим
-и юридическим лицам (далее – Участникам) и является официальным публичным предложением
-Филиппова Виталия Владимировича (далее – Автора) программного обеспечения Vitastor,
-свидетельство Федеральной службы по интеллектуальной собственности (Роспатент) № 2021617829
-от 20 мая 2021 г. (далее – Программа) о нижеследующем:
-
-1. Термины и определения \
-   1.1. Репозиторий – электронное хранилище, содержащее исходный код Программы. \
-   1.2. Доработка – результат интеллектуальной деятельности Участника, включающий
-        в себя изменения или дополнения к исходному коду Программы, которые Участник
-        желает включить в состав Программы для дальнейшего использования и распространения
-        Автором и для этого направляет их Автору. \
-   1.3. Участник – физическое или юридическое лицо, вносящее Доработки в код Программы. \
-   1.4. ГК РФ – Гражданский кодекс Российской Федерации.
-
-2. Предмет оферты \
-   2.1. Предметом настоящей оферты являются Доработки, отправляемые Участником Автору. \
-   2.2. Участник предоставляет Автору право использовать Доработки по собственному усмотрению
-        и без необходимости предварительного согласования с Участником или иным третьим лицом
-        на условиях простой (неисключительной) безвозмездной безотзывной лицензии, полностью
-        или фрагментарно, в составе Программы или других программ, продуктов или сервисов
-        как с открытым, так и с закрытым исходным кодом, любыми способами, не противоречащими
-        закону, включая, но не ограничиваясь следующими: \
-        2.2.1. Запускать и использовать Доработки для выполнения любых задач; \
-        2.2.2. Распространять, импортировать и доводить Доработки до всеобщего сведения; \
-        2.2.3. Вносить в Доработки изменения, сокращения и дополнения, снабжать Доработки
-               при их использовании комментариями, иллюстрациями или пояснениями; \
-        2.2.4. Создавать на основе Доработок иные результаты интеллектуальной деятельности,
-               в том числе производные и составные произведения; \
-        2.2.5. Переводить Доработки на другие языки, в том числе на другие языки программирования; \
-        2.2.6. Осуществлять прокат и публичный показ Доработок; \
-        2.2.7. Использовать Доработки под любым фирменным наименованием, товарным знаком
-               (знаком обслуживания) или иным обозначением, или без такового. \
-   2.3. Участник предоставляет Автору право сублицензировать полученные права на Доработки
-        третьим лицам на любых условиях на усмотрение Автора. \
-   2.4. Участник предоставляет Автору права на Доработки на территории всего мира. \
-   2.5. Участник предоставляет Автору права на весь срок действия исключительного права
-        Участника на Доработки. \
-   2.6. Участник предоставляет Автору права на Доработки на безвозмездной основе. \
-   2.7. Участник разрешает Автору самостоятельно определять порядок, способ и
-        место указания его имени, реквизитов и/или псевдонима при включении
-        Доработок в состав Программы или других программ, продуктов или сервисов.
-
-3. Акцепт Оферты \
-   3.1. Участник может передавать Доработки в адрес Автора через зеркала официального
-        Репозитория Программы по адресам https://git.yourcmc.ru/vitalif/vitastor/ или
-        https://github.com/vitalif/vitastor/ в виде “запроса на слияние” (pull request),
-        либо в письменном виде или с помощью любых других электронных средств коммуникации,
-        например, электронной почты или мессенджеров. \
-   3.2. Факт передачи Участником Доработок в адрес Автора любым способом с одной из пометок
-        “I accept Vitastor CLA agreement: https://git.yourcmc.ru/vitalif/vitastor/src/branch/master/CLA-en.md”
-        или “Я принимаю соглашение Vitastor CLA: https://git.yourcmc.ru/vitalif/vitastor/src/branch/master/CLA-ru.md”
-        является полным и безоговорочным акцептом (принятием) Участником условий настоящей
-        Оферты, т.е. Участник считается ознакомившимся с настоящим публичным договором и
-        в соответствии с ГК РФ признается лицом, вступившим с Автором в договорные отношения
-        на основании настоящей Оферты. \
-   3.3. Датой акцептирования настоящей Оферты считается дата такой передачи.
-
-4. Права и обязанности Сторон \
-   4.1. Участник сохраняет за собой право использовать Доработки любым законным
-        способом, не противоречащим настоящему Договору. \
-   4.2. Автор вправе отказать Участнику во включении Доработок в состав
-        Программы без объяснения причин в любой момент по своему усмотрению.
-
-5. Гарантии и заверения \
-   5.1. Лицо, направляющее Доработки для целей их включения в состав Программы,
-        гарантирует, что является Участником или представителем Участника. Имя или реквизиты
-        Участника должны быть указаны при их передаче в адрес Автора Программы. \
-   5.2. Участник гарантирует, что является законным обладателем исключительных прав
-        на Доработки. \
-   5.3. Участник гарантирует, что на момент акцептирования настоящей Оферты ему
-        ничего не известно (и не могло быть известно) о правах третьих лиц на
-        передаваемые Автору Доработки или их часть, которые могут быть нарушены
-        в связи с передачей Доработок по настоящему Договору. \
-   5.4. Участник гарантирует, что является дееспособным лицом и обладает всеми
-        необходимыми правами для заключения Договора. \
-   5.5. Участник гарантирует, что Доработки не содержат вредоносного ПО, а также
-        любой другой информации, запрещённой к распространению по законам Российской
-        Федерации.
-
-6. Прекращение действия оферты \
-   6.1. Действие настоящего договора может быть прекращено по соглашению сторон,
-        оформленному в письменном виде, а также вследствие его расторжения по основаниям,
-        предусмотренным законом.
-
-7. Заключительные положения \
-   7.1. Участник вправе по желанию подписать настоящий Договор в письменном виде. \
-   7.2. Настоящий договор действует с момента его заключения и до истечения срока
-        действия исключительных прав Участника на Доработки. \
-   7.3. Автор имеет право в одностороннем порядке вносить изменения и дополнения в договор
-        без специального уведомления об этом Участников. Новая редакция документа вступает
-        в силу через 3 (Три) календарных дня со дня опубликования в официальном Репозитории
-        Программы по адресу в сети Интернет
-        [https://git.yourcmc.ru/vitalif/vitastor/src/branch/master/CLA-ru.md](https://git.yourcmc.ru/vitalif/vitastor/src/branch/master/CLA-ru.md).
-        Участники самостоятельно отслеживают действующие условия Оферты. \
-   7.4. Все споры, возникающие между сторонами в процессе их взаимодействия по настоящему
-        договору, решаются путём переговоров. В случае невозможности урегулирования споров
-        переговорным порядком стороны разрешают их в Арбитражном суде г.Москвы.

CMakeLists.txt

@@ -1,7 +1,7 @@
-cmake_minimum_required(VERSION 2.8.12)
+cmake_minimum_required(VERSION 2.8)
 
 project(vitastor)
 
-set(VITASTOR_VERSION "1.9.3")
+set(VERSION "0.6.10")
 
 add_subdirectory(src)

README-ru.md

@@ -1,76 +1,631 @@
-# Vitastor
+## Vitastor
 
 [Read English version](README.md)
 
 ## Идея
 
-Вернём былую скорость кластерному блочному хранилищу!
+Я всего лишь хочу сделать качественную блочную SDS!
 
-Vitastor - распределённая блочная и файловая SDS (программная СХД), прямой аналог Ceph RBD и CephFS,
-а также внутренних СХД популярных облачных провайдеров. Однако, в отличие от них, Vitastor
-быстрый и при этом простой. Только пока маленький :-).
+Vitastor - распределённая блочная SDS, прямой аналог Ceph RBD и внутренних СХД популярных
+облачных провайдеров. Однако, в отличие от них, Vitastor быстрый и при этом простой.
+Только пока маленький :-).
 
-Vitastor архитектурно похож на Ceph, что означает атомарность и строгую консистентность,
+Архитектурная схожесть с Ceph означает заложенную на уровне алгоритмов записи строгую консистентность,
 репликацию через первичный OSD, симметричную кластеризацию без единой точки отказа
 и автоматическое распределение данных по любому числу дисков любого размера с настраиваемыми схемами
 избыточности - репликацией или с произвольными кодами коррекции ошибок.
 
-Vitastor нацелен в первую очередь на SSD и SSD+HDD кластеры с как минимум 10 Гбит/с сетью, поддерживает
-TCP и RDMA и на хорошем железе может достигать задержки 4 КБ чтения и записи на уровне ~0.1 мс,
-что примерно в 10 раз быстрее, чем Ceph и другие популярные программные СХД.
+## Возможности
 
-Vitastor поддерживает QEMU-драйвер, протоколы NBD и NFS, драйверы OpenStack, OpenNebula, Proxmox, Kubernetes.
-Другие драйверы могут также быть легко реализованы.
+Vitastor на данный момент находится в статусе предварительного выпуска, расширенные
+возможности пока отсутствуют, а в будущих версиях вероятны "ломающие" изменения.
 
-Подробности смотрите в документации по ссылкам. Можете начать отсюда: [Быстрый старт](docs/intro/quickstart.ru.md).
+Однако следующее уже реализовано:
 
-## Презентации и записи докладов
+- Базовая часть - надёжное кластерное блочное хранилище без единой точки отказа
+- Производительность ;-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
 
-- 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)
+## Планы развития
 
-## Документация
+- Поддержка удаления снапшотов (слияния слоёв)
+- Более корректные скрипты разметки дисков и автоматического запуска OSD
+- Другие инструменты администрирования
+- Плагины для OpenNebula и других облачных систем
+- iSCSI-прокси
+- Более быстрое переключение при отказах
+- Фоновая проверка целостности без контрольных сумм (сверка реплик)
+- Контрольные суммы
+- Поддержка SSD-кэширования (tiered storage)
+- Поддержка NVDIMM
+- Web-интерфейс
+- Возможно, сжатие
+- Возможно, поддержка кэширования данных через системный page cache
 
-- Введение
-  - [Быстрый старт](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)
-  - [OpenNebula](docs/installation/opennebula.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/client.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) (консольный интерфейс)
-  - [vitastor-disk](docs/usage/disk.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) кластерная файловая система и псевдо-ФС прокси
-  - [Администрирование](docs/usage/admin.ru.md)
-- Производительность
-  - [Понимание сути производительности](docs/performance/understanding.ru.md)
-  - [Теоретический максимум](docs/performance/theoretical.ru.md)
-  - [Пример сравнения с Ceph](docs/performance/comparison1.ru.md)
-  - [Более новый тест Vitastor 1.3.1](docs/performance/bench2.ru.md)
+## Архитектура
+
+Так же, как и в 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_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"
+  }
+  ```
+- Создайте юниты systemd для OSD: `/usr/lib/vitastor/make-osd.sh /dev/disk/by-partuuid/XXX [/dev/disk/by-partuuid/YYY ...]`
+- Вы можете менять параметры 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: `systemctl start etcd`
+- Создайте глобальную конфигурацию в 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`.
+
+### Kubernetes
+
+У Vitastor есть CSI-плагин для Kubernetes, поддерживающий RWO-тома.
+
+Для установки возьмите манифесты из директории [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-подобный язык программирования и развитую инфраструктуру.
 
 ## Автор и лицензия
 
@@ -101,5 +656,5 @@ Vitastor Network Public License 1.1, основанная на GNU GPL 3.0 с д
 и также на условиях GNU GPL 2.0 или более поздней версии. Так сделано в целях
 совместимости с таким ПО, как QEMU и fio.
 
-Вы можете найти полный текст VNPL 1.1 на английском языке в файле [VNPL-1.1.txt](VNPL-1.1.txt),
-VNPL 1.1 на русском языке в файле [VNPL-1.1-RU.txt](VNPL-1.1-RU.txt), а GPL 2.0 в файле [GPL-2.0.txt](GPL-2.0.txt).
+Вы можете найти полный текст VNPL 1.1 в файле [VNPL-1.1.txt](VNPL-1.1.txt),
+а GPL 2.0 в файле [GPL-2.0.txt](GPL-2.0.txt).

README.md

@@ -1,76 +1,579 @@
-# Vitastor
+## Vitastor
 
 [Читать на русском](README-ru.md)
 
 ## The Idea
 
-Make Clustered Block Storage Fast Again.
+Make Software-Defined Block Storage Great Again.
 
-Vitastor is a distributed block and file SDS, direct replacement of Ceph RBD and CephFS,
-and also 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 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).
 
-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).
+## Features
 
-Vitastor targets primarily 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 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:
 
-Vitastor supports QEMU, NBD, NFS protocols, OpenStack, OpenNebula, Proxmox, Kubernetes drivers.
-More drivers may be created easily.
+- 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
 
-Read more details in the documentation. You can start from here: [Quick Start](docs/intro/quickstart.en.md).
+## Roadmap
 
-## Talks and presentations
+- Snapshot deletion (layer merge) support
+- Better OSD creation and auto-start tools
+- Other administrative tools
+- Plugins for OpenNebula, Proxmox 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)
 
-- 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)
+## Architecture
 
-## Documentation
+Similarities:
 
-- 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)
-  - [OpenNebula](docs/installation/opennebula.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)
-    - [Client](docs/config/client.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)
-  - [vitastor-disk](docs/usage/disk.en.md) (disk management tool)
-  - [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) clustered file system and pseudo-FS proxy
-  - [Administration](docs/usage/admin.en.md)
-- 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)
-  - [Newer benchmark of Vitastor 1.3.1](docs/performance/bench2.en.md)
+- 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`
+- 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"
+  }
+  ```
+- Create systemd units for your OSDs: `/usr/lib/vitastor/mon/make-osd.sh /dev/disk/by-partuuid/XXX [/dev/disk/by-partuuid/YYY ...]`
+- 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.
+
+### Kubernetes
+
+Vitastor has a CSI plugin for Kubernetes which supports RWO 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.
 
 ## Author and License
 

VNPL-1.1-RU.txt

@@ -1,680 +0,0 @@
-                СЕТЕВАЯ ПУБЛИЧНАЯ ЛИЦЕНЗИЯ VITASTOR
-                  VITASTOR NETWORK PUBLIC LICENSE
-                   Версия 1.1, от 6 февраля 2021
-
- Автор лицензии: Виталий Филиппов <vitalif@yourcmc.ru>, 2021 год
- Каждый имеет право копировать и распространять точные копии этой
- лицензии, но без внесения изменений.
-
-                            ПРЕАМБУЛА
-
-  Сетевая Публичная Лицензия Vitastor - это свободная "копилефт" лицензия для
-для программного обеспечения (ПО) и других видов произведений, специально
-разработанная, чтобы гарантировать кооперацию с сообществом при разработке
-сетевых приложений.
-
-  Большинство лицензий на программное обеспечение и другие произведения
-спроектированы так, чтобы лишить Вас свободы делиться ими и изменять их.
-Сетевая Публичная Лицензия Vitastor, напротив, разработана с целью
-гарантировать Ваше право распространять и вносить изменения во все версии
-программного обеспечения -- для уверенности, что ПО останется свободным для
-всех пользователей.
-
-  Когда мы говорим о свободном ПО, мы имеем в виду свободу использования, а не
-бесплатность. Свободные лицензии, такие, как Сетевая Публичная Лицензия
-Vitastor, составлены для того, чтобы убедиться, что у Вас есть право
-распространять копии свободного ПО (и взимать плату за них, если Вы хотите),
-что Вы получаете исходные тексты или можете получить их, если захотите, что Вы
-можете изменять программное обеспечение или использовать его части в новых
-свободных программах, и что Вы знаете о своем праве делать всё это.
-
-  Разработчики, использующие Сетевую Публичную Лицензию Vitastor, гарантируют
-Ваши права при помощи следующих мер: (1) закрепляют авторское право на
-программное обеспечение, и (2) предлагают Вам принять условия настоящей
-Лицензии, закрепляющей Ваше право на создание копий, распространение и (или)
-модификацию программного обеспечения.
-
-  Еще одно преимущество защиты свободы всех пользователей заключается в том,
-что улучшения, сделанные в разных версиях программы, при их широком
-распространении становятся доступными для использования другими разработчиками.
-Многие разработчики программного обеспечения воодушевляются этим
-сотрудничеством и пользуются его преимуществами. Однако, если программное
-обеспечение используется на сетевых серверах, данный результат не всегда
-достигается. Генеральная публичная лицензия GNU разрешает создание измененных
-версий и предоставление неограниченного доступа к ним, не делая общедоступным
-их исходный текст. Даже генеральная публичная лицензия GNU Affero разрешает
-использование модифицированной версии свободной программы в закрытой среде, где
-внешние пользователи взаимодействуют с ней только через закрытый промежуточный
-интерфейс (прокси), опять же, без открытия в свободный публичный доступ как
-самой программы, так и прокси.
-
-  Сетевая Публичная Лицензия Vitastor разработана специально, чтобы
-гарантировать, что в таких случаях и модифицированная версия программы, и
-прокси останутся доступными сообществу. Для этого лицензия требует от
-операторов сетевых серверов предоставлять исходный код оригинальной программы,
-а также всех других программ, взаимодействующих с ней на их серверах,
-пользователям этих серверов, на условиях свободных лицензий. Таким образом,
-публичное использование изменённой версии ПО на сервере, прямо или косвенно
-доступном пользователям, даёт пользователям доступ к исходным кодам изменённой
-версии.
-
-  Детальные определения используемых терминов и описание условий копирования,
-распространения и внесения изменений приведены ниже.
-
-                        ТЕРМИНЫ И УСЛОВИЯ
-
-  0. Определения.
-
-  "Настоящая Лицензия" -- версия 1.1 Сетевой Публичной Лицензии Vitastor.
-
-  Под "Авторским правом" понимаются все законы, сходные с авторско-правовыми,
-которые применяются к любым видам работ, например, к топологиям микросхем.
-
-  Термином "Программа" обозначается любое охраноспособное произведение,
-используемое в соответствии с настоящей Лицензией. Лицензиат именуется "Вы".
-"Лицензиаты" и "получатели" могут быть как физическими лицами, так и
-организациями.
-
-  "Внесение изменений" в произведение означает копирование или адаптацию
-произведения целиком или в части, способом, требующим разрешения
-правообладателя, за исключением изготовления его точной копии. Получившееся
-произведение называется "измененной версией" предыдущего произведения или
-произведением, "основанным на" более ранней работе.
-
-  Термином "Лицензионное произведение" обозначается неизмененная Программа или
-произведение, основанное на Программе.
-
-  "Распространение" произведения означает совершение с ним действий, которые
-при отсутствии разрешения сделают Вас прямо или косвенно ответственным за
-нарушение действующего закона об авторском праве, за исключением запуска на
-компьютере или изменения копии, созданной в личных целях. Распространение
-включает в себя копирование, раздачу копий (с изменениями или без них),
-доведение до всеобщего сведения, а в некоторых странах -- и другие действия.
-
-  "Передача" произведения означает любой вид распространения, который позволяет
-другим лицам создавать или получать копии произведения. Обычное взаимодействие
-с пользователем через компьютерную сеть без создания копии передачей не
-является.
-
-  Интерактивный интерфейс пользователя должен отображать "Информация об
-авторском праве", достаточную для того, чтобы (1) обеспечить отображение
-соответствующего уведомления об авторских правах и (2) сообщить пользователю
-о том, что ему не предоставляются никакие гарантии на произведение (за
-исключением явным образом предоставленных гарантий), о том, что лицензиаты
-могут передавать произведение на условиях, описанных в настоящей Лицензии,
-а также о том, как ознакомиться с текстом настоящей Лицензии. Если интерфейс
-предоставляет собой список пользовательских команд или настроек, наподобие
-меню, это требование считается выполненным при наличии явно выделенного
-пункта в таком меню.
-
-  1. Исходный текст.
-
-  Под "Исходным текстом" понимается произведение в форме, которая более всего
-подходит для внесения в него изменений. "Объектным кодом" называется
-произведение в любой иной форме.
-
-  "Стандартный интерфейс" -- интерфейс, который либо является общепринятым
-стандартом, введенным общепризнанным органом по стандартизации, либо, в случае
-интерфейсов, характерных для конкретного языка программирования -- тот,
-который широко используется разработчиками, пишущими программы на этом языке.
-
-  "Системные библиотеки" исполняемого произведения включают в себя то, что не
-относится к произведению в целом и при этом (a) входит в обычный комплект
-Основного компонента, но при этом не является его частью и (b) служит только
-для обеспечения работы с этим Основным компонентом или для реализации
-Стандартного интерфейса, для которого существует общедоступная реализация,
-опубликованная в виде исходного текста. "Основным компонентом" в данном
-контексте назван главный существенный компонент (ядро, оконная система и т.д.)
-определенной операционной системы (если она используется), под управлением
-которой функционирует исполняемое произведение, либо компилятор, используемый
-для создания произведения или интерпретатор объектного кода, используемый для
-его запуска.
-
-  "Полный исходный текст" для произведения в форме объектного кода -- весь
-исходный текст, необходимый для создания, установки и (для исполняемого
-произведения) функционирования объектного кода, а также модификации
-произведения, включая сценарии, контролирующие эти действия. Однако он не
-включает в себя Системные библиотеки, необходимые для функционирования
-произведения, инструменты общего назначения или общедоступные свободные
-программы, которые используются в неизменном виде для выполнения этих
-действий, но не являются частью произведения. Полный исходный текст включает
-в себя, например, файлы описания интерфейса, прилагаемые к файлам исходного
-текста произведения, а также исходные тексты общих библиотек и динамически
-связанных подпрограмм, которые требуются для функционирования произведения
-и разработаны специально для этого, например, для прямой передачи данных
-или управления потоками между этими подпрограммами и другими частями
-произведения. Полный исходный текст не включает в себя то, что пользователи
-могут сгенерировать автоматически из других частей Полного исходного текста.
-Полным исходным текстом для произведения в форме исходных текстов является
-само это произведение.
-
-  2. Основные права.
-
-  Все права, предоставленные на основании настоящей Лицензии, действуют в
-течение срока действия авторских прав на Программу и не могут быть отозваны
-при условии, что сформулированные в ней условия соблюдены. Настоящая Лицензия
-однозначно подтверждает Ваши неограниченные права на запуск неизмененной
-Программы. Настоящая Лицензия распространяется на результаты функционирования
-Лицензионного произведения только в том случае, если они, учитывая их
-содержание, сами являются частью Лицензионного произведения. Настоящая
-Лицензия подтверждает Ваши права на  свободное использование произведения
-или другие аналогичные полномочия, предусмотренные действующим
-законодательством об авторском праве.
-
-  Если Вы не осуществляете обычную передачу Лицензионного произведения, то
-можете как угодно создавать, запускать и распространять его копии до тех пор,
-пока ваша Лицензия сохраняет силу. Вы можете передавать Лицензионные
-произведения третьим лицам исключительно для того, чтобы они внесли в них
-изменения для Вас или предоставили Вам возможность их запуска, при условии,
-что Вы соглашаетесь с условиями настоящей Лицензии при передаче всех
-материалов, авторскими правами на которые Вы не обладаете. Лица, создающие
-или запускающие Лицензионные произведения для Вас, должны делать это
-исключительно от Вашего имени, под Вашим руководством и контролем, на
-условиях, которые запрещают им создание без Вашей санкции каких-либо копий
-материалов, на которые Вы обладаете авторским правом.
-
-  Любая другая передача разрешается исключительно при соблюдении описанных
-ниже условий. Сублицензирование не допускается; раздел 10 делает его не нужным.
-
-  3. Защита прав пользователей от законов, запрещающих обход технических средств.
-
-  Ни одно Лицензионное произведение не должно считаться содержащим эффективные
-технические средства, удовлетворяющие требованиям любого действующего закона,
-принятого для исполнения обязательств, предусмотренных статьей 11 Договора ВОИС
-по авторскому праву от 20 декабря 1996 года или аналогичных законов,
-запрещающих или ограничивающих обход таких технических средств.
-
-  При передаче Лицензионного произведения Вы отказываетесь от всех
-предоставляемых законом полномочий по запрету обхода технических средств,
-используемых авторами в связи с осуществлением их прав, признавая, что такой
-обход находится в рамках осуществления прав на использование Лицензионного
-произведения, предоставленных настоящей Лицензией; также Вы отказываетесь
-от любых попыток ограничить функционирование произведения или внесение в него
-изменений, направленных на реализацию предоставленных Вам законом прав на
-запрет пользователю обхода технических средств.
-
-  4. Передача неизмененных копий.
-
-  Вы можете передавать точные копии исходных текстов Программы в том виде,
-в котором Вы их получили, на любом носителе, при условии, что Вы прилагаете
-к каждой копии соответствующее уведомление об авторских правах способом,
-обеспечивающим ознакомление с ним пользователя; сохраняете все уведомления
-о том, что к тексту применима настоящая Лицензия и любые ограничения,
-добавленные в соответствии с разделом 7; сохраняете все уведомления об
-отсутствии каких-либо гарантий; предоставляете всем получателям вместе с
-Программой копию настоящей Лицензии.
-
-  Вы можете установить любую цену за каждую копию, которую Вы передаете,
-или распространять копии бесплатно; также Вы можете предложить поддержку
-или гарантию за отдельную плату.
-
-  5. Передача измененных исходных текстов.
-
-  Вы можете передавать исходный текст произведения, основанного на Программе,
-или изменений, необходимых для того, чтобы получить его из Программы, на
-условиях, описанных в разделе 4, при соблюдении следующих условий:
-
-    а) Произведение должно содержать уведомления о произведенных Вами
-    изменениях с указанием их даты, сделанные способом, обеспечивающим
-    ознакомление с ними пользователя.
-
-    b) Произведение должно содержать уведомление о том, что оно
-    распространяется на условиях настоящей Лицензии, а также об условиях,
-    добавленных в соответствии с разделом 7, сделанное способом,
-    обеспечивающим ознакомление с ним пользователя. Данное требование имеет
-    приоритет над требованиями раздела 4 "оставлять нетронутыми все
-    уведомления".
-
-    c) Вы должны передать на условиях настоящей Лицензии всю работу целиком
-    любому лицу, которое приобретает копию. Таким образом, настоящая Лицензия
-    вместе с любыми применимыми условиями раздела 7 будет применяться к
-    произведению в целом и всем его частям, независимо от их комплектности.
-    Настоящая Лицензия не дает права на лицензирование произведения на любых
-    других условиях, но это не лишает законной силы такое разрешение, если Вы
-    получили его отдельно.
-
-    d) Если произведение имеет интерактивные пользовательские интерфейсы,
-    каждый из них должен отображать Информацию об авторском праве; однако,
-    если Программа имеет пользовательские интерфейсы, которые не отображают
-    информацию об авторском праве, от Вашего произведения этого также не
-    требуется.
-
-  Включение Лицензионного произведения в подборку на разделе хранения данных
-или на носителе, на котором распространяется произведение, вместе с другими
-отдельными самостоятельными произведениями, которые по своей природе не
-являются переработкой Лицензионного произведения и не объединены с ним,
-например, в программный комплекс, называется "набором", если авторские права
-на подборку не используются для ограничения доступа к ней или законных прав
-её пользователей сверх того, что предусматривают лицензии на отдельные
-произведения. Включение Лицензионного произведения в набор не влечет применения
-положений настоящей Лицензии к остальным его частям.
-
-  6. Передача произведения в формах, не относящихся к исходному тексту.
-
-  Вы можете передавать Лицензионное произведение в виде объектного кода в
-соответствии с положениями разделов 4 и 5, при условии, что Вы также передаете
-машиночитаемый Полный исходный текст в соответствии с условиями настоящей
-Лицензии, одним из следующих способов:
-
-    а) Передавая объектный код или содержащий его материальный продукт (включая
-    распределенный материальный носитель), с приложением Полного исходного
-    текста наматериальном носителе, обычно используемом для обмена программным
-    обеспечением.
-
-    b) Передавая объектный код или содержащий его материальный продукт (включая
-    носитель, на котором распространяется произведение), с письменным
-    предложением, действительным в течение не менее трех лет либо до тех пор,
-    пока Вы предоставляете запасные части или поддержку для данного продукта,
-    о передаче любому обладателю объектного кода (1) копии Полного исходного
-    текста для всего программного обеспечения, содержащегося в продукте, на
-    которое распространяется действие настоящей Лицензии, на физическом
-    носителе, обычно используемом для обмена программным обеспечением, по цене,
-    не превышающей разумных затрат на передачу копии, или (2) доступа к Полному
-    исходному тексту с возможностью его копирования с сетевого сервера без
-    взимания платы.
-
-    с) Передавая отдельные копии объектного кода с письменной копией предложения
-    о предоставлении Полного исходного текста. Этот вариант допускается только
-    в отдельных случаях при распространении без извлечения прибыли, и только
-    если Вы получили объектный код с таким предложением в соответствии
-    с пунктом 6b.
-
-    d) Передавая объектный код посредством предоставления доступа к нему по
-    определенному адресу (бесплатно или за дополнительную плату), и предлагая
-    эквивалентный доступ к Полному исходному тексту таким же способом по тому же
-    адресу без какой-либо дополнительной оплаты. От Вас не требуется принуждать
-    получателей копировать Полный исходный текст вместе с объектным кодом. Если
-    объектный код размещен на сетевом сервере, Полный исходный текст может
-    находиться на другом сервере (управляемом Вами или третьим лицом), который
-    предоставляет аналогичную возможность копирования; при этом Вы должны четко
-    указать рядом с объектным кодом способ получения Полного исходного текста.
-    Независимо от того, на каком сервере расположен Полный исходный текст, Вы
-    обязаны убедиться в том, что он будет распространяться в течение времени,
-    необходимого для соблюдения этих требований.
-
-    e) Передавая объектный код с использованием одноранговой (пиринговой) сети,
-    при условии информирования других пользователей сети о том, где можно
-    бесплатно получить объектный код и Полный исходный текст произведения
-    способом, описанным в пункте 6d.
-
-  Не нужно включать в передаваемый объектный код его отделимые части, исходные
-тексты которых не входят в состав Полного исходного текста, такие как Системные
-библиотеки.
-
-  "Потребительский товар" это либо (1) "товар, предназначенный для личных нужд",
-под которым понимается любое материальное личное имущество, которое обычно
-используется для личных, семейных или домашних целей, или (2) что-либо
-спроектированное или продающееся для использования в жилище. При определении
-того, предназначен ли товар для личных нужд, сомнения должны толковаться в
-пользу положительного ответа на этот вопрос. Применительно к конкретному
-товару, используемому конкретным пользователем, под выражением "обычно
-используется" имеется в виду способ, которым данный вид товаров преимущественно
-или как правило используется, независимо от статуса конкретного пользователя
-или способа, которым конкретный пользователь использует, предполагает или
-будет использовать товар. Товар относится к предназначенным для личных нужд
-независимо от того, насколько часто он используется в коммерческой
-деятельности, промышленности или иной сфере, не относящейся к личным нуждам,
-за исключением случая, когда использование в этой сфере представляет собой
-единственный основной способ использования такого товара.
-
-  "Информация, необходимая для установки" Потребительского товара -- любые
-методы, процедуры, сведения, необходимые для авторизации, или другая
-информация, необходимая для установки и запуска в Потребительском товаре
-измененных версий Лицензионного произведения, полученных при изменении
-Полного исходного текста. Данная информация должна быть достаточной для
-того, чтобы обеспечить возможность внесения в исходный текст изменений,
-не приводящих к ограничению или нарушению его дальнейшей работоспособности.
-
-  Если вместе с Потребительским товаром или специально для использования
-в нём Вы передаете произведение в виде объектного кода на условиях, описанных
-в данном разделе, и такая передача является частью сделки, по которой право
-владения и пользования Потребительским товаром переходит к получателю
-пожизненно или на определенный срок (независимо от признаков сделки), Полный
-исходный текст, передаваемый согласно данному разделу, должен сопровождаться
-Информацией, необходимой для установки. Но это требование не применяется,
-если ни Вы, ни какое-либо третье лицо не сохраняет за собой возможности
-установки измененного объектного кода на Потребительский товар (например,
-произведение было установлено в постоянную память).
-
-  Требование о предоставлении Информации, необходимой для установки, не
-включает в себя требование продолжения оказания услуг по поддержке,
-предоставления гарантии или обновлений для произведения, которое было изменено
-или установлено получателем, либо для Потребительского товара, в котором оно
-было изменено или на который оно было установлено. В доступе к сети может быть
-отказано, если само внесение изменений существенно и негативно влияет на
-работу сети, нарушает правила обмена данными или не поддерживает протоколы для
-обмена данными по сети.
-
-  Передаваемый в соответствии с данным разделом Полный исходный текст и
-предоставленная Информация, необходимая для установки, должны быть записаны в
-формате, который имеет общедоступное описание (и общедоступную реализацию,
-опубликованную в форме исходного текста) и не должны требовать никаких
-специальных паролей или ключей для распаковки, чтения или копирования.
-
-  7. Дополнительные условия.
-
-  "Дополнительными разрешениями" называются условия, которые дополняют условия
-настоящей Лицензии, делая исключения из одного или нескольких её положений.
-Дополнительные разрешения, которые применимы ко всей Программе, должны
-рассматриваться как часть настоящей Лицензии, в той степени, в которой они
-соответствуют действующему законодательству. Если дополнительные разрешения
-применяются только к части Программы, эта часть может быть использована отдельно
-на измененных условиях, но вся Программа продолжает использоваться на условиях
-настоящей Лицензии без учета дополнительных разрешений.
-
-  Когда Вы передаете копию Лицензионного произведения, Вы можете по своему
-усмотрению исключить любые дополнительные разрешения, примененные к этой копии
-или к любой её части. (Для дополнительных разрешений может быть заявлено
-требование об их удалении в определенных случаях, когда Вы вносите изменения в
-произведение.) Вы можете добавлять дополнительные разрешения к добавленным Вами
-в Лицензионное произведение материалам, на которые Вы обладаете авторскими
-правами или правом выдачи соответствующего разрешения.
-
-  Независимо от любых других положений настоящей Лицензии, Вы можете дополнить
-следующими условиями положения настоящей Лицензии в отношении материала,
-добавленного к Лицензионному произведению (если это разрешено обладателями
-авторских прав на материал):
-
-    a) отказом от гарантий или ограничением ответственности, отличающимися от
-    тех, что описаны в разделах 15 и 16 настоящей Лицензии; либо
-
-    b) требованием сохранения соответствующей информации о правах или об
-    авторстве материала, или включения её в Информацию об авторском праве,
-    отображаемую содержащим его произведением; либо
-
-    c) запретом на искажение информации об источнике происхождения материала
-    или требованием того, чтобы измененные версии такого материала содержали
-    корректную отметку об отличиях от исходной версии; либо
-
-    d) ограничением использования в целях рекламы имен лицензиаров или авторов
-    материала; либо
-
-    e) отказом от предоставления прав на использование в качестве товарных
-    знаков некоторых торговых наименований, товарных знаков или знаков
-    обслуживания; либо
-
-    f) требованием от каждого, кто по договору передает материал (или его
-    измененные версии), предоставления компенсации лицензиарам и авторам
-    материала в виде принятия на себя любой ответственности, которую этот
-    договор налагает на лицензиаров и авторов.
-
-  Все остальные ограничительные дополнительные условия считаются "дополнительными
-запретами" по смыслу раздела 10. Если программа, которую Вы получили, или любая
-её часть содержит уведомление о том, что наряду с настоящей Лицензией её
-использование регулируется условием, относящимся к дополнительным запретам, Вы
-можете удалить такое условие. Если лицензия содержит дополнительный запрет, но
-допускает лицензирование на измененных условиях или передачу в соответствии с
-настоящей Лицензией, Вы можете добавить к Лицензионному произведению материал,
-используемый на условиях такой лицензии, в том случае, если дополнительный
-запрет не сохраняется при таком изменении условий лицензии или передаче.
-
-  Если Вы добавляете условия для использования Лицензионного произведения в
-соответствии с настоящим разделом, Вы должны поместить в соответствующих файлах
-исходного текста уведомление о том, что к этим файлам применяются дополнительные
-условия, или указание на то, как ознакомиться с соответствующими условиями.
-
-  Дополнительные разрешающие или ограничивающие условия могут быть сформулированы
-в виде отдельной лицензии или зафиксированы как исключения; вышеуказанные
-требования применяются в любом случае.
-
-  8. Прекращение действия.
-
-  Вы не можете распространять Лицензионное произведение или вносить в него
-изменения на условиях, отличающихся от явно оговоренных в настоящей Лицензии.
-Любая попытка распространения или внесения изменений на иных условиях является
-ничтожной и автоматически прекращает Ваши права, полученные по настоящей
-Лицензии (включая лицензию на любые патенты, предоставленные согласно третьему
-пункту раздела 11).
-
-  Тем не менее если Вы прекращаете нарушение настоящей Лицензии, Ваши права,
-полученные от конкретного правообладателя, восстанавливаются (а) временно, до
-тех пор пока правообладатель явно и окончательно не прекратит действие Ваших
-прав, и (б) навсегда, если правообладатель не уведомит Вас о нарушении с помощью
-надлежащих средств в течение 60 дней после прекращения нарушений.
-
-  Кроме того, Ваши права, полученные от конкретного правообладателя,
-восстанавливаются навсегда, если правообладатель впервые любым подходящим
-способом уведомляет Вас о нарушении настоящей Лицензии на свое произведение (для
-любого произведения) и Вы устраняете нарушение в течение 30 дней после получения
-уведомления.
-
-  Прекращение Ваших прав, описанное в настоящем разделе, не прекращает действие
-лицензий лиц, которые получили от Вас копии произведения или права,
-предоставляемые настоящей Лицензией. Если Ваши права были прекращены навсегда и
-не восстановлены, Вы не можете вновь получить право на тот же материал на
-условиях, описанных в разделе 10.
-
-  9. Акцепт не требуется для получения копий.
-
-  Вы не обязаны принимать условия настоящей Лицензии для того, чтобы получить или
-запустить копию Программы. Случайное распространение Лицензионного произведения,
-происходящее вследствие использования одноранговой (пиринговой) сети для
-получения его копии, также не требует принятия этих условий. Тем не менее только
-настоящая Лицензия дает Вам право распространять или изменять любое Лицензионное
-произведение. Если Вы не приняли условия настоящей Лицензии, такие действия
-будут нарушением авторского права. Поэтому изменяя или распространяя
-Лицензионное произведение, Вы выражаете согласие с условиями настоящей Лицензии.
-
-  10. Автоматическое получение прав последующими получателями.
-
-  Каждый раз, когда Вы передаете Лицензионное произведение, получатель
-автоматически получает от его лицензиара право запускать, изменять и
-распространять это произведение при условии соблюдения настоящей Лицензии. Вы не
-несете ответственности за соблюдение третьими лицами условий настоящей Лицензии.
-
-  "Реорганизацией" называются действия, в результате которых передается управление
-организацией или значительная часть её активов, а также происходит разделение
-или слияние организаций. Если распространение Лицензионного произведения
-является результатом реорганизации, каждая из сторон сделки, получающая копию
-произведения, также получает все права на произведение, которые предшествующее
-юридическое лицо имело или могло предоставить согласно предыдущему абзацу, а
-также право на владение Полным исходным текстом произведения от предшественника,
-осуществляемое в его интересах, если предшественник владеет им или может
-получить его при разумных усилиях.
-
-  Вы не можете налагать каких-либо дополнительных ограничений на осуществление
-прав, предоставленных или подтвержденных в соответствии с настоящей Лицензией.
-Например, Вы не можете ставить осуществление прав, предоставленных по настоящей
-Лицензии, в зависимость от оплаты отчислений, роялти или других сборов; также Вы
-не можете инициировать судебный процесс (включая встречный иск или заявление
-встречного требования в судебном процессе) о нарушении любых патентных прав при
-создании, использовании, продаже, предложении продажи, импорте Программы или
-любой её части.
-
-  11. Патенты.
-
-  "Инвестором" называется правообладатель, разрешающий использование Программы
-либо произведения, на котором основана Программа, на условиях настоящей
-Лицензии. Произведение, лицензированное таким образом, называется "версией со
-вкладом" инвестора.
-
-  "Неотъемлемые патентные претензии" инвестора -- все патентные права,
-принадлежащие инвестору или контролируемые им в настоящее время либо
-приобретенные в будущем, которые могут быть нарушены созданием, использованием
-или продажей версии со вкладом, допускаемыми настоящей Лицензией; они не
-включают в себя права, которые будут нарушены исключительно вследствие будущих
-изменений версии со вкладом. Для целей данного определения под "контролем"
-понимается право выдавать патентные сублицензии способами, не нарушающими
-требований настоящей Лицензии.
-
-  Каждый инвестор предоставляет Вам неисключительную безвозмездную лицензию на
-патент, действующую во всем мире, соответствующую неотъемлемым патентным
-претензиям инвестора, на создание, использование, продажу, предложение для
-продажи, импорт, а также запуск, внесение изменений и распространение всего, что
-входит в состав версии со вкладом.
-
-  В следующих трех абзацах "лицензией на патент" называется любое явно выраженное
-вовне согласие или обязательство не применять патент (например, выдача
-разрешения на использование запатентованного объекта или обещание не подавать в
-суд за нарушение патента). "Выдать" кому-то такую лицензию на патент означает
-заключить такое соглашение или обязаться не применять патент против него.
-
-  Если Вы передаете Лицензионное произведение, сознательно основываясь на лицензии
-на патент, в то время как Полный исходный текст произведения невозможно
-бесплатно скопировать с общедоступного сервера или другим не вызывающим
-затруднений способом, Вы должны либо (1) обеспечить возможность такого доступа к
-Полному исходному тексту, либо (2) отказаться от прав, предоставленных по
-лицензии на патент для данного произведения, либо (3) принять меры по передаче
-лицензии на патент последующим получателям произведения, в соответствии с
-требованиями настоящей Лицензии. "Сознательно основываясь" означает, что Вы
-знаете, что при отсутствии лицензии на патент передача Вами Лицензионного
-произведения в определенной стране или использование получателем переданного ему
-Вами Лицензионного произведения в этой стране нарушит один или несколько
-определенных патентов этой страны, срок действия которых не истек.
-
-  Если в соответствии или в связи с единичной сделкой либо соглашением Вы
-передаете или делаете заказ на распространение Лицензионного произведения, и
-предоставляете определенным лицам, получающим Лицензионное произведение,
-лицензию на патент, разрешающую им использовать, распространять, вносить
-изменения или передавать конкретные экземпляры Лицензионного произведения,
-права, которые Вы предоставляете по лицензии на патент, автоматически переходят
-ко всем получателям Лицензионного произведения и произведений, созданных на его
-основе.
-
-  Патентная лицензия называется "дискриминирующей", если она не покрывает,
-запрещает осуществление или содержит в качестве условия отказ от применения
-одного или нескольких прав, предоставленных настоящей Лицензией. Вы не можете
-передавать Лицензионное произведение, если Вы являетесь участником договора с
-третьим лицом, осуществляющим распространение программного обеспечения, в
-соответствии с которым Вы делаете в пользу третьего лица выплаты, размер которых
-зависит от масштабов Вашей деятельности по передаче произведения, и в
-соответствии с которым любое третье лицо, получающее от Вас Лицензионное
-произведение, делает это на условиях дискриминирующей патентной лицензии (а)
-которая зависит от количества копий Лицензионного произведения, переданных Вами
-(или копий, сделанных с этих копий), или (b) которая используется
-преимущественно в конкретных товарах или подборках, содержащих Лицензионное
-произведение, или в связи с ними, в том случае, если Вы заключили данный договор
-или получили лицензию на патент после 28 марта 2007 года.
-
-  Ничто в настоящей Лицензии не должно толковаться как исключение или ограничение
-любого предполагаемого права или других способов противодействия нарушениям,
-которые во всем остальном могут быть доступны для Вас в соответствии с
-применимым патентным правом.
-
-  12. Запрет отказывать в свободе другим.
-
-  Если на Вас наложены обязанности (будь то по решению суда, договору или иным
-способом), которые противоречат условиям настоящей Лицензии, это не освобождает
-Вас от соблюдения её условий. Если Вы не можете передать Лицензионное
-произведение так, чтобы одновременно выполнять Ваши обязательства по настоящей
-Лицензии и любые другие относящиеся к делу обязательства, то Вы не можете
-передавать его вообще. Например, если Вы согласны с условием, обязывающими Вас
-производить сбор отчислений за дальнейшую передачу от тех, кому Вы передаете
-Программу, то для того, чтобы соблюсти это условие и выполнить требования
-настоящей Лицензии, Вы должны полностью воздержаться от передачи Программы.
-
-  13. Удаленное сетевое взаимодействие.
-
-  Под "Прокси-программой" понимается отдельная программа, специально
-разработанная для использования совместно с Лицензионным произведением,
-и взаимодействующая с ним прямо или косвенно через любой вид программного
-интерфейса, компьютерную сеть, имитацию такой сети, или, в свою очередь,
-через другую Прокси-программу.
-
-  Независимо от любых других положений настоящей Лицензии, если вы
-предоставляете любому пользователю возможность взаимодействовать с Лицензионным
-произведением через компьютерную сеть, имитацию такой сети, или через любое
-количество "Прокси-программ", вы должны в явной форме предложить этому
-пользователю возможность получить Полный исходный текст Лицензионного
-произведения и всех Прокси-программ путём предоставления доступа к нему
-с сетевого сервера без взимания платы, посредством стандартных или
-традиционных способов, используемых для копирования программного обеспечения.
-Полный исходный текст Лицензионного произведения должен предоставляться
-пользователю на условиях настоящей Лицензии, а Полный исходный текст
-Прокси-программ должен предоставляться пользователю либо на условиях настоящей
-Лицензии, либо на условиях одной из свободных лицензий, совместимых с
-Генеральной публичной Лицензией GNU, перечисленных Фондом Свободного
-Программного Обеспечения в списке под названием "Лицензии свободных программ,
-совместимые с GPL".
-
-  14. Пересмотренные редакции настоящей Лицензии.
-
-  Автор настоящей Лицензии время от времени может публиковать пересмотренные
-и (или) новые редакции Сетевой Публичной Лицензии Vitastor. Они будут аналогичны
-по смыслу настоящей редакции, но могут отличаться от нее в деталях, направленных
-на решение новых проблем или регулирование новых отношений.
-
-  Каждой редакции присваивается собственный номер. Если для Программы указано,
-что к ней применима определенная редакция Сетевой Публичной Лицензии Vitastor
-"или любая более поздняя редакция", у Вас есть возможность использовать термины
-и условия, содержащиеся в редакции с указанным номером или любой более поздней
-редакции, опубликованной автором настоящей Лицензии. Если для Программы не
-указан номер редакции Сетевой Публичной Лицензии Vitastor, Вы можете выбрать
-любую редакцию, опубликованную автором настоящей Лицензии.
-
-  Более поздние редакции Лицензии могут дать Вам дополнительные или принципиально
-иные права. Тем не менее в результате Вашего выбора более поздней редакции на
-автора или правообладателя не возлагается никаких дополнительных обязанностей.
-
-  15. Отказ от гарантий.
-
-  НА ПРОГРАММУ НЕ ПРЕДОСТАВЛЯЕТСЯ НИКАКИХ ГАРАНТИЙ ЗА ИСКЛЮЧЕНИЕМ ПРЕДУСМОТРЕННЫХ
-ДЕЙСТВУЮЩИМ ЗАКОНОДАТЕЛЬСТВОМ. ЕСЛИ ИНОЕ НЕ УКАЗАНО В ПИСЬМЕННОЙ ФОРМЕ,
-ПРАВООБЛАДАТЕЛИ И (ИЛИ) ТРЕТЬИ ЛИЦА ПРЕДОСТАВЛЯЮТ ПРОГРАММУ "КАК ЕСТЬ", БЕЗ
-КАКИХ-ЛИБО ЯВНЫХ ИЛИ ПОДРАЗУМЕВАЕМЫХ ГАРАНТИЙ, ВКЛЮЧАЯ ГАРАНТИИ ПРИГОДНОСТИ ДЛЯ
-КОНКРЕТНЫХ ЦЕЛЕЙ, НО НЕ ОГРАНИЧИВАЯСЬ ИМИ. ВЕСЬ РИСК, СВЯЗАННЫЙ С КАЧЕСТВОМ И
-ПРОИЗВОДИТЕЛЬНОСТЬЮ ПРОГРАММЫ, ВОЗЛАГАЕТСЯ НА ВАС. ЕСЛИ В ПРОГРАММЕ БУДУТ
-ВЫЯВЛЕНЫ НЕДОСТАТКИ, ВЫ ПРИНИМАЕТЕ НА СЕБЯ СТОИМОСТЬ ВСЕГО НЕОБХОДИМОГО
-ОБСЛУЖИВАНИЯ, РЕМОНТА ИЛИ ИСПРАВЛЕНИЯ.
-
-  16. Ограничение ответственности.
-
-  ЕСЛИ ИНОЕ НЕ ПРЕДУСМОТРЕНО ДЕЙСТВУЮЩИМ ЗАКОНОДАТЕЛЬСТВОМ ИЛИ СОГЛАШЕНИЕМ СТОРОН,
-ЗАКЛЮЧЕННЫМ В ПИСЬМЕННОЙ ФОРМЕ, ПРАВООБЛАДАТЕЛЬ ИЛИ ИНОЕ ЛИЦО, КОТОРОЕ ВНОСИТ
-ИЗМЕНЕНИЯ В ПРОГРАММУ И (ИЛИ) ПЕРЕДАЕТ ЕЁ НА УСЛОВИЯХ, СФОРМУЛИРОВАННЫХ ВЫШЕ, НЕ
-МОЖЕТ НЕСТИ ОТВЕТСТВЕННОСТЬ ПЕРЕД ВАМИ ЗА ПРИЧИНЕННЫЙ УЩЕРБ, ВКЛЮЧАЯ УЩЕРБ
-ОБЩЕГО ЛИБО КОНКРЕТНОГО ХАРАКТЕРА, ПРИЧИНЕННЫЙ СЛУЧАЙНО ИЛИ ЯВЛЯЮЩИЙСЯ
-СЛЕДСТВИЕМ ИСПОЛЬЗОВАНИЯ ПРОГРАММЫ ЛИБО НЕВОЗМОЖНОСТИ ЕЁ ИСПОЛЬЗОВАНИЯ (В ТОМ
-ЧИСЛЕ ЗА УНИЧТОЖЕНИЕ ИЛИ МОДИФИКАЦИЮ ИНФОРМАЦИИ, ЛИБО УБЫТКИ, ПОНЕСЕННЫЕ ВАМИ
-ИЛИ ТРЕТЬИМИ ЛИЦАМИ, ЛИБО СБОИ ПРОГРАММЫ ПРИ ВЗАИМОДЕЙСТВИИ С ДРУГИМ ПРОГРАММНЫМ
-ОБЕСПЕЧЕНИЕМ), В ТОМ ЧИСЛЕ И В СЛУЧАЯХ, КОГДА ПРАВООБЛАДАТЕЛЬ ИЛИ ТРЕТЬЕ ЛИЦО
-ПРЕДУПРЕЖДЕНЫ О ВОЗМОЖНОСТИ ПРИЧИНЕНИЯ ТАКИХ УБЫТКОВ.
-
-  17. Толкование разделов 15 и 16.
-
-  Если отказ от гарантии и ограничение ответственности, представленные выше, по
-закону не могут быть применены в соответствии с их условиями, суды,
-рассматривающие спор, должны применить действующий закон, который в наибольшей
-степени предусматривает абсолютный отказ от всей гражданской ответственности в
-связи с Программой, за исключением случаев, когда гарантия или принятие на себя
-ответственности за копию программы предоставляется за плату.
-
-                        КОНЕЦ ОПРЕДЕЛЕНИЙ И УСЛОВИЙ
-
-          Порядок применения условий Лицензии к Вашим программам
-
-  Если Вы разрабатываете новую программу и хотите, чтобы её использование принесло
-максимальную пользу обществу, наилучший способ достичь этого -- сделать её
-свободной, чтобы все могли распространять и изменять её на условиях настоящей
-Лицензии.
-
-  Для этого сделайте так, чтобы программа содержала в себе описанные ниже
-уведомления. Самым надежным способом это сделать является включение их в начало
-каждого файла исходного текста, чтобы наиболее эффективным образом сообщить об
-отсутствии гарантий; каждый файл должен иметь по меньшей мере одну строку с
-оповещением об авторских правах и указанием на то, где находится полный текст
-уведомлений.
-
-    <Строка с названием Программы и информацией о её назначении.>
-    Copyright © <год выпуска программы в свет>  <имя автора>
-
-    Эта программа является свободным программным обеспечением: Вы можете
-    распространять её и (или) изменять, соблюдая условия Сетевой Публичной
-    Лицензии Vitastor, опубликованной автором Vitastor, либо редакции 1.1
-    Лицензии, либо (на Ваше усмотрение) любой редакции, выпущенной позже.
-
-    Эта программа распространяется в расчете на то, что она окажется полезной,
-    но БЕЗ КАКИХ-ЛИБО ГАРАНТИЙ, включая подразумеваемую гарантию КАЧЕСТВА либо
-    ПРИГОДНОСТИ ДЛЯ ОПРЕДЕЛЕННЫХ ЦЕЛЕЙ. Ознакомьтесь с Сетевой Публичной
-    Лицензией Vitastor для получения более подробной информации.
-
-  Также добавьте информацию о том, как связаться с Вами посредством электронной
-или обычной почты.
-
-  Если ваша программа взаимодействует с пользователями удаленно через
-компьютерную сеть, Вы также должны убедиться, что обеспечили её пользователям
-возможность получить её исходные тексты. Например, если Ваша программа является
-веб-приложением, её интерфейс может отображать ссылку "Исходные коды", которая
-указывает на архив с текстом. Существует много способов, которыми Вы можете
-распространять исходные тексты, для разных программ подходят разные решения;
-ознакомьтесь с разделом 13 для того, чтобы узнать конкретные требования.

VNPL-1.1.txt

@@ -61,7 +61,7 @@ modification follow.
 
   0. Definitions.
 
-  "This License" refers to version 1.1 of the Vitastor Network Public License.
+  "This License" refers to version 1 of the Vitastor Network Public License.
 
   "Copyright" also means copyright-like laws that apply to other kinds of
 works, such as semiconductor masks.
@@ -629,7 +629,7 @@ the "copyright" line and a pointer to where the full notice is found.
 
     This program is free software: you can redistribute it and/or modify
     it under the terms of the Vitastor Network Public License as published by
-    the Vitastor Author, either version 1.1 of the License, or
+    the Vitastor Author, either version 1 of the License, or
     (at your option) any later version.
 
     This program is distributed in the hope that it will be useful,

copy-fio-includes.sh

@@ -1,6 +1,6 @@
 #!/bin/bash
 
-gcc -I. -E -o fio_headers.i src/util/fio_headers.h
+gcc -I. -E -o fio_headers.i src/fio_headers.h
 
 rm -rf fio-copy
 for i in `grep -Po 'fio/[^"]+' fio_headers.i | sort | uniq`; do

copy-qemu-includes.sh

@@ -5,7 +5,7 @@
 #cd b/qemu; make qapi
 
 gcc -I qemu/b/qemu `pkg-config glib-2.0 --cflags` \
-    -I qemu/include -E -o qemu_driver.i src/client/qemu_driver.c
+    -I qemu/include -E -o qemu_driver.i src/qemu_driver.c
 
 rm -rf qemu-copy
 for i in `grep -Po 'qemu/[^"]+' qemu_driver.i | sort | uniq`; do

cpp-btree

@@ -1 +1 @@
-Subproject commit 8de8b467acbca50cfd8835c20e0e379110f3b32b
+Subproject commit 5dc108754ad40d3b1d024f9bd7cca0595ef1a1db

csi/Dockerfile

@@ -1,15 +1,14 @@
 # Compile stage
-FROM golang:bookworm AS build
+FROM golang:buster AS build
 
 ADD go.sum go.mod /app/
 RUN cd /app; CGO_ENABLED=1 GOOS=linux GOARCH=amd64 go mod download -x
 ADD . /app
-RUN perl -i -e '$/ = undef; while(<>) { s/\n\s*(\{\s*\n)/$1\n/g; s/\}(\s*\n\s*)else\b/$1} else/g; print; }' `find /app -name '*.go'` && \
-    cd /app && \
-    CGO_ENABLED=1 GOOS=linux GOARCH=amd64 go build -o vitastor-csi
+RUN perl -i -e '$/ = undef; while(<>) { s/\n\s*(\{\s*\n)/$1\n/g; s/\}(\s*\n\s*)else\b/$1} else/g; print; }' `find /app -name '*.go'`
+RUN cd /app; CGO_ENABLED=1 GOOS=linux GOARCH=amd64 go build -o vitastor-csi
 
 # Final stage
-FROM debian:bookworm
+FROM debian:buster
 
 LABEL maintainers="Vitaliy Filippov <vitalif@yourcmc.ru>"
 LABEL description="Vitastor CSI Driver"
@@ -19,30 +18,15 @@ ENV CSI_ENDPOINT=""
 
 RUN apt-get update && \
     apt-get install -y wget && \
+    wget -q -O /etc/apt/trusted.gpg.d/vitastor.gpg https://vitastor.io/debian/pubkey.gpg && \
+    (echo deb http://vitastor.io/debian buster main > /etc/apt/sources.list.d/vitastor.list) && \
+    (echo deb http://deb.debian.org/debian buster-backports main > /etc/apt/sources.list.d/backports.list) && \
     (echo "APT::Install-Recommends false;" > /etc/apt/apt.conf) && \
     apt-get update && \
-    apt-get install -y e2fsprogs xfsprogs kmod iproute2 \
-        # dependencies of qemu-storage-daemon
-        libnuma1 liburing2 libglib2.0-0 libfuse3-3 libaio1 libzstd1 libnettle8 \
-        libgmp10 libhogweed6 libp11-kit0 libidn2-0 libunistring2 libtasn1-6 libpcre2-8-0 libffi8 && \
+    apt-get install -y e2fsprogs xfsprogs vitastor kmod && \
     apt-get clean && \
     (echo options nbd nbds_max=128 > /etc/modprobe.d/nbd.conf)
 
 COPY --from=build /app/vitastor-csi /bin/
 
-RUN (echo deb http://vitastor.io/debian bookworm main > /etc/apt/sources.list.d/vitastor.list) && \
-    ((echo 'Package: *'; echo 'Pin: origin "vitastor.io"'; echo 'Pin-Priority: 1000') > /etc/apt/preferences.d/vitastor.pref) && \
-    wget -q -O /etc/apt/trusted.gpg.d/vitastor.gpg https://vitastor.io/debian/pubkey.gpg && \
-    apt-get update && \
-    apt-get install -y vitastor-client && \
-    wget https://vitastor.io/archive/qemu/qemu-bookworm-8.1.2%2Bds-1%2Bvitastor1/qemu-utils_8.1.2%2Bds-1%2Bvitastor1_amd64.deb && \
-    wget https://vitastor.io/archive/qemu/qemu-bookworm-8.1.2%2Bds-1%2Bvitastor1/qemu-block-extra_8.1.2%2Bds-1%2Bvitastor1_amd64.deb && \
-    dpkg -x qemu-utils*.deb tmp1 && \
-    dpkg -x qemu-block-extra*.deb tmp1 && \
-    cp -a tmp1/usr/bin/qemu-storage-daemon /usr/bin/ && \
-    mkdir -p /usr/lib/x86_64-linux-gnu/qemu && \
-    cp -a tmp1/usr/lib/x86_64-linux-gnu/qemu/block-vitastor.so /usr/lib/x86_64-linux-gnu/qemu/ && \
-    rm -rf tmp1 *.deb && \
-    apt-get clean
-
 ENTRYPOINT ["/bin/vitastor-csi"]

csi/Makefile

@@ -1,9 +1,9 @@
-VITASTOR_VERSION ?= v1.9.3
+VERSION ?= v0.6.10
 
 all: build push
 
 build:
-	@docker build --rm -t vitalif/vitastor-csi:$(VITASTOR_VERSION) .
+	@docker build --rm -t vitalif/vitastor-csi:$(VERSION) .
 
 push:
-	@docker push vitalif/vitastor-csi:$(VITASTOR_VERSION)
+	@docker push vitalif/vitastor-csi:$(VERSION)

csi/deploy/001-csi-config-map.yaml

@@ -2,7 +2,6 @@
 apiVersion: v1
 kind: ConfigMap
 data:
-  # You can add multiple configuration files here to use a multi-cluster setup
   vitastor.conf: |-
     {"etcd_address":"http://192.168.7.2:2379","etcd_prefix":"/vitastor"}
 metadata:

csi/deploy/004-csi-nodeplugin.yaml

@@ -49,7 +49,7 @@ spec:
             capabilities:
               add: ["SYS_ADMIN"]
             allowPrivilegeEscalation: true
-          image: vitalif/vitastor-csi:v1.9.3
+          image: vitalif/vitastor-csi:v0.6.10
           args:
             - "--node=$(NODE_ID)"
             - "--endpoint=$(CSI_ENDPOINT)"
@@ -82,8 +82,6 @@ spec:
               name: host-sys
             - mountPath: /run/mount
               name: host-mount
-            - mountPath: /run/vitastor-csi
-              name: run-vitastor-csi
             - mountPath: /lib/modules
               name: lib-modules
               readOnly: true
@@ -104,7 +102,7 @@ spec:
             - "--health-port=9898"
           env:
             - name: CSI_ENDPOINT
-              value: unix:///csi/csi.sock
+              value: unix://csi/csi.sock
           volumeMounts:
           - mountPath: /csi
             name: socket-dir
@@ -134,9 +132,6 @@ spec:
         - name: host-mount
           hostPath:
             path: /run/mount
-        - name: run-vitastor-csi
-          hostPath:
-            path: /run/vitastor-csi
         - name: lib-modules
           hostPath:
             path: /lib/modules

csi/deploy/005-csi-provisioner-rbac.yaml

@@ -35,13 +35,10 @@ rules:
     verbs: ["get", "list", "watch"]
   - apiGroups: ["snapshot.storage.k8s.io"]
     resources: ["volumesnapshots"]
-    verbs: ["get", "list", "patch"]
-  - apiGroups: ["snapshot.storage.k8s.io"]
-    resources: ["volumesnapshots/status"]
-    verbs: ["get", "list", "patch"]
+    verbs: ["get", "list"]
   - apiGroups: ["snapshot.storage.k8s.io"]
     resources: ["volumesnapshotcontents"]
-    verbs: ["create", "get", "list", "watch", "update", "delete", "patch"]
+    verbs: ["create", "get", "list", "watch", "update", "delete"]
   - apiGroups: ["snapshot.storage.k8s.io"]
     resources: ["volumesnapshotclasses"]
     verbs: ["get", "list", "watch"]
@@ -56,7 +53,7 @@ rules:
     verbs: ["get", "list", "watch"]
   - apiGroups: ["snapshot.storage.k8s.io"]
     resources: ["volumesnapshotcontents/status"]
-    verbs: ["update", "patch"]
+    verbs: ["update"]
   - apiGroups: [""]
     resources: ["configmaps"]
     verbs: ["get"]

csi/deploy/007-csi-provisioner.yaml

@@ -23,11 +23,6 @@ metadata:
   name: csi-vitastor-provisioner
 spec:
   replicas: 3
-  strategy:
-    type: RollingUpdate
-    rollingUpdate:
-      maxUnavailable: 1
-      maxSurge: 0
   selector:
     matchLabels:
       app: csi-vitastor-provisioner
@@ -51,7 +46,7 @@ spec:
       priorityClassName: system-cluster-critical
       containers:
         - name: csi-provisioner
-          image: k8s.gcr.io/sig-storage/csi-provisioner:v3.0.0
+          image: k8s.gcr.io/sig-storage/csi-provisioner:v2.2.0
           args:
             - "--csi-address=$(ADDRESS)"
             - "--v=5"
@@ -121,7 +116,7 @@ spec:
             privileged: true
             capabilities:
               add: ["SYS_ADMIN"]
-          image: vitalif/vitastor-csi:v1.9.3
+          image: vitalif/vitastor-csi:v0.6.10
           args:
             - "--node=$(NODE_ID)"
             - "--endpoint=$(CSI_ENDPOINT)"

csi/deploy/009-storage-class.yaml

@@ -12,6 +12,8 @@ parameters:
   etcdVolumePrefix: ""
   poolId: "1"
   # you can choose other configuration file if you have it in the config map
-  # different etcd URLs and prefixes should also be put in the config
   #configPath: "/etc/vitastor/vitastor.conf"
-allowVolumeExpansion: true
+  # you can also specify etcdUrl here, maybe to connect to another Vitastor cluster
+  # multiple etcdUrls may be specified, delimited by comma
+  #etcdUrl: "http://192.168.7.2:2379"
+  #etcdPrefix: "/vitastor"

csi/deploy/example-pvc-block.yaml

@@ -1,13 +0,0 @@
----
-apiVersion: v1
-kind: PersistentVolumeClaim
-metadata:
-  name: test-vitastor-pvc-block
-spec:
-  storageClassName: vitastor
-  volumeMode: Block
-  accessModes:
-    - ReadWriteMany
-  resources:
-    requests:
-      storage: 10Gi

csi/deploy/example-snapshot-class.yaml

@@ -1,7 +0,0 @@
-apiVersion: snapshot.storage.k8s.io/v1
-kind: VolumeSnapshotClass
-metadata:
-  name: vitastor-snapclass
-driver: csi.vitastor.io
-deletionPolicy: Delete
-parameters:

csi/deploy/example-snapshot-clone.yaml

@@ -1,16 +0,0 @@
----
-apiVersion: v1
-kind: PersistentVolumeClaim
-metadata:
-  name: test-vitastor-clone
-spec:
-  storageClassName: vitastor
-  dataSource:
-    name: snap1
-    kind: VolumeSnapshot
-    apiGroup: snapshot.storage.k8s.io
-  accessModes:
-    - ReadWriteOnce
-  resources:
-    requests:
-      storage: 10Gi

csi/deploy/example-snapshot.yaml

@@ -1,8 +0,0 @@
-apiVersion: snapshot.storage.k8s.io/v1
-kind: VolumeSnapshot
-metadata:
-  name: snap1
-spec:
-  volumeSnapshotClassName: vitastor-snapclass
-  source:
-    persistentVolumeClaimName: test-vitastor-pvc

csi/deploy/example-test-pod-block.yaml

@@ -1,17 +0,0 @@
-apiVersion: v1
-kind: Pod
-metadata:
-  name: vitastor-test-block-pvc
-  namespace: default
-spec:
-  containers:
-  - name: vitastor-test-block-pvc
-    image: nginx
-    volumeDevices:
-      - name: data
-        devicePath: /dev/xvda
-  volumes:
-  - name: data
-    persistentVolumeClaim:
-      claimName: test-vitastor-pvc-block
-      readOnly: false

csi/deploy/example-test-pod.yaml

@@ -1,17 +0,0 @@
-apiVersion: v1
-kind: Pod
-metadata:
-  name: vitastor-test-nginx
-  namespace: default
-spec:
-  containers:
-   - name: vitastor-test-nginx
-     image: nginx
-     volumeMounts:
-       - mountPath: /usr/share/nginx/html/s3
-         name: data
-  volumes:
-   - name: data
-     persistentVolumeClaim:
-       claimName: test-vitastor-pvc
-       readOnly: false

csi/go.mod

@@ -3,13 +3,27 @@ module vitastor.io/csi
 go 1.15
 
 require (
-	github.com/container-storage-interface/spec v1.8.0
+	github.com/container-storage-interface/spec v1.4.0
+	github.com/coreos/bbolt v0.0.0-00010101000000-000000000000 // indirect
+	github.com/coreos/etcd v3.3.25+incompatible // indirect
+	github.com/coreos/go-semver v0.3.0 // indirect
+	github.com/coreos/go-systemd v0.0.0-20191104093116-d3cd4ed1dbcf // indirect
+	github.com/coreos/pkg v0.0.0-20180928190104-399ea9e2e55f // indirect
+	github.com/dustin/go-humanize v1.0.0 // indirect
 	github.com/golang/glog v0.0.0-20160126235308-23def4e6c14b
+	github.com/gorilla/websocket v1.4.2 // indirect
+	github.com/grpc-ecosystem/go-grpc-middleware v1.3.0 // indirect
+	github.com/grpc-ecosystem/go-grpc-prometheus v1.2.0 // indirect
+	github.com/grpc-ecosystem/grpc-gateway v1.16.0 // indirect
+	github.com/jonboulle/clockwork v0.2.2 // indirect
 	github.com/kubernetes-csi/csi-lib-utils v0.9.1
-	golang.org/x/net v0.7.0
-	golang.org/x/xerrors v0.0.0-20200804184101-5ec99f83aff1 // indirect
+	github.com/soheilhy/cmux v0.1.5 // indirect
+	github.com/tmc/grpc-websocket-proxy v0.0.0-20201229170055-e5319fda7802 // indirect
+	github.com/xiang90/probing v0.0.0-20190116061207-43a291ad63a2 // indirect
+	go.etcd.io/bbolt v0.0.0-00010101000000-000000000000 // indirect
+	go.etcd.io/etcd v3.3.25+incompatible
+	golang.org/x/net v0.0.0-20201202161906-c7110b5ffcbb
 	google.golang.org/grpc v1.33.1
-	google.golang.org/protobuf v1.24.0
 	k8s.io/klog v1.0.0
 	k8s.io/utils v0.0.0-20210305010621-2afb4311ab10
 )

csi/go.sum

@@ -31,24 +31,40 @@ github.com/alecthomas/template v0.0.0-20160405071501-a0175ee3bccc/go.mod h1:LOuy
 github.com/alecthomas/template v0.0.0-20190718012654-fb15b899a751/go.mod h1:LOuyumcjzFXgccqObfd/Ljyb9UuFJ6TxHnclSeseNhc=
 github.com/alecthomas/units v0.0.0-20151022065526-2efee857e7cf/go.mod h1:ybxpYRFXyAe+OPACYpWeL0wqObRcbAqCMya13uyzqw0=
 github.com/alecthomas/units v0.0.0-20190717042225-c3de453c63f4/go.mod h1:ybxpYRFXyAe+OPACYpWeL0wqObRcbAqCMya13uyzqw0=
+github.com/antihax/optional v1.0.0/go.mod h1:uupD/76wgC+ih3iEmQUL+0Ugr19nfwCT1kdvxnR2qWY=
 github.com/beorn7/perks v0.0.0-20180321164747-3a771d992973/go.mod h1:Dwedo/Wpr24TaqPxmxbtue+5NUziq4I4S80YR8gNf3Q=
 github.com/beorn7/perks v1.0.0/go.mod h1:KWe93zE9D1o94FZ5RNwFwVgaQK1VOXiVxmqh+CedLV8=
+github.com/beorn7/perks v1.0.1 h1:VlbKKnNfV8bJzeqoa4cOKqO6bYr3WgKZxO8Z16+hsOM=
 github.com/beorn7/perks v1.0.1/go.mod h1:G2ZrVWU2WbWT9wwq4/hrbKbnv/1ERSJQ0ibhJ6rlkpw=
 github.com/blang/semver v3.5.0+incompatible/go.mod h1:kRBLl5iJ+tD4TcOOxsy/0fnwebNt5EWlYSAyrTnjyyk=
 github.com/census-instrumentation/opencensus-proto v0.2.1/go.mod h1:f6KPmirojxKA12rnyqOA5BBL4O983OfeGPqjHWSTneU=
+github.com/cespare/xxhash/v2 v2.1.1 h1:6MnRN8NT7+YBpUIWxHtefFZOKTAPgGjpQSxqLNn0+qY=
 github.com/cespare/xxhash/v2 v2.1.1/go.mod h1:VGX0DQ3Q6kWi7AoAeZDth3/j3BFtOZR5XLFGgcrjCOs=
 github.com/chzyer/logex v1.1.10/go.mod h1:+Ywpsq7O8HXn0nuIou7OrIPyXbp3wmkHB+jjWRnGsAI=
 github.com/chzyer/readline v0.0.0-20180603132655-2972be24d48e/go.mod h1:nSuG5e5PlCu98SY8svDHJxuZscDgtXS6KTTbou5AhLI=
 github.com/chzyer/test v0.0.0-20180213035817-a1ea475d72b1/go.mod h1:Q3SI9o4m/ZMnBNeIyt5eFwwo7qiLfzFZmjNmxjkiQlU=
 github.com/container-storage-interface/spec v1.2.0/go.mod h1:6URME8mwIBbpVyZV93Ce5St17xBiQJQY67NDsuohiy4=
-github.com/container-storage-interface/spec v1.8.0 h1:D0vhF3PLIZwlwZEf2eNbpujGCNwspwTYf2idJRJx4xI=
-github.com/container-storage-interface/spec v1.8.0/go.mod h1:ROLik+GhPslwwWRNFF1KasPzroNARibH2rfz1rkg4H0=
+github.com/container-storage-interface/spec v1.4.0 h1:ozAshSKxpJnYUfmkpZCTYyF/4MYeYlhdXbAvPvfGmkg=
+github.com/container-storage-interface/spec v1.4.0/go.mod h1:6URME8mwIBbpVyZV93Ce5St17xBiQJQY67NDsuohiy4=
+github.com/coreos/bbolt v1.3.5 h1:XFv7xaq7701j8ZSEzR28VohFYSlyakMyqNMU5FQH6Ac=
+github.com/coreos/bbolt v1.3.5/go.mod h1:G5EMThwa9y8QZGBClrRx5EY+Yw9kAhnjy3bSjsnlVTQ=
+github.com/coreos/etcd v3.3.25+incompatible h1:0GQEw6h3YnuOVdtwygkIfJ+Omx0tZ8/QkVyXI4LkbeY=
+github.com/coreos/etcd v3.3.25+incompatible/go.mod h1:uF7uidLiAD3TWHmW31ZFd/JWoc32PjwdhPthX9715RE=
+github.com/coreos/go-semver v0.3.0 h1:wkHLiw0WNATZnSG7epLsujiMCgPAc9xhjJ4tgnAxmfM=
+github.com/coreos/go-semver v0.3.0/go.mod h1:nnelYz7RCh+5ahJtPPxZlU+153eP4D4r3EedlOD2RNk=
+github.com/coreos/go-systemd v0.0.0-20191104093116-d3cd4ed1dbcf h1:iW4rZ826su+pqaw19uhpSCzhj44qo35pNgKFGqzDKkU=
+github.com/coreos/go-systemd v0.0.0-20191104093116-d3cd4ed1dbcf/go.mod h1:F5haX7vjVVG0kc13fIWeqUViNPyEJxv/OmvnBo0Yme4=
+github.com/coreos/pkg v0.0.0-20180928190104-399ea9e2e55f h1:lBNOc5arjvs8E5mO2tbpBpLoyyu8B6e44T7hJy6potg=
+github.com/coreos/pkg v0.0.0-20180928190104-399ea9e2e55f/go.mod h1:E3G3o1h8I7cfcXa63jLwjI0eiQQMgzzUDFVpN/nH/eA=
 github.com/davecgh/go-spew v1.1.0/go.mod h1:J7Y8YcW2NihsgmVo/mv3lAwl/skON4iLHjSsI+c5H38=
 github.com/davecgh/go-spew v1.1.1 h1:vj9j/u1bqnvCEfJOwUhtlOARqs3+rkHYY13jYWTU97c=
 github.com/davecgh/go-spew v1.1.1/go.mod h1:J7Y8YcW2NihsgmVo/mv3lAwl/skON4iLHjSsI+c5H38=
+github.com/dgrijalva/jwt-go v3.2.0+incompatible h1:7qlOGliEKZXTDg6OTjfoBKDXWrumCAMpl/TFQ4/5kLM=
 github.com/dgrijalva/jwt-go v3.2.0+incompatible/go.mod h1:E3ru+11k8xSBh+hMPgOLZmtrrCbhqsmaPHjLKYnJCaQ=
 github.com/docker/spdystream v0.0.0-20160310174837-449fdfce4d96/go.mod h1:Qh8CwZgvJUkLughtfhJv5dyTYa91l1fOUCrgjqmcifM=
 github.com/docopt/docopt-go v0.0.0-20180111231733-ee0de3bc6815/go.mod h1:WwZ+bS3ebgob9U8Nd0kOddGdZWjyMGR8Wziv+TBNwSE=
+github.com/dustin/go-humanize v1.0.0 h1:VSnTsYCnlFHaM2/igO1h6X3HA71jcobQuxemgkq4zYo=
+github.com/dustin/go-humanize v1.0.0/go.mod h1:HtrtbFcZ19U5GC7JDqmcUSB87Iq5E25KnS6fMYU6eOk=
 github.com/elazarl/goproxy v0.0.0-20180725130230-947c36da3153/go.mod h1:/Zj4wYkgs4iZTTu3o/KG3Itv/qCCa8VVMlb3i9OVuzc=
 github.com/emicklei/go-restful v0.0.0-20170410110728-ff4f55a20633/go.mod h1:otzb+WCGbkyDHkqmQmT5YD2WR4BBwUdeQoFo8l/7tVs=
 github.com/envoyproxy/go-control-plane v0.9.0/go.mod h1:YTl/9mNaCwkRvm6d1a2C3ymFceY/DCBVvsKhRF0iEA4=
@@ -57,6 +73,7 @@ github.com/evanphx/json-patch v4.9.0+incompatible/go.mod h1:50XU6AFN0ol/bzJsmQLi
 github.com/fsnotify/fsnotify v1.4.7/go.mod h1:jwhsz4b93w/PPRr/qN1Yymfu8t87LnFCMoQvtojpjFo=
 github.com/fsnotify/fsnotify v1.4.9/go.mod h1:znqG4EE+3YCdAaPaxE2ZRY/06pZUdp0tY4IgpuI1SZQ=
 github.com/ghodss/yaml v0.0.0-20150909031657-73d445a93680/go.mod h1:4dBDuWmgqj2HViK6kFavaiC9ZROes6MMH2rRYeMEF04=
+github.com/ghodss/yaml v1.0.0/go.mod h1:4dBDuWmgqj2HViK6kFavaiC9ZROes6MMH2rRYeMEF04=
 github.com/go-gl/glfw/v3.3/glfw v0.0.0-20191125211704-12ad95a8df72/go.mod h1:tQ2UAYgL5IevRw8kRxooKSPJfGvJ9fJQFa0TUsXzTg8=
 github.com/go-kit/kit v0.8.0/go.mod h1:xBxKIO96dXMWWy0MnWVtmwkA9/13aqxPnvrjFYMA2as=
 github.com/go-kit/kit v0.9.0/go.mod h1:xBxKIO96dXMWWy0MnWVtmwkA9/13aqxPnvrjFYMA2as=
@@ -71,10 +88,14 @@ github.com/go-openapi/spec v0.0.0-20160808142527-6aced65f8501/go.mod h1:J8+jY1nA
 github.com/go-openapi/swag v0.0.0-20160704191624-1d0bd113de87/go.mod h1:DXUve3Dpr1UfpPtxFw+EFuQ41HhCWZfha5jSVRG7C7I=
 github.com/go-stack/stack v1.8.0/go.mod h1:v0f6uXyyMGvRgIKkXu+yp6POWl0qKG85gN/melR3HDY=
 github.com/gogo/protobuf v1.1.1/go.mod h1:r8qH/GZQm5c6nD/R0oafs1akxWv10x8SbQlK7atdtwQ=
+github.com/gogo/protobuf v1.3.1 h1:DqDEcV5aeaTmdFBePNpYsp3FlcVH/2ISVVM9Qf8PSls=
 github.com/gogo/protobuf v1.3.1/go.mod h1:SlYgWuQ5SjCEi6WLHjHCa1yvBfUnHcTbrrZtXPKa29o=
+github.com/gogo/protobuf v1.3.2 h1:Ov1cvc58UF3b5XjBnZv7+opcTcQFZebYjWzi34vdm4Q=
+github.com/gogo/protobuf v1.3.2/go.mod h1:P1XiOD3dCwIKUDQYPy72D8LYyHL2YPYrpS2s69NZV8Q=
 github.com/golang/glog v0.0.0-20160126235308-23def4e6c14b h1:VKtxabqXZkF25pY9ekfRL6a582T4P37/31XEstQ5p58=
 github.com/golang/glog v0.0.0-20160126235308-23def4e6c14b/go.mod h1:SBH7ygxi8pfUlaOkMMuAQtPIUF8ecWP5IEl/CR7VP2Q=
 github.com/golang/groupcache v0.0.0-20190702054246-869f871628b6/go.mod h1:cIg4eruTrX1D+g88fzRXU5OdNfaM+9IcxsU14FzY7Hc=
+github.com/golang/groupcache v0.0.0-20191227052852-215e87163ea7 h1:5ZkaAPbicIKTF2I64qf5Fh8Aa83Q/dnOafMYV0OMwjA=
 github.com/golang/groupcache v0.0.0-20191227052852-215e87163ea7/go.mod h1:cIg4eruTrX1D+g88fzRXU5OdNfaM+9IcxsU14FzY7Hc=
 github.com/golang/mock v1.1.1/go.mod h1:oTYuIxOrZwtPieC+H1uAHpcLFnEyAGVDL/k47Jfbm0A=
 github.com/golang/mock v1.2.0/go.mod h1:oTYuIxOrZwtPieC+H1uAHpcLFnEyAGVDL/k47Jfbm0A=
@@ -92,6 +113,7 @@ github.com/golang/protobuf v1.4.1/go.mod h1:U8fpvMrcmy5pZrNK1lt4xCsGvpyWQ/VVv6QD
 github.com/golang/protobuf v1.4.2 h1:+Z5KGCizgyZCbGh1KZqA0fcLLkwbsjIzS4aV2v7wJX0=
 github.com/golang/protobuf v1.4.2/go.mod h1:oDoupMAO8OvCJWAcko0GGGIgR6R6ocIYbsSw735rRwI=
 github.com/google/btree v0.0.0-20180813153112-4030bb1f1f0c/go.mod h1:lNA+9X1NB3Zf8V7Ke586lFgjr2dZNuvo3lPJSGZ5JPQ=
+github.com/google/btree v1.0.0 h1:0udJVsspx3VBr5FwtLhQQtuAsVc79tTq0ocGIPAU6qo=
 github.com/google/btree v1.0.0/go.mod h1:lNA+9X1NB3Zf8V7Ke586lFgjr2dZNuvo3lPJSGZ5JPQ=
 github.com/google/go-cmp v0.2.0/go.mod h1:oXzfMopK8JAjlY9xF4vHSVASa0yLyX7SntLO5aqRK0M=
 github.com/google/go-cmp v0.3.0/go.mod h1:8QqcDgzrUqlUb/G2PQTWiueGozuR1884gddMywk6iLU=
@@ -105,24 +127,38 @@ github.com/google/pprof v0.0.0-20181206194817-3ea8567a2e57/go.mod h1:zfwlbNMJ+OI
 github.com/google/pprof v0.0.0-20190515194954-54271f7e092f/go.mod h1:zfwlbNMJ+OItoe0UupaVj+oy1omPYYDuagoSzA8v9mc=
 github.com/google/pprof v0.0.0-20191218002539-d4f498aebedc/go.mod h1:ZgVRPoUq/hfqzAqh7sHMqb3I9Rq5C59dIz2SbBwJ4eM=
 github.com/google/renameio v0.1.0/go.mod h1:KWCgfxg9yswjAJkECMjeO8J8rahYeXnNhOm40UhjYkI=
+github.com/google/uuid v1.1.1 h1:Gkbcsh/GbpXz7lPftLA3P6TYMwjCLYm83jiFQZF/3gY=
 github.com/google/uuid v1.1.1/go.mod h1:TIyPZe4MgqvfeYDBFedMoGGpEw/LqOeaOT+nhxU+yHo=
 github.com/googleapis/gax-go/v2 v2.0.4/go.mod h1:0Wqv26UfaUD9n4G6kQubkQ+KchISgw+vpHVxEJEs9eg=
 github.com/googleapis/gax-go/v2 v2.0.5/go.mod h1:DWXyrwAJ9X0FpwwEdw+IPEYBICEFu5mhpdKc/us6bOk=
 github.com/googleapis/gnostic v0.4.1/go.mod h1:LRhVm6pbyptWbWbuZ38d1eyptfvIytN3ir6b65WBswg=
+github.com/gorilla/websocket v1.4.2 h1:+/TMaTYc4QFitKJxsQ7Yye35DkWvkdLcvGKqM+x0Ufc=
+github.com/gorilla/websocket v1.4.2/go.mod h1:YR8l580nyteQvAITg2hZ9XVh4b55+EU/adAjf1fMHhE=
 github.com/gregjones/httpcache v0.0.0-20180305231024-9cad4c3443a7/go.mod h1:FecbI9+v66THATjSRHfNgh1IVFe/9kFxbXtjV0ctIMA=
+github.com/grpc-ecosystem/go-grpc-middleware v1.3.0 h1:+9834+KizmvFV7pXQGSXQTsaWhq2GjuNUt0aUU0YBYw=
+github.com/grpc-ecosystem/go-grpc-middleware v1.3.0/go.mod h1:z0ButlSOZa5vEBq9m2m2hlwIgKw+rp3sdCBRoJY+30Y=
+github.com/grpc-ecosystem/go-grpc-prometheus v1.2.0 h1:Ovs26xHkKqVztRpIrF/92BcuyuQ/YW4NSIpoGtfXNho=
+github.com/grpc-ecosystem/go-grpc-prometheus v1.2.0/go.mod h1:8NvIoxWQoOIhqOTXgfV/d3M/q6VIi02HzZEHgUlZvzk=
+github.com/grpc-ecosystem/grpc-gateway v1.16.0 h1:gmcG1KaJ57LophUzW0Hy8NmPhnMZb4M0+kPpLofRdBo=
+github.com/grpc-ecosystem/grpc-gateway v1.16.0/go.mod h1:BDjrQk3hbvj6Nolgz8mAMFbcEtjT1g+wF4CSlocrBnw=
 github.com/hashicorp/golang-lru v0.5.0/go.mod h1:/m3WP610KZHVQ1SGc6re/UDhFvYD7pJ4Ao+sR/qLZy8=
 github.com/hashicorp/golang-lru v0.5.1/go.mod h1:/m3WP610KZHVQ1SGc6re/UDhFvYD7pJ4Ao+sR/qLZy8=
 github.com/hpcloud/tail v1.0.0/go.mod h1:ab1qPbhIpdTxEkNHXyeSf5vhxWSCs/tWer42PpOxQnU=
 github.com/ianlancetaylor/demangle v0.0.0-20181102032728-5e5cf60278f6/go.mod h1:aSSvb/t6k1mPoxDqO4vJh6VOCGPwU4O0C2/Eqndh1Sc=
 github.com/imdario/mergo v0.3.5/go.mod h1:2EnlNZ0deacrJVfApfmtdGgDfMuh/nq6Ok1EcJh5FfA=
+github.com/jonboulle/clockwork v0.2.2 h1:UOGuzwb1PwsrDAObMuhUnj0p5ULPj8V/xJ7Kx9qUBdQ=
+github.com/jonboulle/clockwork v0.2.2/go.mod h1:Pkfl5aHPm1nk2H9h0bjmnJD/BcgbGXUBGnn1kMkgxc8=
 github.com/json-iterator/go v1.1.6/go.mod h1:+SdeFBvtyEkXs7REEP0seUULqWtbJapLOCVDaaPEHmU=
+github.com/json-iterator/go v1.1.10 h1:Kz6Cvnvv2wGdaG/V8yMvfkmNiXq9Ya2KUv4rouJJr68=
 github.com/json-iterator/go v1.1.10/go.mod h1:KdQUCv79m/52Kvf8AW2vK1V8akMuk1QjK/uOdHXbAo4=
 github.com/jstemmer/go-junit-report v0.0.0-20190106144839-af01ea7f8024/go.mod h1:6v2b51hI/fHJwM22ozAgKL4VKDeJcHhJFhtBdhmNjmU=
 github.com/jstemmer/go-junit-report v0.9.1/go.mod h1:Brl9GWCQeLvo8nXZwPNNblvFj/XSXhF0NWZEnDohbsk=
 github.com/julienschmidt/httprouter v1.2.0/go.mod h1:SYymIcj16QtmaHHD7aYtjjsJG7VTCxuUUipMqKk8s4w=
 github.com/kisielk/errcheck v1.2.0/go.mod h1:/BMXB+zMLi60iA8Vv6Ksmxu/1UDYcXs4uQLJ+jE2L00=
+github.com/kisielk/errcheck v1.5.0/go.mod h1:pFxgyoBC7bSaBwPgfKdkLd5X25qrDl4LWUI2bnpBCr8=
 github.com/kisielk/gotool v1.0.0/go.mod h1:XhKaO+MFFWcvkIS/tQcRk01m1F5IRFswLeQ+oQHNcck=
 github.com/konsorten/go-windows-terminal-sequences v1.0.1/go.mod h1:T0+1ngSBFLxvqU3pZ+m/2kptfBszLMUkC4ZK/EgS/cQ=
+github.com/konsorten/go-windows-terminal-sequences v1.0.3 h1:CE8S1cTafDpPvMhIxNJKvHsGVBgn1xWYf1NbHQhywc8=
 github.com/konsorten/go-windows-terminal-sequences v1.0.3/go.mod h1:T0+1ngSBFLxvqU3pZ+m/2kptfBszLMUkC4ZK/EgS/cQ=
 github.com/kr/logfmt v0.0.0-20140226030751-b84e30acd515/go.mod h1:+0opPa2QZZtGFBFZlji/RkVcI2GknAs/DXo4wKdlNEc=
 github.com/kr/pretty v0.1.0/go.mod h1:dAy3ld7l9f0ibDNOQOHHMYYIIbhfbHSm3C4ZsoJORNo=
@@ -135,11 +171,14 @@ github.com/kubernetes-csi/csi-lib-utils v0.9.1 h1:sGq6ifVujfMSkfTsMZip44Ttv8SDXv
 github.com/kubernetes-csi/csi-lib-utils v0.9.1/go.mod h1:8E2jVUX9j3QgspwHXa6LwyN7IHQDjW9jX3kwoWnSC+M=
 github.com/mailru/easyjson v0.0.0-20160728113105-d5b7844b561a/go.mod h1:C1wdFJiN94OJF2b5HbByQZoLdCWB1Yqtg26g4irojpc=
 github.com/matttproud/golang_protobuf_extensions v1.0.1/go.mod h1:D8He9yQNgCq6Z5Ld7szi9bcBfOoFv/3dc6xSMkL2PC0=
+github.com/matttproud/golang_protobuf_extensions v1.0.2-0.20181231171920-c182affec369 h1:I0XW9+e1XWDxdcEniV4rQAIOPUGDq67JSCiRCgGCZLI=
 github.com/matttproud/golang_protobuf_extensions v1.0.2-0.20181231171920-c182affec369/go.mod h1:BSXmuO+STAnVfrANrmjBb36TMTDstsz7MSK+HVaYKv4=
 github.com/moby/term v0.0.0-20200312100748-672ec06f55cd/go.mod h1:DdlQx2hp0Ss5/fLikoLlEeIYiATotOjgB//nb973jeo=
 github.com/modern-go/concurrent v0.0.0-20180228061459-e0a39a4cb421/go.mod h1:6dJC0mAP4ikYIbvyc7fijjWJddQyLn8Ig3JB5CqoB9Q=
+github.com/modern-go/concurrent v0.0.0-20180306012644-bacd9c7ef1dd h1:TRLaZ9cD/w8PVh93nsPXa1VrQ6jlwL5oN8l14QlcNfg=
 github.com/modern-go/concurrent v0.0.0-20180306012644-bacd9c7ef1dd/go.mod h1:6dJC0mAP4ikYIbvyc7fijjWJddQyLn8Ig3JB5CqoB9Q=
 github.com/modern-go/reflect2 v0.0.0-20180701023420-4b7aa43c6742/go.mod h1:bx2lNnkwVCuqBIxFjflWJWanXIb3RllmbCylyMrvgv0=
+github.com/modern-go/reflect2 v1.0.1 h1:9f412s+6RmYXLWZSEzVVgPGK7C2PphHj5RJrvfx9AWI=
 github.com/modern-go/reflect2 v1.0.1/go.mod h1:bx2lNnkwVCuqBIxFjflWJWanXIb3RllmbCylyMrvgv0=
 github.com/munnerz/goautoneg v0.0.0-20120707110453-a547fc61f48d/go.mod h1:+n7T8mK8HuQTcFwEeznm/DIxMOiR9yIdICNftLE1DvQ=
 github.com/mwitkow/go-conntrack v0.0.0-20161129095857-cc309e4a2223/go.mod h1:qRWi+5nqEBWmkhHvq77mSJWrCKwh8bxhgT7d/eI7P4U=
@@ -149,28 +188,38 @@ github.com/onsi/ginkgo v1.6.0/go.mod h1:lLunBs/Ym6LB5Z9jYTR76FiuTmxDTDusOGeTQH+W
 github.com/onsi/ginkgo v1.11.0/go.mod h1:lLunBs/Ym6LB5Z9jYTR76FiuTmxDTDusOGeTQH+WWjE=
 github.com/onsi/gomega v0.0.0-20170829124025-dcabb60a477c/go.mod h1:C1qb7wdrVGGVU+Z6iS04AVkA3Q65CEZX59MT0QO5uiA=
 github.com/onsi/gomega v1.7.0/go.mod h1:ex+gbHU/CVuBBDIJjb2X0qEXbFg53c61hWP/1CpauHY=
+github.com/opentracing/opentracing-go v1.1.0/go.mod h1:UkNAQd3GIcIGf0SeVgPpRdFStlNbqXla1AfSYxPUl2o=
 github.com/peterbourgon/diskv v2.0.1+incompatible/go.mod h1:uqqh8zWWbv1HBMNONnaR/tNboyR3/BZd58JJSHlUSCU=
 github.com/pkg/errors v0.8.0/go.mod h1:bwawxfHBFNV+L2hUp1rHADufV3IMtnDRdf1r5NINEl0=
 github.com/pkg/errors v0.8.1/go.mod h1:bwawxfHBFNV+L2hUp1rHADufV3IMtnDRdf1r5NINEl0=
+github.com/pkg/errors v0.9.1 h1:FEBLx1zS214owpjy7qsBeixbURkuhQAwrK5UwLGTwt4=
 github.com/pkg/errors v0.9.1/go.mod h1:bwawxfHBFNV+L2hUp1rHADufV3IMtnDRdf1r5NINEl0=
 github.com/pmezard/go-difflib v1.0.0 h1:4DBwDE0NGyQoBHbLQYPwSUPoCMWR5BEzIk/f1lZbAQM=
 github.com/pmezard/go-difflib v1.0.0/go.mod h1:iKH77koFhYxTK1pcRnkKkqfTogsbg7gZNVY4sRDYZ/4=
 github.com/prometheus/client_golang v0.9.1/go.mod h1:7SWBe2y4D6OKWSNQJUaRYU/AaXPKyh/dDVn+NZz0KFw=
 github.com/prometheus/client_golang v1.0.0/go.mod h1:db9x61etRT2tGnBNRi70OPL5FsnadC4Ky3P0J6CfImo=
+github.com/prometheus/client_golang v1.7.1 h1:NTGy1Ja9pByO+xAeH/qiWnLrKtr3hJPNjaVUwnjpdpA=
 github.com/prometheus/client_golang v1.7.1/go.mod h1:PY5Wy2awLA44sXw4AOSfFBetzPP4j5+D6mVACh+pe2M=
 github.com/prometheus/client_model v0.0.0-20180712105110-5c3871d89910/go.mod h1:MbSGuTsp3dbXC40dX6PRTWyKYBIrTGTE9sqQNg2J8bo=
 github.com/prometheus/client_model v0.0.0-20190129233127-fd36f4220a90/go.mod h1:xMI15A0UPsDsEKsMN9yxemIoYk6Tm2C1GtYGdfGttqA=
 github.com/prometheus/client_model v0.0.0-20190812154241-14fe0d1b01d4/go.mod h1:xMI15A0UPsDsEKsMN9yxemIoYk6Tm2C1GtYGdfGttqA=
+github.com/prometheus/client_model v0.2.0 h1:uq5h0d+GuxiXLJLNABMgp2qUWDPiLvgCzz2dUR+/W/M=
 github.com/prometheus/client_model v0.2.0/go.mod h1:xMI15A0UPsDsEKsMN9yxemIoYk6Tm2C1GtYGdfGttqA=
 github.com/prometheus/common v0.4.1/go.mod h1:TNfzLD0ON7rHzMJeJkieUDPYmFC7Snx/y86RQel1bk4=
+github.com/prometheus/common v0.10.0 h1:RyRA7RzGXQZiW+tGMr7sxa85G1z0yOpM1qq5c8lNawc=
 github.com/prometheus/common v0.10.0/go.mod h1:Tlit/dnDKsSWFlCLTWaA1cyBgKHSMdTB80sz/V91rCo=
 github.com/prometheus/procfs v0.0.0-20181005140218-185b4288413d/go.mod h1:c3At6R/oaqEKCNdg8wHV1ftS6bRYblBhIjjI8uT2IGk=
 github.com/prometheus/procfs v0.0.2/go.mod h1:TjEm7ze935MbeOT/UhFTIMYKhuLP4wbCsTZCD3I8kEA=
+github.com/prometheus/procfs v0.1.3 h1:F0+tqvhOksq22sc6iCHF5WGlWjdwj92p0udFh1VFBS8=
 github.com/prometheus/procfs v0.1.3/go.mod h1:lV6e/gmhEcM9IjHGsFOCxxuZ+z1YqCvr4OA4YeYWdaU=
+github.com/rogpeppe/fastuuid v1.2.0/go.mod h1:jVj6XXZzXRy/MSR5jhDC/2q6DgLz+nrA6LYCDYWNEvQ=
 github.com/rogpeppe/go-internal v1.3.0/go.mod h1:M8bDsm7K2OlrFYOpmOWEs/qY81heoFRclV5y23lUDJ4=
 github.com/sirupsen/logrus v1.2.0/go.mod h1:LxeOpSwHxABJmUn/MG1IvRgCAasNZTLOkJPxbbu5VWo=
 github.com/sirupsen/logrus v1.4.2/go.mod h1:tLMulIdttU9McNUspp0xgXVQah82FyeX6MwdIuYE2rE=
+github.com/sirupsen/logrus v1.6.0 h1:UBcNElsrwanuuMsnGSlYmtmgbb23qDR5dG+6X6Oo89I=
 github.com/sirupsen/logrus v1.6.0/go.mod h1:7uNnSEd1DgxDLC74fIahvMZmmYsHGZGEOFrfsX/uA88=
+github.com/soheilhy/cmux v0.1.5 h1:jjzc5WVemNEDTLwv9tlmemhC73tI08BNOIGwBOo10Js=
+github.com/soheilhy/cmux v0.1.5/go.mod h1:T7TcVDs9LWfQgPlPsdngu6I6QIoyIFZDDC6sNE1GqG0=
 github.com/spf13/afero v1.2.2/go.mod h1:9ZxEEn6pIJ8Rxe320qSDBk6AsU0r9pR7Q4OcevTdifk=
 github.com/spf13/pflag v0.0.0-20170130214245-9ff6c6923cff/go.mod h1:DYY7MBk1bdzusC3SYhjObp+wFpr4gzcvqqNjLnInEg4=
 github.com/spf13/pflag v1.0.3/go.mod h1:DYY7MBk1bdzusC3SYhjObp+wFpr4gzcvqqNjLnInEg4=
@@ -182,12 +231,24 @@ github.com/stretchr/testify v1.3.0/go.mod h1:M5WIy9Dh21IEIfnGCwXGc5bZfKNJtfHm1UV
 github.com/stretchr/testify v1.4.0/go.mod h1:j7eGeouHqKxXV5pUuKE4zz7dFj8WfuZ+81PSLYec5m4=
 github.com/stretchr/testify v1.5.1 h1:nOGnQDM7FYENwehXlg/kFVnos3rEvtKTjRvOWSzb6H4=
 github.com/stretchr/testify v1.5.1/go.mod h1:5W2xD1RspED5o8YsWQXVCued0rvSQ+mT+I5cxcmMvtA=
-github.com/yuin/goldmark v1.4.13/go.mod h1:6yULJ656Px+3vBD8DxQVa3kxgyrAnzto9xy5taEt/CY=
+github.com/tmc/grpc-websocket-proxy v0.0.0-20201229170055-e5319fda7802 h1:uruHq4dN7GR16kFc5fp3d1RIYzJW5onx8Ybykw2YQFA=
+github.com/tmc/grpc-websocket-proxy v0.0.0-20201229170055-e5319fda7802/go.mod h1:ncp9v5uamzpCO7NfCPTXjqaC+bZgJeR0sMTm6dMHP7U=
+github.com/xiang90/probing v0.0.0-20190116061207-43a291ad63a2 h1:eY9dn8+vbi4tKz5Qo6v2eYzo7kUS51QINcR5jNpbZS8=
+github.com/xiang90/probing v0.0.0-20190116061207-43a291ad63a2/go.mod h1:UETIi67q53MR2AWcXfiuqkDkRtnGDLqkBTpCHuJHxtU=
+github.com/yuin/goldmark v1.1.27/go.mod h1:3hX8gzYuyVAZsxl0MRgGTJEmQBFcNTphYh9decYSb74=
+github.com/yuin/goldmark v1.2.1/go.mod h1:3hX8gzYuyVAZsxl0MRgGTJEmQBFcNTphYh9decYSb74=
+go.etcd.io/bbolt v1.3.5 h1:XAzx9gjCb0Rxj7EoqcClPD1d5ZBxZJk0jbuoPHenBt0=
+go.etcd.io/bbolt v1.3.5/go.mod h1:G5EMThwa9y8QZGBClrRx5EY+Yw9kAhnjy3bSjsnlVTQ=
+go.etcd.io/etcd v3.3.25+incompatible h1:V1RzkZJj9LqsJRy+TUBgpWSbZXITLB819lstuTFoZOY=
+go.etcd.io/etcd v3.3.25+incompatible/go.mod h1:yaeTdrJi5lOmYerz05bd8+V7KubZs8YSFZfzsF9A6aI=
 go.opencensus.io v0.21.0/go.mod h1:mSImk1erAIZhrmZN+AvHh14ztQfjbGwt4TtuofqLduU=
 go.opencensus.io v0.22.0/go.mod h1:+kGneAE2xo2IficOXnaByMWTGM9T73dGwxeWcUqIpI8=
 go.opencensus.io v0.22.2/go.mod h1:yxeiOL68Rb0Xd1ddK5vPZ/oVn4vY4Ynel7k9FzqtOIw=
+go.uber.org/atomic v1.4.0 h1:cxzIVoETapQEqDhQu3QfnvXAV4AlzcvUCxkVUFw3+EU=
 go.uber.org/atomic v1.4.0/go.mod h1:gD2HeocX3+yG+ygLZcrzQJaqmWj9AIm7n08wl/qW/PE=
+go.uber.org/multierr v1.1.0 h1:HoEmRHQPVSqub6w2z2d2EOVs2fjyFRGyofhKuyDq0QI=
 go.uber.org/multierr v1.1.0/go.mod h1:wR5kodmAFQ0UK8QlbwjlSNy0Z68gJhDJUG5sjR94q/0=
+go.uber.org/zap v1.10.0 h1:ORx85nbTijNz8ljznvCMR1ZBIPKFn3jQrag10X2AsuM=
 go.uber.org/zap v1.10.0/go.mod h1:vwi/ZaCAaUcBkycHslxD9B2zi4UTXhF60s6SWpuDF0Q=
 golang.org/x/crypto v0.0.0-20180904163835-0709b304e793/go.mod h1:6SG95UA2DQfeDnfUPMdvaQW0Q7yPrPDi9nlGo2tz2b4=
 golang.org/x/crypto v0.0.0-20190308221718-c2843e01d9a2/go.mod h1:djNgcEr1/C05ACkg1iLfiJU5Ep61QUkGW8qpdssI0+w=
@@ -195,8 +256,8 @@ golang.org/x/crypto v0.0.0-20190510104115-cbcb75029529/go.mod h1:yigFU9vqHzYiE8U
 golang.org/x/crypto v0.0.0-20190605123033-f99c8df09eb5/go.mod h1:yigFU9vqHzYiE8UmvKecakEJjdnWj3jj499lnFckfCI=
 golang.org/x/crypto v0.0.0-20191011191535-87dc89f01550/go.mod h1:yigFU9vqHzYiE8UmvKecakEJjdnWj3jj499lnFckfCI=
 golang.org/x/crypto v0.0.0-20191206172530-e9b2fee46413/go.mod h1:LzIPMQfyMNhhGPhUkYOs5KpL4U8rLKemX1yGLhDgUto=
+golang.org/x/crypto v0.0.0-20200622213623-75b288015ac9 h1:psW17arqaxU48Z5kZ0CQnkZWQJsqcURM6tKiBApRjXI=
 golang.org/x/crypto v0.0.0-20200622213623-75b288015ac9/go.mod h1:LzIPMQfyMNhhGPhUkYOs5KpL4U8rLKemX1yGLhDgUto=
-golang.org/x/crypto v0.0.0-20210921155107-089bfa567519/go.mod h1:GvvjBRRGRdwPK5ydBHafDWAxML/pGHZbMvKqRZ5+Abc=
 golang.org/x/exp v0.0.0-20190121172915-509febef88a4/go.mod h1:CJ0aWSM057203Lf6IL+f9T1iT9GByDxfZKAQTCR3kQA=
 golang.org/x/exp v0.0.0-20190306152737-a1d7652674e8/go.mod h1:CJ0aWSM057203Lf6IL+f9T1iT9GByDxfZKAQTCR3kQA=
 golang.org/x/exp v0.0.0-20190510132918-efd6b22b2522/go.mod h1:ZjyILWgesfNpC6sMxTJOJm9Kp84zZh5NQWvqDGG3Qr8=
@@ -215,7 +276,8 @@ golang.org/x/mobile v0.0.0-20190719004257-d2bd2a29d028/go.mod h1:E/iHnbuqvinMTCc
 golang.org/x/mod v0.0.0-20190513183733-4bf6d317e70e/go.mod h1:mXi4GBBbnImb6dmsKGUJ2LatrhH/nqhxcFungHvyanc=
 golang.org/x/mod v0.1.0/go.mod h1:0QHyrYULN0/3qlju5TqG8bIK38QM8yzMo5ekMj3DlcY=
 golang.org/x/mod v0.1.1-0.20191105210325-c90efee705ee/go.mod h1:QqPTAvyqsEbceGzBzNggFXnrqF1CaUcvgkdR5Ot7KZg=
-golang.org/x/mod v0.6.0-dev.0.20220419223038-86c51ed26bb4/go.mod h1:jJ57K6gSWd91VN4djpZkiMVwK6gcyfeH4XE8wZrZaV4=
+golang.org/x/mod v0.2.0/go.mod h1:s0Qsj1ACt9ePp/hMypM3fl4fZqREWJwdYDEqhRiZZUA=
+golang.org/x/mod v0.3.0/go.mod h1:s0Qsj1ACt9ePp/hMypM3fl4fZqREWJwdYDEqhRiZZUA=
 golang.org/x/net v0.0.0-20180724234803-3673e40ba225/go.mod h1:mL1N/T3taQHkDXs73rZJwtUhF3w3ftmwwsq0BUmARs4=
 golang.org/x/net v0.0.0-20180906233101-161cd47e91fd/go.mod h1:mL1N/T3taQHkDXs73rZJwtUhF3w3ftmwwsq0BUmARs4=
 golang.org/x/net v0.0.0-20181114220301-adae6a3d119a/go.mod h1:mL1N/T3taQHkDXs73rZJwtUhF3w3ftmwwsq0BUmARs4=
@@ -229,23 +291,26 @@ golang.org/x/net v0.0.0-20190603091049-60506f45cf65/go.mod h1:HSz+uSET+XFnRR8LxR
 golang.org/x/net v0.0.0-20190613194153-d28f0bde5980/go.mod h1:z5CRVTTTmAJ677TzLLGU+0bjPO0LkuOLi4/5GtJWs/s=
 golang.org/x/net v0.0.0-20190620200207-3b0461eec859/go.mod h1:z5CRVTTTmAJ677TzLLGU+0bjPO0LkuOLi4/5GtJWs/s=
 golang.org/x/net v0.0.0-20191209160850-c0dbc17a3553/go.mod h1:z5CRVTTTmAJ677TzLLGU+0bjPO0LkuOLi4/5GtJWs/s=
+golang.org/x/net v0.0.0-20200226121028-0de0cce0169b/go.mod h1:z5CRVTTTmAJ677TzLLGU+0bjPO0LkuOLi4/5GtJWs/s=
 golang.org/x/net v0.0.0-20200324143707-d3edc9973b7e/go.mod h1:qpuaurCH72eLCgpAm/N6yyVIVM9cpaDIP3A8BGJEC5A=
+golang.org/x/net v0.0.0-20200707034311-ab3426394381 h1:VXak5I6aEWmAXeQjA+QSZzlgNrpq9mjcfDemuexIKsU=
 golang.org/x/net v0.0.0-20200707034311-ab3426394381/go.mod h1:/O7V0waA8r7cgGh81Ro3o1hOxt32SMVPicZroKQ2sZA=
-golang.org/x/net v0.0.0-20210226172049-e18ecbb05110/go.mod h1:m0MpNAwzfU5UDzcl9v0D8zg8gWTRqZa9RBIspLL5mdg=
-golang.org/x/net v0.0.0-20220722155237-a158d28d115b/go.mod h1:XRhObCWvk6IyKnWLug+ECip1KBveYUHfp+8e9klMJ9c=
-golang.org/x/net v0.7.0 h1:rJrUqqhjsgNp7KqAIc25s9pZnjU7TUcSY7HcVZjdn1g=
-golang.org/x/net v0.7.0/go.mod h1:2Tu9+aMcznHK/AK1HMvgo6xiTLG5rD5rZLDS+rp2Bjs=
+golang.org/x/net v0.0.0-20200822124328-c89045814202/go.mod h1:/O7V0waA8r7cgGh81Ro3o1hOxt32SMVPicZroKQ2sZA=
+golang.org/x/net v0.0.0-20201021035429-f5854403a974/go.mod h1:sp8m0HH+o8qH0wwXwYZr8TS3Oi6o0r6Gce1SSxlDquU=
+golang.org/x/net v0.0.0-20201202161906-c7110b5ffcbb h1:eBmm0M9fYhWpKZLjQUUKka/LtIxf46G4fxeEz5KJr9U=
+golang.org/x/net v0.0.0-20201202161906-c7110b5ffcbb/go.mod h1:sp8m0HH+o8qH0wwXwYZr8TS3Oi6o0r6Gce1SSxlDquU=
 golang.org/x/oauth2 v0.0.0-20180821212333-d2e6202438be/go.mod h1:N/0e6XlmueqKjAGxoOufVs8QHGRruUQn6yWY3a++T0U=
 golang.org/x/oauth2 v0.0.0-20190226205417-e64efc72b421/go.mod h1:gOpvHmFTYa4IltrdGE7lF6nIHvwfUNPOp7c8zoXwtLw=
 golang.org/x/oauth2 v0.0.0-20190604053449-0f29369cfe45/go.mod h1:gOpvHmFTYa4IltrdGE7lF6nIHvwfUNPOp7c8zoXwtLw=
 golang.org/x/oauth2 v0.0.0-20191202225959-858c2ad4c8b6/go.mod h1:gOpvHmFTYa4IltrdGE7lF6nIHvwfUNPOp7c8zoXwtLw=
+golang.org/x/oauth2 v0.0.0-20200107190931-bf48bf16ab8d/go.mod h1:gOpvHmFTYa4IltrdGE7lF6nIHvwfUNPOp7c8zoXwtLw=
 golang.org/x/sync v0.0.0-20180314180146-1d60e4601c6f/go.mod h1:RxMgew5VJxzue5/jJTE5uejpjVlOe/izrB70Jof72aM=
 golang.org/x/sync v0.0.0-20181108010431-42b317875d0f/go.mod h1:RxMgew5VJxzue5/jJTE5uejpjVlOe/izrB70Jof72aM=
 golang.org/x/sync v0.0.0-20181221193216-37e7f081c4d4/go.mod h1:RxMgew5VJxzue5/jJTE5uejpjVlOe/izrB70Jof72aM=
 golang.org/x/sync v0.0.0-20190227155943-e225da77a7e6/go.mod h1:RxMgew5VJxzue5/jJTE5uejpjVlOe/izrB70Jof72aM=
 golang.org/x/sync v0.0.0-20190423024810-112230192c58/go.mod h1:RxMgew5VJxzue5/jJTE5uejpjVlOe/izrB70Jof72aM=
 golang.org/x/sync v0.0.0-20190911185100-cd5d95a43a6e/go.mod h1:RxMgew5VJxzue5/jJTE5uejpjVlOe/izrB70Jof72aM=
-golang.org/x/sync v0.0.0-20220722155255-886fb9371eb4/go.mod h1:RxMgew5VJxzue5/jJTE5uejpjVlOe/izrB70Jof72aM=
+golang.org/x/sync v0.0.0-20201020160332-67f06af15bc9/go.mod h1:RxMgew5VJxzue5/jJTE5uejpjVlOe/izrB70Jof72aM=
 golang.org/x/sys v0.0.0-20180905080454-ebe1bf3edb33/go.mod h1:STP8DvDyc/dI5b8T5hshtkjS+E42TnysNCUPdjciGhY=
 golang.org/x/sys v0.0.0-20180909124046-d0be0721c37e/go.mod h1:STP8DvDyc/dI5b8T5hshtkjS+E42TnysNCUPdjciGhY=
 golang.org/x/sys v0.0.0-20181116152217-5ac8a444bdc5/go.mod h1:STP8DvDyc/dI5b8T5hshtkjS+E42TnysNCUPdjciGhY=
@@ -261,28 +326,22 @@ golang.org/x/sys v0.0.0-20191005200804-aed5e4c7ecf9/go.mod h1:h1NjWce9XRLGQEsW7w
 golang.org/x/sys v0.0.0-20191204072324-ce4227a45e2e/go.mod h1:h1NjWce9XRLGQEsW7wpKNCjG9DtNlClVuFLEZdDNbEs=
 golang.org/x/sys v0.0.0-20191228213918-04cbcbbfeed8/go.mod h1:h1NjWce9XRLGQEsW7wpKNCjG9DtNlClVuFLEZdDNbEs=
 golang.org/x/sys v0.0.0-20200106162015-b016eb3dc98e/go.mod h1:h1NjWce9XRLGQEsW7wpKNCjG9DtNlClVuFLEZdDNbEs=
+golang.org/x/sys v0.0.0-20200202164722-d101bd2416d5/go.mod h1:h1NjWce9XRLGQEsW7wpKNCjG9DtNlClVuFLEZdDNbEs=
 golang.org/x/sys v0.0.0-20200302150141-5c8b2ff67527/go.mod h1:h1NjWce9XRLGQEsW7wpKNCjG9DtNlClVuFLEZdDNbEs=
 golang.org/x/sys v0.0.0-20200323222414-85ca7c5b95cd/go.mod h1:h1NjWce9XRLGQEsW7wpKNCjG9DtNlClVuFLEZdDNbEs=
 golang.org/x/sys v0.0.0-20200615200032-f1bc736245b1/go.mod h1:h1NjWce9XRLGQEsW7wpKNCjG9DtNlClVuFLEZdDNbEs=
+golang.org/x/sys v0.0.0-20200622214017-ed371f2e16b4 h1:5/PjkGUjvEU5Gl6BxmvKRPpqo2uNMv4rcHBMwzk/st8=
 golang.org/x/sys v0.0.0-20200622214017-ed371f2e16b4/go.mod h1:h1NjWce9XRLGQEsW7wpKNCjG9DtNlClVuFLEZdDNbEs=
-golang.org/x/sys v0.0.0-20201119102817-f84b799fce68/go.mod h1:h1NjWce9XRLGQEsW7wpKNCjG9DtNlClVuFLEZdDNbEs=
-golang.org/x/sys v0.0.0-20210615035016-665e8c7367d1/go.mod h1:oPkhp1MJrh7nUepCBck5+mAzfO9JrbApNNgaTdGDITg=
-golang.org/x/sys v0.0.0-20220520151302-bc2c85ada10a/go.mod h1:oPkhp1MJrh7nUepCBck5+mAzfO9JrbApNNgaTdGDITg=
-golang.org/x/sys v0.0.0-20220722155257-8c9f86f7a55f/go.mod h1:oPkhp1MJrh7nUepCBck5+mAzfO9JrbApNNgaTdGDITg=
-golang.org/x/sys v0.5.0 h1:MUK/U/4lj1t1oPg0HfuXDN/Z1wv31ZJ/YcPiGccS4DU=
-golang.org/x/sys v0.5.0/go.mod h1:oPkhp1MJrh7nUepCBck5+mAzfO9JrbApNNgaTdGDITg=
-golang.org/x/term v0.0.0-20201126162022-7de9c90e9dd1/go.mod h1:bj7SfCRtBDWHUb9snDiAeCFNEtKQo2Wmx5Cou7ajbmo=
-golang.org/x/term v0.0.0-20210927222741-03fcf44c2211/go.mod h1:jbD1KX2456YbFQfuXm/mYQcufACuNUgVhRMnK/tPxf8=
-golang.org/x/term v0.5.0/go.mod h1:jMB1sMXY+tzblOD4FWmEbocvup2/aLOaQEp7JmGp78k=
+golang.org/x/sys v0.0.0-20200930185726-fdedc70b468f h1:+Nyd8tzPX9R7BWHguqsrbFdRx3WQ/1ib8I44HXV5yTA=
+golang.org/x/sys v0.0.0-20200930185726-fdedc70b468f/go.mod h1:h1NjWce9XRLGQEsW7wpKNCjG9DtNlClVuFLEZdDNbEs=
 golang.org/x/text v0.3.0/go.mod h1:NqM8EUOU14njkJ3fqMW+pc6Ldnwhi/IjpwHt7yyuwOQ=
 golang.org/x/text v0.3.1-0.20180807135948-17ff2d5776d2/go.mod h1:NqM8EUOU14njkJ3fqMW+pc6Ldnwhi/IjpwHt7yyuwOQ=
 golang.org/x/text v0.3.2/go.mod h1:bEr9sfX3Q8Zfm5fL9x+3itogRgK3+ptLWKqgva+5dAk=
+golang.org/x/text v0.3.3 h1:cokOdA+Jmi5PJGXLlLllQSgYigAEfHXJAERHVMaCc2k=
 golang.org/x/text v0.3.3/go.mod h1:5Zoc/QRtKVWzQhOtBMvqHzDpF6irO9z98xDceosuGiQ=
-golang.org/x/text v0.3.7/go.mod h1:u+2+/6zg+i71rQMx5EYifcz6MCKuco9NR6JIITiCfzQ=
-golang.org/x/text v0.7.0 h1:4BRB4x83lYWy72KwLD/qYDuTu7q9PjSagHvijDw7cLo=
-golang.org/x/text v0.7.0/go.mod h1:mrYo+phRRbMaCq/xk9113O4dZlRixOauAjOtrjsXDZ8=
 golang.org/x/time v0.0.0-20181108054448-85acf8d2951c/go.mod h1:tRJNPiyCQ0inRvYxbN9jk5I+vvW/OXSQhTDSoE431IQ=
 golang.org/x/time v0.0.0-20190308202827-9d24e82272b4/go.mod h1:tRJNPiyCQ0inRvYxbN9jk5I+vvW/OXSQhTDSoE431IQ=
+golang.org/x/time v0.0.0-20191024005414-555d28b269f0 h1:/5xXl8Y5W96D+TtHSlonuFqGHIWVuyCkGJLwGh9JJFs=
 golang.org/x/time v0.0.0-20191024005414-555d28b269f0/go.mod h1:tRJNPiyCQ0inRvYxbN9jk5I+vvW/OXSQhTDSoE431IQ=
 golang.org/x/tools v0.0.0-20180917221912-90fa682c2a6e/go.mod h1:n7NCudcB/nEzxVGmLbDWY5pfWTLqBcC2KZ6jyYvM4mQ=
 golang.org/x/tools v0.0.0-20181011042414-1f849cf54d09/go.mod h1:n7NCudcB/nEzxVGmLbDWY5pfWTLqBcC2KZ6jyYvM4mQ=
@@ -304,9 +363,11 @@ golang.org/x/tools v0.0.0-20191012152004-8de300cfc20a/go.mod h1:b+2E5dAYhXwXZwtn
 golang.org/x/tools v0.0.0-20191119224855-298f0cb1881e/go.mod h1:b+2E5dAYhXwXZwtnZ6UAqBI28+e2cm9otk0dWdXHAEo=
 golang.org/x/tools v0.0.0-20191125144606-a911d9008d1f/go.mod h1:b+2E5dAYhXwXZwtnZ6UAqBI28+e2cm9otk0dWdXHAEo=
 golang.org/x/tools v0.0.0-20191227053925-7b8e75db28f4/go.mod h1:TB2adYChydJhpapKDTa4BR/hXlZSLoq2Wpct/0txZ28=
-golang.org/x/tools v0.1.12/go.mod h1:hNGJHUnrk76NpqgfD5Aqm5Crs+Hm0VOH/i9J2+nxYbc=
+golang.org/x/tools v0.0.0-20200619180055-7c47624df98f/go.mod h1:EkVYQZoAsY45+roYkvgYkIh4xh/qjgUK9TdY2XT94GE=
+golang.org/x/tools v0.0.0-20210106214847-113979e3529a/go.mod h1:emZCQorbCU4vsT4fOWvOPXz4eW1wZW4PmDk9uLelYpA=
 golang.org/x/xerrors v0.0.0-20190717185122-a985d3407aa7/go.mod h1:I/5z698sn9Ka8TeJc9MKroUUfqBBauWjQqLJ2OPfmY0=
 golang.org/x/xerrors v0.0.0-20191011141410-1b5146add898/go.mod h1:I/5z698sn9Ka8TeJc9MKroUUfqBBauWjQqLJ2OPfmY0=
+golang.org/x/xerrors v0.0.0-20191204190536-9bdfabe68543 h1:E7g+9GITq07hpfrRu66IVDexMakfv52eLZ2CXBWiKr4=
 golang.org/x/xerrors v0.0.0-20191204190536-9bdfabe68543/go.mod h1:I/5z698sn9Ka8TeJc9MKroUUfqBBauWjQqLJ2OPfmY0=
 golang.org/x/xerrors v0.0.0-20200804184101-5ec99f83aff1 h1:go1bK/D/BFZV2I8cIQd1NKEZ+0owSTG1fDTci4IqFcE=
 golang.org/x/xerrors v0.0.0-20200804184101-5ec99f83aff1/go.mod h1:I/5z698sn9Ka8TeJc9MKroUUfqBBauWjQqLJ2OPfmY0=
@@ -327,6 +388,8 @@ google.golang.org/genproto v0.0.0-20190801165951-fa694d86fc64/go.mod h1:DMBHOl98
 google.golang.org/genproto v0.0.0-20190819201941-24fa4b261c55/go.mod h1:DMBHOl98Agz4BDEuKkezgsaosCRResVns1a3J2ZsMNc=
 google.golang.org/genproto v0.0.0-20190911173649-1774047e7e51/go.mod h1:IbNlFCBrqXvoKpeg0TB2l7cyZUmoaFKYIwrEpbDKLA8=
 google.golang.org/genproto v0.0.0-20191230161307-f3c370f40bfb/go.mod h1:n3cpQtvxv34hfy77yVDNjmbRyujviMdxYliBSkLhpCc=
+google.golang.org/genproto v0.0.0-20200423170343-7949de9c1215/go.mod h1:55QSHmfGQM9UVYDPBsyGGes0y52j32PQ3BqQfXhyH3c=
+google.golang.org/genproto v0.0.0-20200513103714-09dca8ec2884/go.mod h1:55QSHmfGQM9UVYDPBsyGGes0y52j32PQ3BqQfXhyH3c=
 google.golang.org/genproto v0.0.0-20200526211855-cb27e3aa2013 h1:+kGHl1aib/qcwaRi1CbqBZ1rk19r85MNUf8HaBghugY=
 google.golang.org/genproto v0.0.0-20200526211855-cb27e3aa2013/go.mod h1:NbSheEEYHJ7i3ixzK3sjbqSGDJWnxyFXZblF3eUsNvo=
 google.golang.org/grpc v1.25.1 h1:wdKvqQk7IttEw92GoRyKG2IDrUIpgpj6H6m81yfeMW0=
@@ -352,6 +415,7 @@ gopkg.in/inf.v0 v0.9.1/go.mod h1:cWUDdTG/fYaXco+Dcufb5Vnc6Gp2YChqWtbxRZE0mXw=
 gopkg.in/tomb.v1 v1.0.0-20141024135613-dd632973f1e7/go.mod h1:dt/ZhP58zS4L8KSrWDmTeBkI65Dw0HsyUHuEVlX15mw=
 gopkg.in/yaml.v2 v2.2.1/go.mod h1:hI93XBmqTisBFMUTm0b8Fm+jr3Dg1NNxqwp+5A1VGuI=
 gopkg.in/yaml.v2 v2.2.2/go.mod h1:hI93XBmqTisBFMUTm0b8Fm+jr3Dg1NNxqwp+5A1VGuI=
+gopkg.in/yaml.v2 v2.2.3/go.mod h1:hI93XBmqTisBFMUTm0b8Fm+jr3Dg1NNxqwp+5A1VGuI=
 gopkg.in/yaml.v2 v2.2.4/go.mod h1:hI93XBmqTisBFMUTm0b8Fm+jr3Dg1NNxqwp+5A1VGuI=
 gopkg.in/yaml.v2 v2.2.5/go.mod h1:hI93XBmqTisBFMUTm0b8Fm+jr3Dg1NNxqwp+5A1VGuI=
 gopkg.in/yaml.v2 v2.2.8 h1:obN1ZagJSUGI0Ek/LBmuj4SNLPfIny3KsKFopxRdj10=
@@ -380,4 +444,5 @@ k8s.io/utils v0.0.0-20210305010621-2afb4311ab10/go.mod h1:jPW/WVKK9YHAvNhRxK0md/
 rsc.io/binaryregexp v0.2.0/go.mod h1:qTv7/COck+e2FymRvadv62gMdZztPaShugOCi3I+8D8=
 sigs.k8s.io/structured-merge-diff/v4 v4.0.1/go.mod h1:bJZC9H9iH24zzfZ/41RGcq60oK1F7G282QMXDPYydCw=
 sigs.k8s.io/yaml v1.1.0/go.mod h1:UJmg0vDUVViEyp3mgSv9WPwZCDxu4rQW1olrI1uml+o=
+sigs.k8s.io/yaml v1.2.0 h1:kr/MCeFWJWTwyaHoR9c8EjH9OumOmoF9YGiZd7lFm/Q=
 sigs.k8s.io/yaml v1.2.0/go.mod h1:yfXDCHCao9+ENCvLSE62v9VSji2MKu5jeNfTrofGhJc=

csi/src/config.go

@@ -5,7 +5,7 @@ package vitastor
 
 const (
     vitastorCSIDriverName    = "csi.vitastor.io"
-    vitastorCSIDriverVersion = "1.9.3"
+    vitastorCSIDriverVersion = "0.6.10"
 )
 
 // Config struct fills the parameters of request or user input

csi/src/controllerserver.go

@@ -6,11 +6,13 @@ package vitastor
 import (
     "context"
     "encoding/json"
-    "fmt"
     "strings"
+    "bytes"
     "strconv"
     "time"
+    "fmt"
     "os"
+    "os/exec"
     "io/ioutil"
 
     "github.com/kubernetes-csi/csi-lib-utils/protosanitizer"
@@ -18,7 +20,8 @@ import (
 
     "google.golang.org/grpc/codes"
     "google.golang.org/grpc/status"
-    "google.golang.org/protobuf/types/known/timestamppb"
+
+    "go.etcd.io/etcd/clientv3"
 
     "github.com/container-storage-interface/spec/lib/go/csi"
 )
@@ -44,7 +47,6 @@ type InodeConfig struct
     ParentPool uint64 `json:"parent_pool,omitempty"`
     ParentId uint64 `json:"parent_id,omitempty"`
     Readonly bool `json:"readonly,omitempty"`
-    CreateTs uint64 `json:"create_ts,omitempty"`
 }
 
 type ControllerServer struct
@@ -60,7 +62,7 @@ func NewControllerServer(driver *Driver) *ControllerServer
     }
 }
 
-func GetConnectionParams(params map[string]string) (map[string]string, error)
+func GetConnectionParams(params map[string]string) (map[string]string, []string, string)
 {
     ctxVars := make(map[string]string)
     configPath := params["configPath"]
@@ -73,53 +75,43 @@ func GetConnectionParams(params map[string]string) (map[string]string, error)
         ctxVars["configPath"] = configPath
     }
     config := make(map[string]interface{})
-    configFD, err := os.Open(configPath)
-    if (err != nil)
+    if configFD, err := os.Open(configPath); err == nil
     {
-        return nil, err
+        defer configFD.Close()
+        data, _ := ioutil.ReadAll(configFD)
+        json.Unmarshal(data, &config)
     }
-    defer configFD.Close()
-    data, _ := ioutil.ReadAll(configFD)
-    json.Unmarshal(data, &config)
-    // Check etcd URL in the config, but do not use the explicit etcdUrl
-    // parameter for CLI calls, otherwise users won't be able to later
-    // change them - storage class parameters are saved in volume IDs
+    // Try to load prefix & etcd URL from the config
     var etcdUrl []string
-    switch config["etcd_address"].(type)
+    if (params["etcdUrl"] != "")
     {
-    case string:
-        url := strings.TrimSpace(config["etcd_address"].(string))
-        if (url != "")
-        {
-            etcdUrl = strings.Split(url, ",")
-        }
-    case []string:
-        etcdUrl = config["etcd_address"].([]string)
-    case []interface{}:
-        for _, url := range config["etcd_address"].([]interface{})
-        {
-            s, ok := url.(string)
-            if (ok)
-            {
-                etcdUrl = append(etcdUrl, s)
-            }
-        }
+        ctxVars["etcdUrl"] = params["etcdUrl"]
+        etcdUrl = strings.Split(params["etcdUrl"], ",")
     }
     if (len(etcdUrl) == 0)
     {
-        return nil, status.Error(codes.InvalidArgument, "etcd_address is missing in "+configPath)
+        switch config["etcd_address"].(type)
+        {
+        case string:
+            etcdUrl = strings.Split(config["etcd_address"].(string), ",")
+        case []string:
+            etcdUrl = config["etcd_address"].([]string)
+        }
     }
-    return ctxVars, nil
-}
-
-func invokeCLI(ctxVars map[string]string, args []string) ([]byte, error)
-{
-    if (ctxVars["configPath"] != "")
+    etcdPrefix := params["etcdPrefix"]
+    if (etcdPrefix == "")
     {
-        args = append(args, "--config_path", ctxVars["configPath"])
+        etcdPrefix, _ = config["etcd_prefix"].(string)
+        if (etcdPrefix == "")
+        {
+            etcdPrefix = "/vitastor"
+        }
     }
-    stdout, _, err := system("/usr/bin/vitastor-cli", args...)
-    return stdout, err
+    else
+    {
+        ctxVars["etcdPrefix"] = etcdPrefix
+    }
+    return ctxVars, etcdUrl, etcdPrefix
 }
 
 // Create the volume
@@ -140,12 +132,6 @@ func (cs *ControllerServer) CreateVolume(ctx context.Context, req *csi.CreateVol
         return nil, status.Error(codes.InvalidArgument, "volume capabilities is a required field")
     }
 
-    err := cs.checkCaps(volumeCapabilities)
-    if (err != nil)
-    {
-        return nil, err
-    }
-
     etcdVolumePrefix := req.Parameters["etcdVolumePrefix"]
     poolId, _ := strconv.ParseUint(req.Parameters["poolId"], 10, 64)
     if (poolId == 0)
@@ -160,57 +146,128 @@ func (cs *ControllerServer) CreateVolume(ctx context.Context, req *csi.CreateVol
         volSize = ((capRange.GetRequiredBytes() + MB - 1) / MB) * MB
     }
 
-    ctxVars, err := GetConnectionParams(req.Parameters)
-    if (err != nil)
+    // FIXME: The following should PROBABLY be implemented externally in a management tool
+
+    ctxVars, etcdUrl, etcdPrefix := GetConnectionParams(req.Parameters)
+    if (len(etcdUrl) == 0)
     {
-        return nil, err
+        return nil, status.Error(codes.InvalidArgument, "no etcdUrl in storage class configuration and no etcd_address in vitastor.conf")
     }
 
-    args := []string{ "create", volName, "-s", fmt.Sprintf("%v", volSize), "--pool", fmt.Sprintf("%v", poolId) }
-
-    // Support creation from snapshot
-    var src *csi.VolumeContentSource
-    if (req.VolumeContentSource.GetSnapshot() != nil)
+    // Connect to etcd
+    cli, err := clientv3.New(clientv3.Config{
+        DialTimeout: ETCD_TIMEOUT,
+        Endpoints: etcdUrl,
+    })
+    if (err != nil)
     {
-        snapId := req.VolumeContentSource.GetSnapshot().GetSnapshotId()
-        if (snapId != "")
+        return nil, status.Error(codes.Internal, "failed to connect to etcd at "+strings.Join(etcdUrl, ",")+": "+err.Error())
+    }
+    defer cli.Close()
+
+    var imageId uint64 = 0
+    for
+    {
+        // Check if the image exists
+        ctx, cancel := context.WithTimeout(context.Background(), ETCD_TIMEOUT)
+        resp, err := cli.Get(ctx, etcdPrefix+"/index/image/"+volName)
+        cancel()
+        if (err != nil)
         {
-            snapVars := make(map[string]string)
-            err := json.Unmarshal([]byte(snapId), &snapVars)
-            if (err != nil)
-            {
-                return nil, status.Error(codes.Internal, "volume ID not in JSON format")
-            }
-            args = append(args, "--parent", snapVars["name"]+"@"+snapVars["snapshot"])
-            src = &csi.VolumeContentSource{
-                Type: &csi.VolumeContentSource_Snapshot{
-                    Snapshot: &csi.VolumeContentSource_SnapshotSource{
-                        SnapshotId: snapId,
-                    },
-                },
-            }
+            return nil, status.Error(codes.Internal, "failed to read key from etcd: "+err.Error())
         }
-    }
-
-    // Create image using vitastor-cli
-    _, err = invokeCLI(ctxVars, args)
-    if (err != nil)
-    {
-        if (strings.Index(err.Error(), "already exists") > 0)
+        if (len(resp.Kvs) > 0)
         {
-            inodeCfg, err := invokeList(ctxVars, volName, true)
+            kv := resp.Kvs[0]
+            var v InodeIndex
+            err := json.Unmarshal(kv.Value, &v)
             if (err != nil)
             {
-                return nil, err
+                return nil, status.Error(codes.Internal, "invalid /index/image/"+volName+" key in etcd: "+err.Error())
             }
-            if (inodeCfg[0].Size < uint64(volSize))
+            poolId = v.PoolId
+            imageId = v.Id
+            inodeCfgKey := fmt.Sprintf("/config/inode/%d/%d", poolId, imageId)
+            ctx, cancel := context.WithTimeout(context.Background(), ETCD_TIMEOUT)
+            resp, err := cli.Get(ctx, etcdPrefix+inodeCfgKey)
+            cancel()
+            if (err != nil)
+            {
+                return nil, status.Error(codes.Internal, "failed to read key from etcd: "+err.Error())
+            }
+            if (len(resp.Kvs) == 0)
+            {
+                return nil, status.Error(codes.Internal, "missing "+inodeCfgKey+" key in etcd")
+            }
+            var inodeCfg InodeConfig
+            err = json.Unmarshal(resp.Kvs[0].Value, &inodeCfg)
+            if (err != nil)
+            {
+                return nil, status.Error(codes.Internal, "invalid "+inodeCfgKey+" key in etcd: "+err.Error())
+            }
+            if (inodeCfg.Size < uint64(volSize))
             {
                 return nil, status.Error(codes.Internal, "image "+volName+" is already created, but size is less than expected")
             }
         }
         else
         {
-            return nil, err
+            // Find a free ID
+            // Create image metadata in a transaction verifying that the image doesn't exist yet AND ID is still free
+            maxIdKey := fmt.Sprintf("%s/index/maxid/%d", etcdPrefix, poolId)
+            ctx, cancel := context.WithTimeout(context.Background(), ETCD_TIMEOUT)
+            resp, err := cli.Get(ctx, maxIdKey)
+            cancel()
+            if (err != nil)
+            {
+                return nil, status.Error(codes.Internal, "failed to read key from etcd: "+err.Error())
+            }
+            var modRev int64
+            var nextId uint64
+            if (len(resp.Kvs) > 0)
+            {
+                var err error
+                nextId, err = strconv.ParseUint(string(resp.Kvs[0].Value), 10, 64)
+                if (err != nil)
+                {
+                    return nil, status.Error(codes.Internal, maxIdKey+" contains invalid ID")
+                }
+                modRev = resp.Kvs[0].ModRevision
+                nextId++
+            }
+            else
+            {
+                nextId = 1
+            }
+            inodeIdxJson, _ := json.Marshal(InodeIndex{
+                Id: nextId,
+                PoolId: poolId,
+            })
+            inodeCfgJson, _ := json.Marshal(InodeConfig{
+                Name: volName,
+                Size: uint64(volSize),
+            })
+            ctx, cancel = context.WithTimeout(context.Background(), ETCD_TIMEOUT)
+            txnResp, err := cli.Txn(ctx).If(
+                clientv3.Compare(clientv3.ModRevision(fmt.Sprintf("%s/index/maxid/%d", etcdPrefix, poolId)), "=", modRev),
+                clientv3.Compare(clientv3.CreateRevision(fmt.Sprintf("%s/index/image/%s", etcdPrefix, volName)), "=", 0),
+                clientv3.Compare(clientv3.CreateRevision(fmt.Sprintf("%s/config/inode/%d/%d", etcdPrefix, poolId, nextId)), "=", 0),
+            ).Then(
+                clientv3.OpPut(fmt.Sprintf("%s/index/maxid/%d", etcdPrefix, poolId), fmt.Sprintf("%d", nextId)),
+                clientv3.OpPut(fmt.Sprintf("%s/index/image/%s", etcdPrefix, volName), string(inodeIdxJson)),
+                clientv3.OpPut(fmt.Sprintf("%s/config/inode/%d/%d", etcdPrefix, poolId, nextId), string(inodeCfgJson)),
+            ).Commit()
+            cancel()
+            if (err != nil)
+            {
+                return nil, status.Error(codes.Internal, "failed to commit transaction in etcd: "+err.Error())
+            }
+            if (txnResp.Succeeded)
+            {
+                imageId = nextId
+                break
+            }
+            // Start over if the transaction fails
         }
     }
 
@@ -221,7 +278,6 @@ func (cs *ControllerServer) CreateVolume(ctx context.Context, req *csi.CreateVol
             // Ugly, but VolumeContext isn't passed to DeleteVolume :-(
             VolumeId: string(volumeIdJson),
             CapacityBytes: volSize,
-            ContentSource: src,
         },
     }, nil
 }
@@ -235,24 +291,105 @@ func (cs *ControllerServer) DeleteVolume(ctx context.Context, req *csi.DeleteVol
         return nil, status.Error(codes.InvalidArgument, "request cannot be empty")
     }
 
-    volVars := make(map[string]string)
-    err := json.Unmarshal([]byte(req.VolumeId), &volVars)
+    ctxVars := make(map[string]string)
+    err := json.Unmarshal([]byte(req.VolumeId), &ctxVars)
     if (err != nil)
     {
         return nil, status.Error(codes.Internal, "volume ID not in JSON format")
     }
-    volName := volVars["name"]
+    volName := ctxVars["name"]
 
-    ctxVars, err := GetConnectionParams(volVars)
-    if (err != nil)
+    _, etcdUrl, etcdPrefix := GetConnectionParams(ctxVars)
+    if (len(etcdUrl) == 0)
     {
-        return nil, err
+        return nil, status.Error(codes.InvalidArgument, "no etcdUrl in storage class configuration and no etcd_address in vitastor.conf")
     }
 
-    _, err = invokeCLI(ctxVars, []string{ "rm", volName })
+    cli, err := clientv3.New(clientv3.Config{
+        DialTimeout: ETCD_TIMEOUT,
+        Endpoints: etcdUrl,
+    })
     if (err != nil)
     {
-        return nil, err
+        return nil, status.Error(codes.Internal, "failed to connect to etcd at "+strings.Join(etcdUrl, ",")+": "+err.Error())
+    }
+    defer cli.Close()
+
+    // Find inode by name
+    ctx, cancel := context.WithTimeout(context.Background(), ETCD_TIMEOUT)
+    resp, err := cli.Get(ctx, etcdPrefix+"/index/image/"+volName)
+    cancel()
+    if (err != nil)
+    {
+        return nil, status.Error(codes.Internal, "failed to read key from etcd: "+err.Error())
+    }
+    if (len(resp.Kvs) == 0)
+    {
+        return nil, status.Error(codes.NotFound, "volume "+volName+" does not exist")
+    }
+    var idx InodeIndex
+    err = json.Unmarshal(resp.Kvs[0].Value, &idx)
+    if (err != nil)
+    {
+        return nil, status.Error(codes.Internal, "invalid /index/image/"+volName+" key in etcd: "+err.Error())
+    }
+
+    // Get inode config
+    inodeCfgKey := fmt.Sprintf("%s/config/inode/%d/%d", etcdPrefix, idx.PoolId, idx.Id)
+    ctx, cancel = context.WithTimeout(context.Background(), ETCD_TIMEOUT)
+    resp, err = cli.Get(ctx, inodeCfgKey)
+    cancel()
+    if (err != nil)
+    {
+        return nil, status.Error(codes.Internal, "failed to read key from etcd: "+err.Error())
+    }
+    if (len(resp.Kvs) == 0)
+    {
+        return nil, status.Error(codes.NotFound, "volume "+volName+" does not exist")
+    }
+    var inodeCfg InodeConfig
+    err = json.Unmarshal(resp.Kvs[0].Value, &inodeCfg)
+    if (err != nil)
+    {
+        return nil, status.Error(codes.Internal, "invalid "+inodeCfgKey+" key in etcd: "+err.Error())
+    }
+
+    // Delete inode data by invoking vitastor-cli
+    args := []string{
+        "rm-data", "--etcd_address", strings.Join(etcdUrl, ","),
+        "--pool", fmt.Sprintf("%d", idx.PoolId),
+        "--inode", fmt.Sprintf("%d", idx.Id),
+    }
+    if (ctxVars["configPath"] != "")
+    {
+        args = append(args, "--config_path", ctxVars["configPath"])
+    }
+    c := exec.Command("/usr/bin/vitastor-cli", args...)
+    var stderr bytes.Buffer
+    c.Stdout = nil
+    c.Stderr = &stderr
+    err = c.Run()
+    stderrStr := string(stderr.Bytes())
+    if (err != nil)
+    {
+        klog.Errorf("vitastor-cli rm-data failed: %s, status %s\n", stderrStr, err)
+        return nil, status.Error(codes.Internal, stderrStr+" (status "+err.Error()+")")
+    }
+
+    // Delete inode config in etcd
+    ctx, cancel = context.WithTimeout(context.Background(), ETCD_TIMEOUT)
+    txnResp, err := cli.Txn(ctx).Then(
+        clientv3.OpDelete(fmt.Sprintf("%s/index/image/%s", etcdPrefix, volName)),
+        clientv3.OpDelete(fmt.Sprintf("%s/config/inode/%d/%d", etcdPrefix, idx.PoolId, idx.Id)),
+    ).Commit()
+    cancel()
+    if (err != nil)
+    {
+        return nil, status.Error(codes.Internal, "failed to delete keys in etcd: "+err.Error())
+    }
+    if (!txnResp.Succeeded)
+    {
+        return nil, status.Error(codes.Internal, "failed to delete keys in etcd: transaction failed")
     }
 
     return &csi.DeleteVolumeResponse{}, nil
@@ -289,44 +426,13 @@ func (cs *ControllerServer) ValidateVolumeCapabilities(ctx context.Context, req
         return nil, status.Error(codes.InvalidArgument, "volumeCapabilities is nil")
     }
 
-    err := cs.checkCaps(volumeCapabilities)
-    if (err != nil)
-    {
-        return nil, err
-    }
-
-    return &csi.ValidateVolumeCapabilitiesResponse{
-        Confirmed: &csi.ValidateVolumeCapabilitiesResponse_Confirmed{
-            VolumeCapabilities: req.VolumeCapabilities,
-        },
-    }, nil
-}
-
-func (cs *ControllerServer) checkCaps(volumeCapabilities []*csi.VolumeCapability) error
-{
     var volumeCapabilityAccessModes []*csi.VolumeCapability_AccessMode
     for _, mode := range []csi.VolumeCapability_AccessMode_Mode{
         csi.VolumeCapability_AccessMode_SINGLE_NODE_WRITER,
-        csi.VolumeCapability_AccessMode_SINGLE_NODE_READER_ONLY,
-        csi.VolumeCapability_AccessMode_MULTI_NODE_READER_ONLY,
-        csi.VolumeCapability_AccessMode_SINGLE_NODE_SINGLE_WRITER,
-        csi.VolumeCapability_AccessMode_SINGLE_NODE_MULTI_WRITER,
+        csi.VolumeCapability_AccessMode_MULTI_NODE_MULTI_WRITER,
     } {
         volumeCapabilityAccessModes = append(volumeCapabilityAccessModes, &csi.VolumeCapability_AccessMode{Mode: mode})
     }
-    for _, capability := range volumeCapabilities
-    {
-        if (capability.GetBlock() != nil)
-        {
-            for _, mode := range []csi.VolumeCapability_AccessMode_Mode{
-                csi.VolumeCapability_AccessMode_MULTI_NODE_SINGLE_WRITER,
-                csi.VolumeCapability_AccessMode_MULTI_NODE_MULTI_WRITER,
-            } {
-                volumeCapabilityAccessModes = append(volumeCapabilityAccessModes, &csi.VolumeCapability_AccessMode{Mode: mode})
-            }
-            break
-        }
-    }
 
     capabilitySupport := false
     for _, capability := range volumeCapabilities
@@ -342,10 +448,14 @@ func (cs *ControllerServer) checkCaps(volumeCapabilities []*csi.VolumeCapability
 
     if (!capabilitySupport)
     {
-        return status.Errorf(codes.NotFound, "%v not supported", volumeCapabilities)
+        return nil, status.Errorf(codes.NotFound, "%v not supported", req.GetVolumeCapabilities())
     }
 
-    return nil
+    return &csi.ValidateVolumeCapabilitiesResponse{
+        Confirmed: &csi.ValidateVolumeCapabilitiesResponse_Confirmed{
+            VolumeCapabilities: req.VolumeCapabilities,
+        },
+    }, nil
 }
 
 // ListVolumes returns a list of volumes
@@ -380,8 +490,6 @@ func (cs *ControllerServer) ControllerGetCapabilities(ctx context.Context, req *
         csi.ControllerServiceCapability_RPC_LIST_VOLUMES,
         csi.ControllerServiceCapability_RPC_EXPAND_VOLUME,
         csi.ControllerServiceCapability_RPC_CREATE_DELETE_SNAPSHOT,
-        csi.ControllerServiceCapability_RPC_LIST_SNAPSHOTS,
-        // TODO: csi.ControllerServiceCapability_RPC_CLONE_VOLUME,
     } {
         controllerServerCapabilities = append(controllerServerCapabilities, functionControllerServerCapabilities(capability))
     }
@@ -391,226 +499,28 @@ func (cs *ControllerServer) ControllerGetCapabilities(ctx context.Context, req *
     }, nil
 }
 
-func invokeList(ctxVars map[string]string, pattern string, expectExist bool) ([]InodeConfig, error)
-{
-    stat, err := invokeCLI(ctxVars, []string{ "ls", "--json", pattern })
-    if (err != nil)
-    {
-        return nil, err
-    }
-    var inodeCfg []InodeConfig
-    err = json.Unmarshal(stat, &inodeCfg)
-    if (err != nil)
-    {
-        return nil, status.Error(codes.Internal, "Invalid JSON in vitastor-cli ls: "+err.Error())
-    }
-    if (expectExist && len(inodeCfg) == 0)
-    {
-        return nil, status.Error(codes.Internal, "Can't find expected image "+pattern+" via vitastor-cli ls")
-    }
-    return inodeCfg, nil
-}
-
 // CreateSnapshot create snapshot of an existing PV
 func (cs *ControllerServer) CreateSnapshot(ctx context.Context, req *csi.CreateSnapshotRequest) (*csi.CreateSnapshotResponse, error)
 {
-    klog.Infof("received controller create snapshot request %+v", protosanitizer.StripSecrets(req))
-    if (req == nil)
-    {
-        return nil, status.Errorf(codes.InvalidArgument, "request cannot be empty")
-    }
-    if (req.SourceVolumeId == "" || req.Name == "")
-    {
-        return nil, status.Error(codes.InvalidArgument, "source volume ID and snapshot name are required fields")
-    }
-
-    // snapshot name
-    snapName := req.Name
-
-    // req.VolumeId is an ugly json string in our case :)
-    ctxVars := make(map[string]string)
-    err := json.Unmarshal([]byte(req.SourceVolumeId), &ctxVars)
-    if (err != nil)
-    {
-        return nil, status.Error(codes.Internal, "volume ID not in JSON format")
-    }
-    volName := ctxVars["name"]
-
-    // Create image using vitastor-cli
-    _, err = invokeCLI(ctxVars, []string{ "create", "--snapshot", snapName, volName })
-    if (err != nil && strings.Index(err.Error(), "already exists") <= 0)
-    {
-        return nil, err
-    }
-
-    // Check created snapshot
-    inodeCfg, err := invokeList(ctxVars, volName+"@"+snapName, true)
-    if (err != nil)
-    {
-        return nil, err
-    }
-
-    // Use ugly JSON snapshot ID again, DeleteSnapshot doesn't have context :-(
-    ctxVars["snapshot"] = snapName
-    snapIdJson, _ := json.Marshal(ctxVars)
-    return &csi.CreateSnapshotResponse{
-        Snapshot: &csi.Snapshot{
-            SizeBytes: int64(inodeCfg[0].Size),
-            SnapshotId: string(snapIdJson),
-            SourceVolumeId: req.SourceVolumeId,
-            CreationTime: &timestamppb.Timestamp{ Seconds: int64(inodeCfg[0].CreateTs) },
-            ReadyToUse: true,
-        },
-    }, nil
+    return nil, status.Error(codes.Unimplemented, "")
 }
 
 // DeleteSnapshot delete provided snapshot of a PV
 func (cs *ControllerServer) DeleteSnapshot(ctx context.Context, req *csi.DeleteSnapshotRequest) (*csi.DeleteSnapshotResponse, error)
 {
-    klog.Infof("received controller delete snapshot request %+v", protosanitizer.StripSecrets(req))
-    if (req == nil)
-    {
-        return nil, status.Errorf(codes.InvalidArgument, "request cannot be empty")
-    }
-    if (req.SnapshotId == "")
-    {
-        return nil, status.Error(codes.InvalidArgument, "snapshot ID is a required field")
-    }
-
-    volVars := make(map[string]string)
-    err := json.Unmarshal([]byte(req.SnapshotId), &volVars)
-    if (err != nil)
-    {
-        return nil, status.Error(codes.Internal, "snapshot ID not in JSON format")
-    }
-    volName := volVars["name"]
-    snapName := volVars["snapshot"]
-
-    ctxVars, err := GetConnectionParams(volVars)
-    if (err != nil)
-    {
-        return nil, err
-    }
-
-    _, err = invokeCLI(ctxVars, []string{ "rm", volName+"@"+snapName })
-    if (err != nil)
-    {
-        return nil, err
-    }
-
-    return &csi.DeleteSnapshotResponse{}, nil
+    return nil, status.Error(codes.Unimplemented, "")
 }
 
 // ListSnapshots list the snapshots of a PV
 func (cs *ControllerServer) ListSnapshots(ctx context.Context, req *csi.ListSnapshotsRequest) (*csi.ListSnapshotsResponse, error)
 {
-    klog.Infof("received controller list snapshots request %+v", protosanitizer.StripSecrets(req))
-    if (req == nil)
-    {
-        return nil, status.Error(codes.InvalidArgument, "request cannot be empty")
-    }
-
-    volVars := make(map[string]string)
-    err := json.Unmarshal([]byte(req.SourceVolumeId), &volVars)
-    if (err != nil)
-    {
-        return nil, status.Error(codes.Internal, "volume ID not in JSON format")
-    }
-    volName := volVars["name"]
-    ctxVars, err := GetConnectionParams(volVars)
-    if (err != nil)
-    {
-        return nil, err
-    }
-
-    inodeCfg, err := invokeList(ctxVars, volName+"@*", false)
-    if (err != nil)
-    {
-        return nil, err
-    }
-
-    resp := &csi.ListSnapshotsResponse{}
-    for _, ino := range inodeCfg
-    {
-        snapName := ino.Name[len(volName)+1:]
-        if (len(req.StartingToken) > 0 && snapName < req.StartingToken)
-        {
-        }
-        else if (req.MaxEntries == 0 || len(resp.Entries) < int(req.MaxEntries))
-        {
-            volVars["snapshot"] = snapName
-            snapIdJson, _ := json.Marshal(volVars)
-            resp.Entries = append(resp.Entries, &csi.ListSnapshotsResponse_Entry{
-                Snapshot: &csi.Snapshot{
-                    SizeBytes: int64(ino.Size),
-                    SnapshotId: string(snapIdJson),
-                    SourceVolumeId: req.SourceVolumeId,
-                    CreationTime: &timestamppb.Timestamp{ Seconds: int64(ino.CreateTs) },
-                    ReadyToUse: true,
-                },
-            })
-        }
-        else
-        {
-            resp.NextToken = snapName
-            break
-        }
-    }
-
-    return resp, nil
+    return nil, status.Error(codes.Unimplemented, "")
 }
 
-// ControllerExpandVolume increases the size of a volume
+// ControllerExpandVolume resizes a volume
 func (cs *ControllerServer) ControllerExpandVolume(ctx context.Context, req *csi.ControllerExpandVolumeRequest) (*csi.ControllerExpandVolumeResponse, error)
 {
-    klog.Infof("received controller expand volume request %+v", protosanitizer.StripSecrets(req))
-    if (req == nil)
-    {
-        return nil, status.Error(codes.InvalidArgument, "request cannot be empty")
-    }
-    if (req.VolumeId == "" || req.CapacityRange == nil || req.CapacityRange.RequiredBytes == 0)
-    {
-        return nil, status.Error(codes.InvalidArgument, "VolumeId, CapacityRange and RequiredBytes are required fields")
-    }
-
-    volVars := make(map[string]string)
-    err := json.Unmarshal([]byte(req.VolumeId), &volVars)
-    if (err != nil)
-    {
-        return nil, status.Error(codes.Internal, "volume ID not in JSON format")
-    }
-    volName := volVars["name"]
-    ctxVars, err := GetConnectionParams(volVars)
-    if (err != nil)
-    {
-        return nil, err
-    }
-
-    inodeCfg, err := invokeList(ctxVars, volName, true)
-    if (err != nil)
-    {
-        return nil, err
-    }
-
-    if (req.CapacityRange.RequiredBytes > 0 && inodeCfg[0].Size < uint64(req.CapacityRange.RequiredBytes))
-    {
-        sz := ((req.CapacityRange.RequiredBytes+4095)/4096)*4096
-        _, err := invokeCLI(ctxVars, []string{ "modify", "--inc_size", "1", "--resize", fmt.Sprintf("%d", sz), volName })
-        if (err != nil)
-        {
-            return nil, err
-        }
-        inodeCfg, err = invokeList(ctxVars, volName, true)
-        if (err != nil)
-        {
-            return nil, err
-        }
-    }
-
-    return &csi.ControllerExpandVolumeResponse{
-        CapacityBytes: int64(inodeCfg[0].Size),
-        NodeExpansionRequired: false,
-    }, nil
+    return nil, status.Error(codes.Unimplemented, "")
 }
 
 // ControllerGetVolume get volume info

csi/src/identityserver.go

@@ -49,13 +49,6 @@ func (is *IdentityServer) GetPluginCapabilities(ctx context.Context, req *csi.Ge
                     },
                 },
             },
-            {
-                Type: &csi.PluginCapability_VolumeExpansion_{
-                    VolumeExpansion: &csi.PluginCapability_VolumeExpansion{
-                        Type: csi.PluginCapability_VolumeExpansion_OFFLINE,
-                    },
-                },
-            },
         },
     }, nil
 }

csi/src/nodeserver.go

@@ -5,15 +5,11 @@ package vitastor
 
 import (
     "context"
-    "encoding/json"
-    "fmt"
     "os"
     "os/exec"
-    "path/filepath"
+    "encoding/json"
     "strings"
-    "sync"
-    "syscall"
-    "time"
+    "bytes"
 
     "google.golang.org/grpc/codes"
     "google.golang.org/grpc/status"
@@ -29,533 +25,193 @@ import (
 type NodeServer struct
 {
     *Driver
-    useVduse bool
-    stateDir string
     mounter mount.Interface
-    restartInterval time.Duration
-    mu sync.Mutex
-    cond *sync.Cond
-    volumeLocks map[string]bool
-}
-
-type DeviceState struct
-{
-    ConfigPath string `json:"configPath"`
-    VdpaId     string `json:"vdpaId"`
-    Image      string `json:"image"`
-    Blockdev   string `json:"blockdev"`
-    Readonly   bool   `json:"readonly"`
-    PidFile    string `json:"pidFile"`
 }
 
 // NewNodeServer create new instance node
 func NewNodeServer(driver *Driver) *NodeServer
 {
-    stateDir := os.Getenv("STATE_DIR")
-    if (stateDir == "")
-    {
-        stateDir = "/run/vitastor-csi"
-    }
-    if (stateDir[len(stateDir)-1] != '/')
-    {
-        stateDir += "/"
-    }
-    ns := &NodeServer{
+    return &NodeServer{
         Driver: driver,
-        useVduse: checkVduseSupport(),
-        stateDir: stateDir,
         mounter: mount.New(""),
-        volumeLocks: make(map[string]bool),
-    }
-    ns.cond = sync.NewCond(&ns.mu)
-    if (ns.useVduse)
-    {
-        ns.restoreVduseDaemons()
-        dur, err := time.ParseDuration(os.Getenv("RESTART_INTERVAL"))
-        if (err != nil)
-        {
-            dur = 10 * time.Second
-        }
-        ns.restartInterval = dur
-        if (ns.restartInterval != time.Duration(0))
-        {
-            go ns.restarter()
-        }
-    }
-    return ns
-}
-
-func (ns *NodeServer) lockVolume(lockId string)
-{
-    ns.mu.Lock()
-    defer ns.mu.Unlock()
-    for (ns.volumeLocks[lockId])
-    {
-        ns.cond.Wait()
-    }
-    ns.volumeLocks[lockId] = true
-    ns.cond.Broadcast()
-}
-
-func (ns *NodeServer) unlockVolume(lockId string)
-{
-    ns.mu.Lock()
-    defer ns.mu.Unlock()
-    delete(ns.volumeLocks, lockId)
-    ns.cond.Broadcast()
-}
-
-func (ns *NodeServer) restarter()
-{
-    // Restart dead VDUSE daemons at regular intervals
-    // Otherwise volume I/O may hang in case of a qemu-storage-daemon crash
-    // Moreover, it may lead to a kernel panic of the kernel is configured to
-    // panic on hung tasks
-    ticker := time.NewTicker(ns.restartInterval)
-    defer ticker.Stop()
-    for
-    {
-        <-ticker.C
-        ns.restoreVduseDaemons()
-    }
-}
-
-func (ns *NodeServer) restoreVduseDaemons()
-{
-    pattern := ns.stateDir+"vitastor-vduse-*.json"
-    matches, err := filepath.Glob(pattern)
-    if (err != nil)
-    {
-        klog.Errorf("failed to list %s: %v", pattern, err)
-    }
-    if (len(matches) == 0)
-    {
-        return
-    }
-    devList := make(map[string]interface{})
-    // example output: {"dev":{"test1":{"type":"block","mgmtdev":"vduse","vendor_id":0,"max_vqs":16,"max_vq_size":128}}}
-    devListJSON, _, err := system("/sbin/vdpa", "-j", "dev", "list")
-    if (err != nil)
-    {
-        return
-    }
-    err = json.Unmarshal(devListJSON, &devList)
-    devs, ok := devList["dev"].(map[string]interface{})
-    if (err != nil || !ok)
-    {
-        klog.Errorf("/sbin/vdpa -j dev list returned bad JSON (error %v): %v", err, string(devListJSON))
-        return
-    }
-    for _, stateFile := range matches
-    {
-        vdpaId := filepath.Base(stateFile)
-        vdpaId = vdpaId[0:len(vdpaId)-5]
-        // Check if VDPA device is still added to the bus
-        if (devs[vdpaId] == nil)
-        {
-            // Unused, clean it up
-            unmapVduseById(ns.stateDir, vdpaId)
-            continue
-        }
-
-        stateJSON, err := os.ReadFile(stateFile)
-        if (err != nil)
-        {
-            klog.Warningf("error reading state file %v: %v", stateFile, err)
-            continue
-        }
-        var state DeviceState
-        err = json.Unmarshal(stateJSON, &state)
-        if (err != nil)
-        {
-            klog.Warningf("state file %v contains invalid JSON (error %v): %v", stateFile, err, string(stateJSON))
-            continue
-        }
-
-        ns.lockVolume(state.ConfigPath+":"+state.Image)
-
-        // Recheck state file after locking
-        _, err = os.ReadFile(stateFile)
-        if (err != nil)
-        {
-            klog.Warningf("state file %v disappeared, skipping volume", stateFile)
-            ns.unlockVolume(state.ConfigPath+":"+state.Image)
-            continue
-        }
-
-        // Check if the storage daemon is still active
-        pidFile := ns.stateDir + vdpaId + ".pid"
-        exists := false
-        proc, err := findByPidFile(pidFile)
-        if (err == nil)
-        {
-            exists = proc.Signal(syscall.Signal(0)) == nil
-        }
-        if (!exists)
-        {
-            // Restart daemon
-            klog.Warningf("restarting storage daemon for volume %v (VDPA ID %v)", state.Image, vdpaId)
-            _ = startStorageDaemon(vdpaId, state.Image, pidFile, state.ConfigPath, state.Readonly)
-        }
-
-        ns.unlockVolume(state.ConfigPath+":"+state.Image)
     }
 }
 
 // NodeStageVolume mounts the volume to a staging path on the node.
 func (ns *NodeServer) NodeStageVolume(ctx context.Context, req *csi.NodeStageVolumeRequest) (*csi.NodeStageVolumeResponse, error)
 {
-    klog.Infof("received node stage volume request %+v", protosanitizer.StripSecrets(req))
-
-    ctxVars := make(map[string]string)
-    err := json.Unmarshal([]byte(req.VolumeId), &ctxVars)
-    if (err != nil)
-    {
-        return nil, status.Error(codes.Internal, "volume ID not in JSON format")
-    }
-    _, err = GetConnectionParams(ctxVars)
-    if (err != nil)
-    {
-        return nil, err
-    }
-    volName := ctxVars["name"]
-
-    ns.lockVolume(ctxVars["configPath"]+":"+volName)
-    defer ns.unlockVolume(ctxVars["configPath"]+":"+volName)
-
-    targetPath := req.GetStagingTargetPath()
-    isBlock := req.GetVolumeCapability().GetBlock() != nil
-
-    // Check that it's not already mounted
-    notmnt, err := mount.IsNotMountPoint(ns.mounter, targetPath)
-    if (err == nil)
-    {
-        if (!notmnt)
-        {
-            klog.Errorf("target path %s is already mounted", targetPath)
-            return nil, fmt.Errorf("target path %s is already mounted", targetPath)
-        }
-        var finfo os.FileInfo
-        finfo, err = os.Stat(targetPath)
-        if (err != nil)
-        {
-            klog.Errorf("failed to stat %s: %v", targetPath, err)
-            return nil, err
-        }
-        if (finfo.IsDir() != (!isBlock))
-        {
-            err = os.Remove(targetPath)
-            if (err != nil)
-            {
-                klog.Errorf("failed to remove %s (to recreate it with correct type): %v", targetPath, err)
-                return nil, err
-            }
-            err = os.ErrNotExist
-        }
-    }
-    if (err != nil)
-    {
-        if (os.IsNotExist(err))
-        {
-            if (isBlock)
-            {
-                pathFile, err := os.OpenFile(targetPath, os.O_CREATE|os.O_RDWR, 0o600)
-                if (err != nil)
-                {
-                    klog.Errorf("failed to create block device mount target %s with error: %v", targetPath, err)
-                    return nil, err
-                }
-                err = pathFile.Close()
-                if (err != nil)
-                {
-                    klog.Errorf("failed to close %s with error: %v", targetPath, err)
-                    return nil, err
-                }
-            }
-            else
-            {
-                err := os.MkdirAll(targetPath, 0777)
-                if (err != nil)
-                {
-                    klog.Errorf("failed to create fs mount target %s with error: %v", targetPath, err)
-                    return nil, err
-                }
-            }
-        }
-        else
-        {
-            return nil, err
-        }
-    }
-
-    var devicePath, vdpaId string
-    if (!ns.useVduse)
-    {
-        devicePath, err = mapNbd(volName, ctxVars, false)
-    }
-    else
-    {
-        devicePath, vdpaId, err = mapVduse(ns.stateDir, volName, ctxVars, false)
-    }
-    if (err != nil)
-    {
-        return nil, err
-    }
-
-    diskMounter := &mount.SafeFormatAndMount{Interface: ns.mounter, Exec: utilexec.New()}
-    if (isBlock)
-    {
-        klog.Infof("bind-mounting %s to %s", devicePath, targetPath)
-        err = diskMounter.Mount(devicePath, targetPath, "", []string{"bind"})
-    }
-    else
-    {
-        // Check existing format
-        existingFormat, err := diskMounter.GetDiskFormat(devicePath)
-        if (err != nil)
-        {
-            klog.Errorf("failed to get disk format for path %s, error: %v", err)
-            goto unmap
-        }
-
-        // Format the device (ext4 or xfs)
-        fsType := req.GetVolumeCapability().GetMount().GetFsType()
-        opt := req.GetVolumeCapability().GetMount().GetMountFlags()
-        opt = append(opt, "_netdev")
-        if ((req.VolumeCapability.AccessMode.Mode == csi.VolumeCapability_AccessMode_MULTI_NODE_READER_ONLY ||
-            req.VolumeCapability.AccessMode.Mode == csi.VolumeCapability_AccessMode_SINGLE_NODE_READER_ONLY) &&
-            !Contains(opt, "ro"))
-        {
-            opt = append(opt, "ro")
-        }
-        if (fsType == "xfs")
-        {
-            opt = append(opt, "nouuid")
-        }
-        readOnly := Contains(opt, "ro")
-        if (existingFormat == "" && !readOnly)
-        {
-            switch fsType
-            {
-                case "ext4":
-                    args := []string{"-m0", "-Enodiscard,lazy_itable_init=1,lazy_journal_init=1", devicePath}
-                    _, err = systemCombined("mkfs.ext4", args...)
-                case "xfs":
-                    _, err = systemCombined("mkfs.xfs", "-K", devicePath)
-            }
-            if (err != nil)
-            {
-                goto unmap
-            }
-        }
-
-        klog.Infof("formatting and mounting %s to %s with FS %s, options: %v", devicePath, targetPath, fsType, opt)
-        err = diskMounter.FormatAndMount(devicePath, targetPath, fsType, opt)
-        if (err == nil)
-        {
-            klog.Infof("successfully mounted %s to %s", devicePath, targetPath)
-        }
-
-        // Try to run online resize on mount.
-        // FIXME: Implement online resize. It requires online resize support in vitastor-nbd.
-        if (err == nil && existingFormat != "" && !readOnly)
-        {
-            switch (fsType)
-            {
-                case "ext4":
-                    _, err = systemCombined("resize2fs", devicePath)
-                case "xfs":
-                    _, err = systemCombined("xfs_growfs", devicePath)
-            }
-            if (err != nil)
-            {
-                goto unmap
-            }
-        }
-    }
-    if (err != nil)
-    {
-        klog.Errorf(
-            "failed to mount device path (%s) to path (%s) for volume (%s) error: %s",
-            devicePath, targetPath, volName, err,
-        )
-        goto unmap
-    }
     return &csi.NodeStageVolumeResponse{}, nil
-
-unmap:
-    if (!ns.useVduse || len(devicePath) >= 8 && devicePath[0:8] == "/dev/nbd")
-    {
-        unmapNbd(devicePath)
-    }
-    else
-    {
-        unmapVduseById(ns.stateDir, vdpaId)
-    }
-    return nil, err
 }
 
 // NodeUnstageVolume unstages the volume from the staging path
 func (ns *NodeServer) NodeUnstageVolume(ctx context.Context, req *csi.NodeUnstageVolumeRequest) (*csi.NodeUnstageVolumeResponse, error)
 {
-    klog.Infof("received node unstage volume request %+v", protosanitizer.StripSecrets(req))
-
-    ctxVars := make(map[string]string)
-    err := json.Unmarshal([]byte(req.VolumeId), &ctxVars)
-    if (err != nil)
-    {
-        return nil, status.Error(codes.Internal, "volume ID not in JSON format")
-    }
-    volName := ctxVars["name"]
-
-    ns.lockVolume(ctxVars["configPath"]+":"+volName)
-    defer ns.unlockVolume(ctxVars["configPath"]+":"+volName)
-
-    targetPath := req.GetStagingTargetPath()
-    devicePath, _, err := mount.GetDeviceNameFromMount(ns.mounter, targetPath)
-    if (err != nil)
-    {
-        if (os.IsNotExist(err))
-        {
-            return nil, status.Error(codes.NotFound, "Target path not found")
-        }
-        return nil, err
-    }
-    if (devicePath == "")
-    {
-        // volume not mounted
-        klog.Warningf("%s is not a mountpoint, deleting", targetPath)
-        os.Remove(targetPath)
-        return &csi.NodeUnstageVolumeResponse{}, nil
-    }
-
-    refList, err := ns.mounter.GetMountRefs(targetPath)
-    if (err != nil)
-    {
-        return nil, err
-    }
-    if (len(refList) > 0)
-    {
-        klog.Warningf("%s is still referenced: %v", targetPath, refList)
-    }
-
-    // unmount
-    err = mount.CleanupMountPoint(targetPath, ns.mounter, false)
-    if (err != nil)
-    {
-        return nil, err
-    }
-
-    // unmap device
-    if (len(refList) == 0)
-    {
-        if (!ns.useVduse)
-        {
-            unmapNbd(devicePath)
-        }
-        else
-        {
-            unmapVduse(ns.stateDir, devicePath)
-        }
-    }
-
     return &csi.NodeUnstageVolumeResponse{}, nil
 }
 
+func Contains(list []string, s string) bool
+{
+    for i := 0; i < len(list); i++
+    {
+        if (list[i] == s)
+        {
+            return true
+        }
+    }
+    return false
+}
+
 // NodePublishVolume mounts the volume mounted to the staging path to the target path
 func (ns *NodeServer) NodePublishVolume(ctx context.Context, req *csi.NodePublishVolumeRequest) (*csi.NodePublishVolumeResponse, error)
 {
     klog.Infof("received node publish volume request %+v", protosanitizer.StripSecrets(req))
 
+    targetPath := req.GetTargetPath()
+
+    // Check that it's not already mounted
+    free, error := mount.IsNotMountPoint(ns.mounter, targetPath)
+    if (error != nil)
+    {
+        if (os.IsNotExist(error))
+        {
+            error := os.MkdirAll(targetPath, 0777)
+            if (error != nil)
+            {
+                return nil, status.Error(codes.Internal, error.Error())
+            }
+            free = true
+        }
+        else
+        {
+            return nil, status.Error(codes.Internal, error.Error())
+        }
+    }
+    if (!free)
+    {
+        return &csi.NodePublishVolumeResponse{}, nil
+    }
+
     ctxVars := make(map[string]string)
     err := json.Unmarshal([]byte(req.VolumeId), &ctxVars)
     if (err != nil)
     {
         return nil, status.Error(codes.Internal, "volume ID not in JSON format")
     }
-    _, err = GetConnectionParams(ctxVars)
-    if (err != nil)
-    {
-        return nil, err
-    }
     volName := ctxVars["name"]
 
-    ns.lockVolume(ctxVars["configPath"]+":"+volName)
-    defer ns.unlockVolume(ctxVars["configPath"]+":"+volName)
-
-    stagingTargetPath := req.GetStagingTargetPath()
-    targetPath := req.GetTargetPath()
-    isBlock := req.GetVolumeCapability().GetBlock() != nil
-
-    // Check that stagingTargetPath is mounted
-    notmnt, err := mount.IsNotMountPoint(ns.mounter, stagingTargetPath)
-    if (err != nil)
+    _, etcdUrl, etcdPrefix := GetConnectionParams(ctxVars)
+    if (len(etcdUrl) == 0)
     {
-        klog.Errorf("staging path %v is not mounted: %w", stagingTargetPath, err)
-        return nil, fmt.Errorf("staging path %v is not mounted: %w", stagingTargetPath, err)
-    }
-    else if (notmnt)
-    {
-        klog.Errorf("staging path %v is not mounted", stagingTargetPath)
-        return nil, fmt.Errorf("staging path %v is not mounted", stagingTargetPath)
+        return nil, status.Error(codes.InvalidArgument, "no etcdUrl in storage class configuration and no etcd_address in vitastor.conf")
     }
 
-    // Check that targetPath is not already mounted
-    notmnt, err = mount.IsNotMountPoint(ns.mounter, targetPath)
-    if (err != nil)
+    // Map NBD device
+    // FIXME: Check if already mapped
+    args := []string{
+        "map", "--etcd_address", strings.Join(etcdUrl, ","),
+        "--etcd_prefix", etcdPrefix,
+        "--image", volName,
+    };
+    if (ctxVars["configPath"] != "")
     {
-        if (os.IsNotExist(err))
-        {
-            if (isBlock)
-            {
-                pathFile, err := os.OpenFile(targetPath, os.O_CREATE|os.O_RDWR, 0o600)
-                if (err != nil)
-                {
-                    klog.Errorf("failed to create block device mount target %s with error: %v", targetPath, err)
-                    return nil, err
-                }
-                err = pathFile.Close()
-                if (err != nil)
-                {
-                    klog.Errorf("failed to close %s with error: %v", targetPath, err)
-                    return nil, err
-                }
-            }
-            else
-            {
-                err := os.MkdirAll(targetPath, 0777)
-                if (err != nil)
-                {
-                    klog.Errorf("failed to create fs mount target %s with error: %v", targetPath, err)
-                    return nil, err
-                }
-            }
-        }
-        else
-        {
-            return nil, err
-        }
+        args = append(args, "--config_path", ctxVars["configPath"])
     }
-    else if (!notmnt)
-    {
-        klog.Errorf("target path %s is already mounted", targetPath)
-        return nil, fmt.Errorf("target path %s is already mounted", targetPath)
-    }
-
-    execArgs := []string{"--bind", stagingTargetPath, targetPath}
     if (req.GetReadonly())
     {
-        execArgs = append(execArgs, "-o", "ro")
+        args = append(args, "--readonly", "1")
     }
-    cmd := exec.Command("mount", execArgs...)
-    cmd.Stderr = os.Stderr
-    klog.Infof("binding volume %v (%v) from %v to %v", volName, ctxVars["configPath"], stagingTargetPath, targetPath)
-    out, err := cmd.Output()
+    c := exec.Command("/usr/bin/vitastor-nbd", args...)
+    var stdout, stderr bytes.Buffer
+    c.Stdout, c.Stderr = &stdout, &stderr
+    err = c.Run()
+    stdoutStr, stderrStr := string(stdout.Bytes()), string(stderr.Bytes())
     if (err != nil)
     {
-        return nil, fmt.Errorf("Error running mount %v: %s", strings.Join(execArgs, " "), out)
+        klog.Errorf("vitastor-nbd map failed: %s, status %s\n", stdoutStr+stderrStr, err)
+        return nil, status.Error(codes.Internal, stdoutStr+stderrStr+" (status "+err.Error()+")")
+    }
+    devicePath := strings.TrimSpace(stdoutStr)
+
+    // Check existing format
+    diskMounter := &mount.SafeFormatAndMount{Interface: ns.mounter, Exec: utilexec.New()}
+    existingFormat, err := diskMounter.GetDiskFormat(devicePath)
+    if (err != nil)
+    {
+        klog.Errorf("failed to get disk format for path %s, error: %v", err)
+        // unmap NBD device
+        unmapOut, unmapErr := exec.Command("/usr/bin/vitastor-nbd", "unmap", devicePath).CombinedOutput()
+        if (unmapErr != nil)
+        {
+            klog.Errorf("failed to unmap NBD device %s: %s, error: %v", devicePath, unmapOut, unmapErr)
+        }
+        return nil, err
     }
 
+    // Format the device (ext4 or xfs)
+    fsType := req.GetVolumeCapability().GetMount().GetFsType()
+    isBlock := req.GetVolumeCapability().GetBlock() != nil
+    opt := req.GetVolumeCapability().GetMount().GetMountFlags()
+    opt = append(opt, "_netdev")
+    if ((req.VolumeCapability.AccessMode.Mode == csi.VolumeCapability_AccessMode_MULTI_NODE_READER_ONLY ||
+        req.VolumeCapability.AccessMode.Mode == csi.VolumeCapability_AccessMode_SINGLE_NODE_READER_ONLY) &&
+        !Contains(opt, "ro"))
+    {
+        opt = append(opt, "ro")
+    }
+    if (fsType == "xfs")
+    {
+        opt = append(opt, "nouuid")
+    }
+    readOnly := Contains(opt, "ro")
+    if (existingFormat == "" && !readOnly)
+    {
+        args := []string{}
+        switch fsType
+        {
+            case "ext4":
+                args = []string{"-m0", "-Enodiscard,lazy_itable_init=1,lazy_journal_init=1", devicePath}
+            case "xfs":
+                args = []string{"-K", devicePath}
+        }
+        if (len(args) > 0)
+        {
+            cmdOut, cmdErr := diskMounter.Exec.Command("mkfs."+fsType, args...).CombinedOutput()
+            if (cmdErr != nil)
+            {
+                klog.Errorf("failed to run mkfs error: %v, output: %v", cmdErr, string(cmdOut))
+                // unmap NBD device
+                unmapOut, unmapErr := exec.Command("/usr/bin/vitastor-nbd", "unmap", devicePath).CombinedOutput()
+                if (unmapErr != nil)
+                {
+                    klog.Errorf("failed to unmap NBD device %s: %s, error: %v", devicePath, unmapOut, unmapErr)
+                }
+                return nil, status.Error(codes.Internal, cmdErr.Error())
+            }
+        }
+    }
+    if (isBlock)
+    {
+        opt = append(opt, "bind")
+        err = diskMounter.Mount(devicePath, targetPath, fsType, opt)
+    }
+    else
+    {
+        err = diskMounter.FormatAndMount(devicePath, targetPath, fsType, opt)
+    }
+    if (err != nil)
+    {
+        klog.Errorf(
+            "failed to mount device path (%s) to path (%s) for volume (%s) error: %s",
+            devicePath, targetPath, volName, err,
+        )
+        // unmap NBD device
+        unmapOut, unmapErr := exec.Command("/usr/bin/vitastor-nbd", "unmap", devicePath).CombinedOutput()
+        if (unmapErr != nil)
+        {
+            klog.Errorf("failed to unmap NBD device %s: %s, error: %v", devicePath, unmapOut, unmapErr)
+        }
+        return nil, status.Error(codes.Internal, err.Error())
+    }
     return &csi.NodePublishVolumeResponse{}, nil
 }
 
@@ -563,43 +219,35 @@ func (ns *NodeServer) NodePublishVolume(ctx context.Context, req *csi.NodePublis
 func (ns *NodeServer) NodeUnpublishVolume(ctx context.Context, req *csi.NodeUnpublishVolumeRequest) (*csi.NodeUnpublishVolumeResponse, error)
 {
     klog.Infof("received node unpublish volume request %+v", protosanitizer.StripSecrets(req))
-
-    ctxVars := make(map[string]string)
-    err := json.Unmarshal([]byte(req.VolumeId), &ctxVars)
-    if (err != nil)
-    {
-        return nil, status.Error(codes.Internal, "volume ID not in JSON format")
-    }
-    volName := ctxVars["name"]
-
-    ns.lockVolume(ctxVars["configPath"]+":"+volName)
-    defer ns.unlockVolume(ctxVars["configPath"]+":"+volName)
-
     targetPath := req.GetTargetPath()
-    devicePath, _, err := mount.GetDeviceNameFromMount(ns.mounter, targetPath)
+    devicePath, refCount, err := mount.GetDeviceNameFromMount(ns.mounter, targetPath)
     if (err != nil)
     {
         if (os.IsNotExist(err))
         {
             return nil, status.Error(codes.NotFound, "Target path not found")
         }
-        return nil, err
+        return nil, status.Error(codes.Internal, err.Error())
     }
     if (devicePath == "")
     {
-        // volume not mounted
-        klog.Warningf("%s is not a mountpoint, deleting", targetPath)
-        os.Remove(targetPath)
-        return &csi.NodeUnpublishVolumeResponse{}, nil
+        return nil, status.Error(codes.NotFound, "Volume not mounted")
     }
-
     // unmount
     err = mount.CleanupMountPoint(targetPath, ns.mounter, false)
     if (err != nil)
     {
-        return nil, err
+        return nil, status.Error(codes.Internal, err.Error())
+    }
+    // unmap NBD device
+    if (refCount == 1)
+    {
+        unmapOut, unmapErr := exec.Command("/usr/bin/vitastor-nbd", "unmap", devicePath).CombinedOutput()
+        if (unmapErr != nil)
+        {
+            klog.Errorf("failed to unmap NBD device %s: %s, error: %v", devicePath, unmapOut, unmapErr)
+        }
     }
-
     return &csi.NodeUnpublishVolumeResponse{}, nil
 }
 
@@ -618,17 +266,7 @@ func (ns *NodeServer) NodeExpandVolume(ctx context.Context, req *csi.NodeExpandV
 // NodeGetCapabilities returns the supported capabilities of the node server
 func (ns *NodeServer) NodeGetCapabilities(ctx context.Context, req *csi.NodeGetCapabilitiesRequest) (*csi.NodeGetCapabilitiesResponse, error)
 {
-    return &csi.NodeGetCapabilitiesResponse{
-        Capabilities: []*csi.NodeServiceCapability{
-            &csi.NodeServiceCapability{
-                Type: &csi.NodeServiceCapability_Rpc{
-                    Rpc: &csi.NodeServiceCapability_RPC{
-                        Type: csi.NodeServiceCapability_RPC_STAGE_UNSTAGE_VOLUME,
-                    },
-                },
-            },
-        },
-    }, nil
+    return &csi.NodeGetCapabilitiesResponse{}, nil
 }
 
 // NodeGetInfo returns NodeGetInfoResponse for CO.

csi/src/utils.go

@@ -1,342 +0,0 @@
-// Copyright (c) Vitaliy Filippov, 2019+
-// License: VNPL-1.1 or GNU GPL-2.0+ (see README.md for details)
-
-package vitastor
-
-import (
-    "bytes"
-    "errors"
-    "encoding/json"
-    "fmt"
-    "os"
-    "os/exec"
-    "path/filepath"
-    "strconv"
-    "strings"
-    "syscall"
-
-    "k8s.io/klog"
-    "google.golang.org/grpc/codes"
-    "google.golang.org/grpc/status"
-)
-
-func Contains(list []string, s string) bool
-{
-    for i := 0; i < len(list); i++
-    {
-        if (list[i] == s)
-        {
-            return true
-        }
-    }
-    return false
-}
-
-func checkVduseSupport() bool
-{
-    // Check VDUSE support (vdpa, vduse, virtio-vdpa kernel modules)
-    vduse := true
-    for _, mod := range []string{"vdpa", "vduse", "virtio-vdpa"}
-    {
-        _, err := os.Stat("/sys/module/"+mod)
-        if (err != nil)
-        {
-            if (!errors.Is(err, os.ErrNotExist))
-            {
-                klog.Errorf("failed to check /sys/module/%s: %v", mod, err)
-            }
-            c := exec.Command("/sbin/modprobe", mod)
-            c.Stdout = os.Stderr
-            c.Stderr = os.Stderr
-            err := c.Run()
-            if (err != nil)
-            {
-                klog.Errorf("/sbin/modprobe %s failed: %v", mod, err)
-                vduse = false
-                break
-            }
-        }
-    }
-    // Check that vdpa tool functions
-    if (vduse)
-    {
-        c := exec.Command("/sbin/vdpa", "-j", "dev")
-        c.Stderr = os.Stderr
-        err := c.Run()
-        if (err != nil)
-        {
-            klog.Errorf("/sbin/vdpa -j dev failed: %v", err)
-            vduse = false
-        }
-    }
-    if (!vduse)
-    {
-        klog.Errorf(
-            "Your host apparently has no VDUSE support. VDUSE support disabled, NBD will be used to map devices."+
-            " For VDUSE you need at least Linux 5.15 and the following kernel modules: vdpa, virtio-vdpa, vduse.",
-        )
-    }
-    else
-    {
-        klog.Infof("VDUSE support enabled successfully")
-    }
-    return vduse
-}
-
-func mapNbd(volName string, ctxVars map[string]string, readonly bool) (string, error)
-{
-    // Map NBD device
-    // FIXME: Check if already mapped
-    args := []string{
-        "map", "--image", volName,
-    }
-    if (ctxVars["configPath"] != "")
-    {
-        args = append(args, "--config_path", ctxVars["configPath"])
-    }
-    if (readonly)
-    {
-        args = append(args, "--readonly", "1")
-    }
-    stdout, stderr, err := system("/usr/bin/vitastor-nbd", args...)
-    dev := strings.TrimSpace(string(stdout))
-    if (dev == "")
-    {
-        return "", fmt.Errorf("vitastor-nbd did not return the name of NBD device. output: %s", stderr)
-    }
-    klog.Infof("Attached volume %s via NBD as %s", volName, dev)
-    return dev, err
-}
-
-func unmapNbd(devicePath string)
-{
-    // unmap NBD device
-    unmapOut, unmapErr := exec.Command("/usr/bin/vitastor-nbd", "unmap", devicePath).CombinedOutput()
-    if (unmapErr != nil)
-    {
-        klog.Errorf("failed to unmap NBD device %s: %s, error: %v", devicePath, unmapOut, unmapErr)
-    }
-}
-
-func findByPidFile(pidFile string) (*os.Process, error)
-{
-    pidBuf, err := os.ReadFile(pidFile)
-    if (err != nil)
-    {
-        return nil, err
-    }
-    pid, err := strconv.ParseInt(strings.TrimSpace(string(pidBuf)), 0, 64)
-    if (err != nil)
-    {
-        return nil, err
-    }
-    proc, err := os.FindProcess(int(pid))
-    if (err != nil)
-    {
-        return nil, err
-    }
-    return proc, nil
-}
-
-func killByPidFile(pidFile string) error
-{
-    klog.Infof("killing process with PID from file %s", pidFile)
-    proc, err := findByPidFile(pidFile)
-    if (err != nil)
-    {
-        return err
-    }
-    return proc.Signal(syscall.SIGTERM)
-}
-
-func startStorageDaemon(vdpaId, volName, pidFile, configPath string, readonly bool) error
-{
-    // Start qemu-storage-daemon
-    blockSpec := map[string]interface{}{
-        "node-name": "disk1",
-        "driver": "vitastor",
-        "image": volName,
-        "cache": map[string]bool{
-            "direct": true,
-            "no-flush": false,
-        },
-        "discard": "unmap",
-    }
-    if (configPath != "")
-    {
-        blockSpec["config-path"] = configPath
-    }
-    blockSpecJson, _ := json.Marshal(blockSpec)
-    writable := "true"
-    if (readonly)
-    {
-        writable = "false"
-    }
-    _, _, err := system(
-        "/usr/bin/qemu-storage-daemon", "--daemonize", "--pidfile", pidFile, "--blockdev", string(blockSpecJson),
-        "--export", "vduse-blk,id="+vdpaId+",node-name=disk1,name="+vdpaId+",num-queues=16,queue-size=128,writable="+writable,
-    )
-    return err
-}
-
-func mapVduse(stateDir string, volName string, ctxVars map[string]string, readonly bool) (string, string, error)
-{
-    // Generate state file
-    stateFd, err := os.CreateTemp(stateDir, "vitastor-vduse-*.json")
-    if (err != nil)
-    {
-        return "", "", err
-    }
-    stateFile := stateFd.Name()
-    stateFd.Close()
-    vdpaId := filepath.Base(stateFile)
-    vdpaId = vdpaId[0:len(vdpaId)-5] // remove ".json"
-    pidFile := stateDir + vdpaId + ".pid"
-    // Map VDUSE device via qemu-storage-daemon
-    err = startStorageDaemon(vdpaId, volName, pidFile, ctxVars["configPath"], readonly)
-    if (err == nil)
-    {
-        // Add device to VDPA bus
-        _, _, err = system("/sbin/vdpa", "-j", "dev", "add", "name", vdpaId, "mgmtdev", "vduse")
-        if (err == nil)
-        {
-            // Find block device name
-            var matches []string
-            matches, err = filepath.Glob("/sys/bus/vdpa/devices/"+vdpaId+"/virtio*/block/*")
-            if (err == nil && len(matches) == 0)
-            {
-                err = errors.New("/sys/bus/vdpa/devices/"+vdpaId+"/virtio*/block/* is not found")
-            }
-            if (err == nil)
-            {
-                blockdev := "/dev/"+filepath.Base(matches[0])
-                _, err = os.Stat(blockdev)
-                if (err == nil)
-                {
-                    // Generate state file
-                    stateJSON, _ := json.Marshal(&DeviceState{
-                        ConfigPath: ctxVars["configPath"],
-                        VdpaId:     vdpaId,
-                        Image:      volName,
-                        Blockdev:   blockdev,
-                        Readonly:   readonly,
-                        PidFile:    pidFile,
-                    })
-                    err = os.WriteFile(stateFile, stateJSON, 0600)
-                    if (err == nil)
-                    {
-                        klog.Infof("Attached volume %s via VDUSE as %s (VDPA ID %s)", volName, blockdev, vdpaId)
-                        return blockdev, vdpaId, nil
-                    }
-                }
-            }
-        }
-        killErr := killByPidFile(pidFile)
-        if (killErr != nil)
-        {
-            klog.Errorf("Failed to kill started qemu-storage-daemon: %v", killErr)
-        }
-        os.Remove(stateFile)
-        os.Remove(pidFile)
-    }
-    return "", "", err
-}
-
-func unmapVduse(stateDir, devicePath string)
-{
-    if (len(devicePath) < 6 || devicePath[0:6] != "/dev/v")
-    {
-        klog.Errorf("%s does not start with /dev/v", devicePath)
-        return
-    }
-    vduseDev, err := os.Readlink("/sys/block/"+devicePath[5:])
-    if (err != nil)
-    {
-        klog.Errorf("%s is not a symbolic link to VDUSE device (../devices/virtual/vduse/xxx): %v", devicePath, err)
-        return
-    }
-    vdpaId := ""
-    p := strings.Index(vduseDev, "/vduse/")
-    if (p >= 0)
-    {
-        vduseDev = vduseDev[p+7:]
-        p = strings.Index(vduseDev, "/")
-        if (p >= 0)
-        {
-            vdpaId = vduseDev[0:p]
-        }
-    }
-    if (vdpaId == "")
-    {
-        klog.Errorf("%s is not a symbolic link to VDUSE device (../devices/virtual/vduse/xxx), but is %v", devicePath, vduseDev)
-        return
-    }
-    unmapVduseById(stateDir, vdpaId)
-}
-
-func unmapVduseById(stateDir, vdpaId string)
-{
-    _, err := os.Stat("/sys/bus/vdpa/devices/"+vdpaId)
-    if (err != nil)
-    {
-        klog.Errorf("failed to stat /sys/bus/vdpa/devices/"+vdpaId+": %v", err)
-    }
-    else
-    {
-        _, _, _ = system("/sbin/vdpa", "-j", "dev", "del", vdpaId)
-    }
-    stateFile := stateDir + vdpaId + ".json"
-    os.Remove(stateFile)
-    pidFile := stateDir + vdpaId + ".pid"
-    _, err = os.Stat(pidFile)
-    if (os.IsNotExist(err))
-    {
-        // ok, already killed
-    }
-    else if (err != nil)
-    {
-        klog.Errorf("Failed to stat %v: %v", pidFile, err)
-        return
-    }
-    else
-    {
-        err = killByPidFile(pidFile)
-        if (err != nil)
-        {
-            klog.Errorf("Failed to kill started qemu-storage-daemon: %v", err)
-        }
-        os.Remove(pidFile)
-    }
-}
-
-func system(program string, args ...string) ([]byte, []byte, error)
-{
-    klog.Infof("Running "+program+" "+strings.Join(args, " "))
-    c := exec.Command(program, args...)
-    var stdout, stderr bytes.Buffer
-    c.Stdout, c.Stderr = &stdout, &stderr
-    err := c.Run()
-    if (err != nil)
-    {
-        stdoutStr, stderrStr := string(stdout.Bytes()), string(stderr.Bytes())
-        klog.Errorf(program+" "+strings.Join(args, " ")+" failed: %s\nOutput:\n%s", err, stdoutStr+stderrStr)
-        return nil, nil, status.Error(codes.Internal, stdoutStr+stderrStr+" (status "+err.Error()+")")
-    }
-    return stdout.Bytes(), stderr.Bytes(), nil
-}
-
-func systemCombined(program string, args ...string) ([]byte, error)
-{
-    klog.Infof("Running "+program+" "+strings.Join(args, " "))
-    c := exec.Command(program, args...)
-    var out bytes.Buffer
-    c.Stdout, c.Stderr = &out, &out
-    err := c.Run()
-    if (err != nil)
-    {
-        outStr := string(out.Bytes())
-        klog.Errorf(program+" "+strings.Join(args, " ")+" failed: %s, status %s\n", outStr, err)
-        return nil, status.Error(codes.Internal, outStr+" (status "+err.Error()+")")
-    }
-    return out.Bytes(), nil
-}

debian/build-pve-qemu.sh

@@ -1,58 +0,0 @@
-exit
-
-git clone https://git.yourcmc.ru/vitalif/pve-qemu .
-
-# bookworm
-
-docker run -it -v `pwd`/pve-qemu:/root/pve-qemu --name pve-qemu-bullseye debian:bullseye bash
-
-perl -i -pe 's/Types: deb$/Types: deb deb-src/' /etc/apt/sources.list.d/debian.sources
-echo 'deb [arch=amd64] http://download.proxmox.com/debian/pve bookworm pve-no-subscription' >> /etc/apt/sources.list
-echo 'deb https://vitastor.io/debian bookworm main' >> /etc/apt/sources.list
-echo 'APT::Install-Recommends false;' >> /etc/apt/apt.conf
-echo 'ru_RU UTF-8' >> /etc/locale.gen
-echo 'en_US UTF-8' >> /etc/locale.gen
-apt-get update
-apt-get install wget ca-certificates
-wget https://enterprise.proxmox.com/debian/proxmox-release-bookworm.gpg -O /etc/apt/trusted.gpg.d/proxmox-release-bookworm.gpg
-wget https://vitastor.io/debian/pubkey.gpg -O /etc/apt/trusted.gpg.d/vitastor.gpg
-apt-get update
-apt-get install git devscripts equivs wget mc libjemalloc-dev vitastor-client-dev lintian locales
-mk-build-deps --install ./control
-
-# bullseye
-
-docker run -it -v `pwd`/pve-qemu:/root/pve-qemu --name pve-qemu-bullseye debian:bullseye bash
-
-grep '^deb ' /etc/apt/sources.list | perl -pe 's/^deb /deb-src /' >> /etc/apt/sources.list
-echo 'deb [arch=amd64] http://download.proxmox.com/debian/pve bullseye pve-no-subscription' >> /etc/apt/sources.list
-echo 'deb https://vitastor.io/debian bullseye main' >> /etc/apt/sources.list
-echo 'APT::Install-Recommends false;' >> /etc/apt/apt.conf
-echo 'ru_RU UTF-8' >> /etc/locale.gen
-echo 'en_US UTF-8' >> /etc/locale.gen
-apt-get update
-apt-get install wget
-wget https://enterprise.proxmox.com/debian/proxmox-release-bullseye.gpg -O /etc/apt/trusted.gpg.d/proxmox-release-bullseye.gpg
-wget https://vitastor.io/debian/pubkey.gpg -O /etc/apt/trusted.gpg.d/vitastor.gpg
-apt-get update
-apt-get install git devscripts equivs wget mc libjemalloc-dev vitastor-client-dev lintian locales
-mk-build-deps --install ./control
-
-# buster
-
-docker run -it -v `pwd`/pve-qemu:/root/pve-qemu --name pve-qemu-buster debian:buster bash
-
-grep '^deb ' /etc/apt/sources.list | perl -pe 's/^deb /deb-src /' >> /etc/apt/sources.list
-echo 'deb [arch=amd64] http://download.proxmox.com/debian/pve buster pve-no-subscription' >> /etc/apt/sources.list
-echo 'deb https://vitastor.io/debian buster main' >> /etc/apt/sources.list
-echo 'deb http://deb.debian.org/debian buster-backports main' >> /etc/apt/sources.list
-echo 'APT::Install-Recommends false;' >> /etc/apt/apt.conf
-echo 'ru_RU UTF-8' >> /etc/locale.gen
-echo 'en_US UTF-8' >> /etc/locale.gen
-apt-get update
-apt-get install wget ca-certificates
-wget http://download.proxmox.com/debian/proxmox-ve-release-6.x.gpg -O /etc/apt/trusted.gpg.d/proxmox-ve-release-6.x.gpg
-wget https://vitastor.io/debian/pubkey.gpg -O /etc/apt/trusted.gpg.d/vitastor.gpg
-apt-get update
-apt-get install git devscripts equivs wget mc libjemalloc-dev vitastor-client-dev lintian locales
-mk-build-deps --install ./control

debian/build-vitastor-bookworm.sh

@@ -1,7 +0,0 @@
-#!/bin/bash
-
-cat < vitastor.Dockerfile > ../Dockerfile
-cd ..
-mkdir -p packages
-sudo podman build --build-arg DISTRO=debian --build-arg REL=bookworm -v `pwd`/packages:/root/packages -f Dockerfile .
-rm Dockerfile

debian/build-vitastor-bullseye.sh

@@ -3,5 +3,5 @@
 cat < vitastor.Dockerfile > ../Dockerfile
 cd ..
 mkdir -p packages
-sudo podman build --build-arg DISTRO=debian --build-arg REL=bullseye -v `pwd`/packages:/root/packages -f Dockerfile .
+sudo podman build --build-arg REL=bullseye -v `pwd`/packages:/root/packages -f Dockerfile .
 rm Dockerfile

debian/build-vitastor-buster.sh

@@ -3,5 +3,5 @@
 cat < vitastor.Dockerfile > ../Dockerfile
 cd ..
 mkdir -p packages
-sudo podman build --build-arg DISTRO=debian --build-arg REL=buster -v `pwd`/packages:/root/packages -f Dockerfile .
+sudo podman build --build-arg REL=buster -v `pwd`/packages:/root/packages -f Dockerfile .
 rm Dockerfile

debian/build-vitastor-ubuntu-jammy.sh

@@ -1,7 +0,0 @@
-#!/bin/bash
-
-cat < vitastor.Dockerfile > ../Dockerfile
-cd ..
-mkdir -p packages
-sudo podman build --build-arg DISTRO=ubuntu --build-arg REL=jammy -v `pwd`/packages:/root/packages -f Dockerfile .
-rm Dockerfile

debian/changelog

@@ -1,18 +1,4 @@
-vitastor (1.9.3-1) unstable; urgency=medium
-
-  * Bugfixes
-
- -- Vitaliy Filippov <vitalif@yourcmc.ru>  Fri, 03 Jun 2022 02:09:44 +0300
-
-vitastor (0.7.0-1) unstable; urgency=medium
-
-  * Implement NFS proxy
-  * Add documentation
-  * Bugfixes
-
- -- Vitaliy Filippov <vitalif@yourcmc.ru>  Sun, 29 May 2022 23:39:13 +0300
-
-vitastor (0.6.3-1) unstable; urgency=medium
+vitastor (0.6.10-1) unstable; urgency=medium
 
   * RDMA support
   * Bugfixes

debian/control

@@ -2,7 +2,7 @@ Source: vitastor
 Section: admin
 Priority: optional
 Maintainer: Vitaliy Filippov <vitalif@yourcmc.ru>
-Build-Depends: debhelper, liburing-dev (>= 0.6), g++ (>= 8), libstdc++6 (>= 8), linux-libc-dev, libgoogle-perftools-dev, libjerasure-dev, libgf-complete-dev, libibverbs-dev, libisal-dev, cmake, pkg-config, libnl-3-dev, libnl-genl-3-dev
+Build-Depends: debhelper, liburing-dev (>= 0.6), g++ (>= 8), libstdc++6 (>= 8), linux-libc-dev, libgoogle-perftools-dev, libjerasure-dev, libgf-complete-dev, libibverbs-dev
 Standards-Version: 4.5.0
 Homepage: https://vitastor.io/
 Rules-Requires-Root: no
@@ -18,7 +18,7 @@ Description: Vitastor, a fast software-defined clustered block storage
 
 Package: vitastor-osd
 Architecture: amd64
-Depends: ${shlibs:Depends}, ${misc:Depends}, vitastor-client (= ${binary:Version}), fdisk, util-linux, parted
+Depends: ${shlibs:Depends}, ${misc:Depends}, vitastor-client (= ${binary:Version})
 Description: Vitastor, a fast software-defined clustered block storage - object storage daemon
  Vitastor object storage daemon, i.e. server program that stores data.
 
@@ -53,9 +53,3 @@ Architecture: amd64
 Depends: ${shlibs:Depends}, ${misc:Depends}, vitastor-client (= ${binary:Version})
 Description: Vitastor Proxmox Virtual Environment storage plugin
  Vitastor storage plugin for Proxmox Virtual Environment.
-
-Package: vitastor-opennebula
-Architecture: amd64
-Depends: ${shlibs:Depends}, ${misc:Depends}, vitastor-client, patch, python3, jq
-Description: Vitastor OpenNebula storage plugin
- Vitastor storage plugin for OpenNebula.

debian/libisal.pc

@@ -1,11 +0,0 @@
-prefix=/usr
-exec_prefix=${prefix}
-libdir=${prefix}/lib/x86_64-linux-gnu
-includedir=${prefix}/include
-
-Name: libisal
-Description: Library for storage systems
-Version: 2.30.0
-Libs: -L${libdir} -lisal
-Libs.private:
-Cflags: -I${includedir}

debian/libvirt.Dockerfile

@@ -1,14 +1,13 @@
 # Build patched libvirt for Debian Buster or Bullseye/Sid inside a container
-# cd ..; podman build --build-arg DISTRO=debian --build-arg REL=bullseye -v `pwd`/packages:/root/packages -f debian/libvirt.Dockerfile .
+# cd ..; podman build --build-arg REL=bullseye -v `pwd`/packages:/root/packages -f debian/libvirt.Dockerfile .
 
-ARG DISTRO=
 ARG REL=
-FROM $DISTRO:$REL
+FROM debian:$REL
 ARG REL=
 
 WORKDIR /root
 
-RUN if ([ "${DISTRO}" = "debian" ]) && ( [ "${REL}" = "buster" -o "${REL}" = "bullseye" ] ); then \
+RUN if [ "$REL" = "buster" -o "$REL" = "bullseye" ]; then \
         echo "deb http://deb.debian.org/debian $REL-backports main" >> /etc/apt/sources.list; \
         echo >> /etc/apt/preferences; \
         echo 'Package: *' >> /etc/apt/preferences; \
@@ -24,7 +23,7 @@ RUN apt-get -y build-dep libvirt0
 RUN apt-get -y install libglusterfs-dev
 RUN apt-get --download-only source libvirt
 
-ADD patches/libvirt-5.0-vitastor.diff patches/libvirt-7.0-vitastor.diff patches/libvirt-7.5-vitastor.diff patches/libvirt-7.6-vitastor.diff patches/libvirt-8.0-vitastor.diff /root
+ADD patches/libvirt-5.0-vitastor.diff patches/libvirt-7.0-vitastor.diff patches/libvirt-7.5-vitastor.diff patches/libvirt-7.6-vitastor.diff /root
 RUN set -e; \
     mkdir -p /root/packages/libvirt-$REL; \
     rm -rf /root/packages/libvirt-$REL/*; \

debian/patched-qemu.Dockerfile

@@ -1,4 +1,4 @@
-# Build patched QEMU for Debian inside a container
+# Build patched QEMU for Debian Buster or Bullseye/Sid inside a container
 # cd ..; podman build --build-arg REL=bullseye -v `pwd`/packages:/root/packages -f debian/patched-qemu.Dockerfile .
 
 ARG REL=
@@ -7,7 +7,7 @@ ARG REL=
 
 WORKDIR /root
 
-RUN if [ "$REL" = "buster" -o "$REL" = "bullseye" -o "$REL" = "bookworm" ]; then \
+RUN if [ "$REL" = "buster" -o "$REL" = "bullseye" ]; then \
         echo "deb http://deb.debian.org/debian $REL-backports main" >> /etc/apt/sources.list; \
         echo >> /etc/apt/preferences; \
         echo 'Package: *' >> /etc/apt/preferences; \
@@ -15,47 +15,47 @@ RUN if [ "$REL" = "buster" -o "$REL" = "bullseye" -o "$REL" = "bookworm" ]; then
         echo 'Pin-Priority: 500' >> /etc/apt/preferences; \
     fi; \
     grep '^deb ' /etc/apt/sources.list | perl -pe 's/^deb/deb-src/' >> /etc/apt/sources.list; \
-    perl -i -pe 's/Types: deb$/Types: deb deb-src/' /etc/apt/sources.list.d/debian.sources || true; \
     echo 'APT::Install-Recommends false;' >> /etc/apt/apt.conf; \
     echo 'APT::Install-Suggests false;' >> /etc/apt/apt.conf
 
 RUN apt-get update
-RUN apt-get -y install fio liburing-dev libgoogle-perftools-dev devscripts
+RUN apt-get -y install qemu fio liburing1 liburing-dev libgoogle-perftools-dev devscripts
 RUN apt-get -y build-dep qemu
 # To build a custom version
 #RUN cp /root/packages/qemu-orig/* /root
 RUN apt-get --download-only source qemu
 
-ADD patches /root/vitastor/patches
-ADD src/client/qemu_driver.c /root/qemu_driver.c
-
-#RUN set -e; \
-#    apt-get install -y wget; \
-#    wget -q -O /etc/apt/trusted.gpg.d/vitastor.gpg https://vitastor.io/debian/pubkey.gpg; \
-#    (echo deb http://vitastor.io/debian $REL main > /etc/apt/sources.list.d/vitastor.list); \
-#    (echo "APT::Install-Recommends false;" > /etc/apt/apt.conf) && \
-#    apt-get update; \
-#    apt-get install -y vitastor-client vitastor-client-dev quilt
-
+ADD patches/qemu-5.0-vitastor.patch patches/qemu-5.1-vitastor.patch patches/qemu-6.1-vitastor.patch src/qemu_driver.c /root/vitastor/patches/
 RUN set -e; \
-    dpkg -i /root/packages/vitastor-$REL/vitastor-client_*.deb /root/packages/vitastor-$REL/vitastor-client-dev_*.deb; \
+    apt-get install -y wget; \
+    wget -q -O /etc/apt/trusted.gpg.d/vitastor.gpg https://vitastor.io/debian/pubkey.gpg; \
+    (echo deb http://vitastor.io/debian $REL main > /etc/apt/sources.list.d/vitastor.list); \
+    (echo "APT::Install-Recommends false;" > /etc/apt/apt.conf) && \
     apt-get update; \
-    apt-get install -y quilt; \
+    apt-get install -y vitastor-client vitastor-client-dev quilt; \
     mkdir -p /root/packages/qemu-$REL; \
     rm -rf /root/packages/qemu-$REL/*; \
     cd /root/packages/qemu-$REL; \
     dpkg-source -x /root/qemu*.dsc; \
-    QEMU_VER=$(ls -d qemu*/ | perl -pe 's!^.*?(\d+\.\d+).*!$1!'); \
-    D=$(ls -d qemu*/); \
-    cp /root/vitastor/patches/qemu-$QEMU_VER-vitastor.patch ./qemu-*/debian/patches; \
-    echo qemu-$QEMU_VER-vitastor.patch >> $D/debian/patches/series; \
+    if ls -d /root/packages/qemu-$REL/qemu-5.0*; then \
+        D=$(ls -d /root/packages/qemu-$REL/qemu-5.0*); \
+        cp /root/vitastor/patches/qemu-5.0-vitastor.patch $D/debian/patches; \
+        echo qemu-5.0-vitastor.patch >> $D/debian/patches/series; \
+    elif ls /root/packages/qemu-$REL/qemu-6.1*; then \
+        D=$(ls -d /root/packages/qemu-$REL/qemu-6.1*); \
+        cp /root/vitastor/patches/qemu-6.1-vitastor.patch $D/debian/patches; \
+        echo qemu-6.1-vitastor.patch >> $D/debian/patches/series; \
+    else \
+        cp /root/vitastor/patches/qemu-5.1-vitastor.patch /root/packages/qemu-$REL/qemu-*/debian/patches; \
+        P=`ls -d /root/packages/qemu-$REL/qemu-*/debian/patches`; \
+        echo qemu-5.1-vitastor.patch >> $P/series; \
+    fi; \
     cd /root/packages/qemu-$REL/qemu-*/; \
     quilt push -a; \
     quilt add block/vitastor.c; \
-    cp /root/qemu_driver.c block/vitastor.c; \
+    cp /root/vitastor/patches/qemu_driver.c block/vitastor.c; \
     quilt refresh; \
-    V=$(head -n1 debian/changelog | perl -pe 's/5\.2\+dfsg-9/5.2+dfsg-11/; s/^.*\((.*?)(~bpo[\d\+]*)?\).*$/$1/')+vitastor4; \
-    if [ "$REL" = bullseye ]; then V=${V}bullseye; fi; \
+    V=$(head -n1 debian/changelog | perl -pe 's/^.*\((.*?)(~bpo[\d\+]*)?\).*$/$1/')+vitastor1; \
     DEBEMAIL="Vitaliy Filippov <vitalif@yourcmc.ru>" dch -D $REL -v $V 'Plug Vitastor block driver'; \
     DEB_BUILD_OPTIONS=nocheck dpkg-buildpackage --jobs=auto -sa; \
     rm -rf /root/packages/qemu-$REL/qemu-*/

debian/pve-storage-vitastor.install

@@ -1 +1 @@
-patches/VitastorPlugin.pm usr/share/perl5/PVE/Storage/Custom/
+patches/PVE_VitastorPlugin.pm usr/share/perl5/PVE/Storage/Custom/VitastorPlugin.pm

debian/vitastor-client.install

@@ -2,7 +2,5 @@ usr/bin/vita
 usr/bin/vitastor-cli
 usr/bin/vitastor-rm
 usr/bin/vitastor-nbd
-usr/bin/vitastor-nfs
-usr/bin/vitastor-kv
-usr/bin/vitastor-kv-stress
 usr/lib/*/libvitastor*.so*
+mon/make-osd.sh /usr/lib/vitastor

debian/vitastor-mon.install

@@ -1,3 +1 @@
-mon usr/lib/vitastor/
-mon/scripts/make-etcd usr/lib/vitastor/mon
-mon/scripts/vitastor-mon.service /lib/systemd/system
+mon usr/lib/vitastor

debian/vitastor-mon.postinst

@@ -1,11 +0,0 @@
-#!/bin/sh
-
-set -e
-
-if [ "$1" = "configure" ]; then
-	addgroup --system --quiet vitastor
-	adduser --system --quiet --ingroup vitastor --no-create-home --home /nonexistent vitastor
-	mkdir -p /etc/vitastor
-	mkdir -p /var/lib/vitastor
-	chown vitastor:vitastor /var/lib/vitastor
-fi

debian/vitastor-opennebula.install

@@ -1,3 +0,0 @@
-opennebula/remotes var/lib/one/
-opennebula/sudoers.d etc/
-opennebula/install.sh var/lib/one/remotes/datastore/vitastor/

debian/vitastor-opennebula.postinst

@@ -1,7 +0,0 @@
-#!/bin/sh
-
-set -e
-
-if [ "$1" = "configure" ]; then
-	/var/lib/one/remotes/datastore/vitastor/install.sh
-fi

debian/vitastor-opennebula.triggers

@@ -1,4 +0,0 @@
-interest /var/lib/one/remotes/datastore/downloader.sh
-interest /etc/one/oned.conf
-interest /etc/one/vmm_exec/vmm_execrc
-interest /etc/apparmor.d/local/abstractions/libvirt-qemu

debian/vitastor-osd.install

@@ -1,6 +1,2 @@
 usr/bin/vitastor-osd
-usr/bin/vitastor-disk
 usr/bin/vitastor-dump-journal
-mon/scripts/vitastor-osd@.service /lib/systemd/system
-mon/scripts/vitastor.target /lib/systemd/system
-mon/scripts/90-vitastor.rules /lib/udev/rules.d

debian/vitastor-osd.postinst

@@ -1,10 +0,0 @@
-#!/bin/sh
-
-set -e
-
-if [ "$1" = "configure" ]; then
-	addgroup --system --quiet vitastor
-	adduser --system --quiet --ingroup vitastor --no-create-home --home /nonexistent vitastor
-	install -o vitastor -g vitastor -d /var/log/vitastor
-	mkdir -p /etc/vitastor
-fi

debian/vitastor.Dockerfile

@@ -1,34 +1,31 @@
-# Build Vitastor packages for Debian inside a container
-# cd ..; podman build --build-arg DISTRO=debian --build-arg REL=bullseye -v `pwd`/packages:/root/packages -f debian/vitastor.Dockerfile .
+# Build Vitastor packages for Debian Buster or Bullseye/Sid inside a container
+# cd ..; podman build --build-arg REL=bullseye -v `pwd`/packages:/root/packages -f debian/vitastor.Dockerfile .
 
-ARG DISTRO=debian
 ARG REL=
-FROM $DISTRO:$REL
-ARG DISTRO=debian
+FROM debian:$REL
 ARG REL=
 
 WORKDIR /root
 
-RUN set -e -x; \
-    if [ "$REL" = "buster" ]; then \
-        apt-get update; \
-        apt-get -y install wget; \
-        wget https://vitastor.io/debian/pubkey.gpg -O /etc/apt/trusted.gpg.d/vitastor.gpg; \
-        echo "deb https://vitastor.io/debian $REL main" >> /etc/apt/sources.list; \
+RUN if [ "$REL" = "buster" -o "$REL" = "bullseye" ]; then \
+        echo "deb http://deb.debian.org/debian $REL-backports main" >> /etc/apt/sources.list; \
+        echo >> /etc/apt/preferences; \
+        echo 'Package: *' >> /etc/apt/preferences; \
+        echo "Pin: release a=$REL-backports" >> /etc/apt/preferences; \
+        echo 'Pin-Priority: 500' >> /etc/apt/preferences; \
     fi; \
     grep '^deb ' /etc/apt/sources.list | perl -pe 's/^deb/deb-src/' >> /etc/apt/sources.list; \
-    perl -i -pe 's/Types: deb$/Types: deb deb-src/' /etc/apt/sources.list.d/debian.sources || true; \
     echo 'APT::Install-Recommends false;' >> /etc/apt/apt.conf; \
     echo 'APT::Install-Suggests false;' >> /etc/apt/apt.conf
 
 RUN apt-get update
-RUN apt-get -y install fio liburing-dev libgoogle-perftools-dev devscripts libjerasure-dev cmake libibverbs-dev libisal-dev libnl-3-dev libnl-genl-3-dev curl
+RUN apt-get -y install fio liburing1 liburing-dev libgoogle-perftools-dev devscripts
 RUN apt-get -y build-dep fio
 RUN apt-get --download-only source fio
+RUN apt-get update && apt-get -y install libjerasure-dev cmake libibverbs-dev
 
 ADD . /root/vitastor
 RUN set -e -x; \
-    [ -e /usr/lib/x86_64-linux-gnu/pkgconfig/libisal.pc ] || cp /root/vitastor/debian/libisal.pc /usr/lib/x86_64-linux-gnu/pkgconfig; \
     mkdir -p /root/fio-build/; \
     cd /root/fio-build/; \
     rm -rf /root/fio-build/*; \
@@ -36,10 +33,8 @@ RUN set -e -x; \
     mkdir -p /root/packages/vitastor-$REL; \
     rm -rf /root/packages/vitastor-$REL/*; \
     cd /root/packages/vitastor-$REL; \
-    FULLVER=$(head -n1 /root/vitastor/debian/changelog | perl -pe 's/^.*\((.*?)\).*$/$1/'); \
-    VER=${FULLVER%%-*}; \
-    cp -r /root/vitastor vitastor-$VER; \
-    cd vitastor-$VER; \
+    cp -r /root/vitastor vitastor-0.6.10; \
+    cd vitastor-0.6.10; \
     ln -s /root/fio-build/fio-*/ ./fio; \
     FIO=$(head -n1 fio/debian/changelog | perl -pe 's/^.*\((.*?)\).*$/$1/'); \
     ls /usr/include/linux/raw.h || cp ./debian/raw.h /usr/include/linux/raw.h; \
@@ -51,14 +46,10 @@ RUN set -e -x; \
     echo fio-headers.patch >> debian/patches/series; \
     rm -rf a b; \
     echo "dep:fio=$FIO" > debian/fio_version; \
-    cd /root/packages/vitastor-$REL/vitastor-$VER; \
-    mkdir mon/node_modules; \
-    cd mon/node_modules; \
-    curl -s https://git.yourcmc.ru/vitalif/antietcd/archive/master.tar.gz | tar -zx; \
-    curl -s https://git.yourcmc.ru/vitalif/tinyraft/archive/master.tar.gz | tar -zx; \
     cd /root/packages/vitastor-$REL; \
-    tar --sort=name --mtime='2020-01-01' --owner=0 --group=0 --exclude=debian -cJf vitastor_$VER.orig.tar.xz vitastor-$VER; \
-    cd vitastor-$VER; \
-    DEBFULLNAME="Vitaliy Filippov <vitalif@yourcmc.ru>" dch -D $REL -v "$FULLVER""$REL" "Rebuild for $REL"; \
+    tar --sort=name --mtime='2020-01-01' --owner=0 --group=0 --exclude=debian -cJf vitastor_0.6.10.orig.tar.xz vitastor-0.6.10; \
+    cd vitastor-0.6.10; \
+    V=$(head -n1 debian/changelog | perl -pe 's/^.*\((.*?)\).*$/$1/'); \
+    DEBFULLNAME="Vitaliy Filippov <vitalif@yourcmc.ru>" dch -D $REL -v "$V""$REL" "Rebuild for $REL"; \
     DEB_BUILD_OPTIONS=nocheck dpkg-buildpackage --jobs=auto -sa; \
     rm -rf /root/packages/vitastor-$REL/vitastor-*/

docs/config.en.md

@@ -1,40 +0,0 @@
-[Documentation](../README.md#documentation) → Configuration Reference
-
------
-
-[Читать на русском](config.ru.md)
-
-# Configuration Reference
-
-Vitastor configuration consists of:
-- [Configuration parameters (key-value)](#parameter-reference)
-- [Pool configuration](config/pool.en.md)
-- [OSD placement tree configuration](config/pool.en.md#placement-tree)
-- [Separate OSD settings](config/pool.en.md#osd-settings)
-- [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 (when you run it without vitastor-disk),
-  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.
-- OSD superblocks created by [vitastor-disk](usage/disk.en.md) contain
-  primarily disk layout parameters of specific OSDs. In fact, these parameters
-  are automatically passed into the command line of vitastor-osd process, so
-  they have the same "status" as command-line parameters.
-
-In the future, additional configuration methods may be added:
-- OSD-specific keys in etcd like `/vitastor/config/osd/<number>`.
-
-## Parameter Reference
-
-- [Common](config/common.en.md)
-- [Network](config/network.en.md)
-- [Client](config/client.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)

docs/config.ru.md

@@ -1,43 +0,0 @@
-[Документация](../README-ru.md#документация) → Конфигурация Vitastor
-
------
-
-[Read in English](config.en.md)
-
-# Конфигурация Vitastor
-
-Конфигурация Vitastor состоит из:
-- [Параметров (ключ-значение)](#список-параметров)
-- [Настроек пулов](config/pool.ru.md)
-- [Настроек дерева OSD](config/pool.ru.md#дерево-размещения)
-- [Настроек отдельных OSD](config/pool.ru.md#настройки-osd)
-- [Настроек инодов](config/inode.ru.md), т.е. метаданных образов, таких, как имя, размер и ссылки на
-  родительский образ
-
-Параметры конфигурации могут задаваться в 3 местах:
-- Файле конфигурации (`/etc/vitastor/vitastor.conf` или по другому пути)
-- Ключе в etcd `/vitastor/config/global`. Большая часть параметров может
-  задаваться там, кроме, естественно, самих параметров соединения с etcd,
-  которые должны задаваться в файле конфигурации
-- В командной строке компонентов Vitastor: OSD (при ручном запуске без vitastor-disk),
-  монитора, опциях fio и QEMU, настроек OpenStack, Proxmox и т.п. Последние,
-  как правило, не включают полный набор параметров напрямую, но позволяют
-  определить путь к файлу конфигурации и задать любые параметры в нём.
-- В суперблоке OSD, записываемом [vitastor-disk](usage/disk.ru.md) - параметры,
-  связанные с дисковым форматом и с этим конкретным OSD. На самом деле,
-  при запуске OSD эти параметры автоматически передаются в командную строку
-  процесса vitastor-osd, то есть по "статусу" они эквивалентны параметрам
-  командной строки OSD.
-
-В будущем также могут быть добавлены другие способы конфигурации:
-- OSD-специфичные ключи в etcd типа `/vitastor/config/osd/<номер>`.
-
-## Список параметров
-
-- [Общие](config/common.ru.md)
-- [Сеть](config/network.ru.md)
-- [Клиентский код](config/client.ru.md)
-- [Глобальные дисковые параметры](config/layout-cluster.ru.md)
-- [Дисковые параметры OSD](config/layout-osd.ru.md)
-- [Прочие параметры OSD](config/osd.ru.md)
-- [Параметры мониторов](config/monitor.ru.md)

docs/config/client.en.md

@@ -1,203 +0,0 @@
-[Documentation](../../README.md#documentation) → [Configuration](../config.en.md) → Client Parameters
-
------
-
-[Читать на русском](client.ru.md)
-
-# Client Parameters
-
-These parameters apply only to Vitastor clients (QEMU, fio, NBD and so on) and
-affect their interaction with the cluster.
-
-- [client_iothread_count](#client_iothread_count)
-- [client_retry_interval](#client_retry_interval)
-- [client_eio_retry_interval](#client_eio_retry_interval)
-- [client_retry_enospc](#client_retry_enospc)
-- [client_max_dirty_bytes](#client_max_dirty_bytes)
-- [client_max_dirty_ops](#client_max_dirty_ops)
-- [client_enable_writeback](#client_enable_writeback)
-- [client_max_buffered_bytes](#client_max_buffered_bytes)
-- [client_max_buffered_ops](#client_max_buffered_ops)
-- [client_max_writeback_iodepth](#client_max_writeback_iodepth)
-- [nbd_timeout](#nbd_timeout)
-- [nbd_max_devices](#nbd_max_devices)
-- [nbd_max_part](#nbd_max_part)
-- [osd_nearfull_ratio](#osd_nearfull_ratio)
-
-## client_iothread_count
-
-- Type: integer
-- Default: 0
-
-Number of separate threads for handling TCP network I/O at client library
-side. Enabling 4 threads usually allows to increase peak performance of each
-client from approx. 2-3 to 7-8 GByte/s linear read/write and from approx.
-100-150 to 400 thousand iops, but at the same time it increases latency.
-Latency increase depends on CPU: with CPU power saving disabled latency
-only increases by ~10 us (equivalent to Q=1 iops decrease from 10500 to 9500),
-with CPU power saving enabled it may be as high as 500 us (equivalent to Q=1
-iops decrease from 2000 to 1000). RDMA isn't affected by this option.
-
-It's recommended to enable client I/O threads if you don't use RDMA and want
-to increase peak client performance.
-
-## client_retry_interval
-
-- Type: milliseconds
-- Default: 50
-- Minimum: 10
-- Can be changed online: yes
-
-Retry time for I/O requests failed due to inactive PGs or network
-connectivity errors.
-
-## client_eio_retry_interval
-
-- Type: milliseconds
-- Default: 1000
-- Can be changed online: yes
-
-Retry time for I/O requests failed due to data corruption or unfinished
-EC object deletions (has_incomplete PG state). 0 disables such retries
-and clients are not blocked and just get EIO error code instead.
-
-## client_retry_enospc
-
-- Type: boolean
-- Default: true
-- Can be changed online: yes
-
-Retry writes on out of space errors to wait until some space is freed on
-OSDs.
-
-## client_max_dirty_bytes
-
-- Type: integer
-- Default: 33554432
-- Can be changed online: yes
-
-Without [immediate_commit](layout-cluster.en.md#immediate_commit)=all this parameter sets the limit of "dirty"
-(not committed by fsync) data allowed by the client before forcing an
-additional fsync and committing the data. Also note that the client always
-holds a copy of uncommitted data in memory so this setting also affects
-RAM usage of clients.
-
-## client_max_dirty_ops
-
-- Type: integer
-- Default: 1024
-- Can be changed online: yes
-
-Same as client_max_dirty_bytes, but instead of total size, limits the number
-of uncommitted write operations.
-
-## client_enable_writeback
-
-- Type: boolean
-- Default: false
-- Can be changed online: yes
-
-This parameter enables client-side write buffering. This means that write
-requests are accumulated in memory for a short time before being sent to
-a Vitastor cluster which allows to send them in parallel and increase
-performance of some applications. Writes are buffered until client forces
-a flush with fsync() or until the amount of buffered writes exceeds the
-limit.
-
-Write buffering significantly increases performance of some applications,
-for example, CrystalDiskMark under Windows (LOL :-D), but also any other
-applications if they do writes in one of two non-optimal ways: either if
-they do a lot of small (4 kb or so) sequential writes, or if they do a lot
-of small random writes, but without any parallelism or asynchrony, and also
-without calling fsync().
-
-With write buffering enabled, you can expect around 22000 T1Q1 random write
-iops in QEMU more or less regardless of the quality of your SSDs, and this
-number is in fact bound by QEMU itself rather than Vitastor (check it
-yourself by adding a "driver=null-co" disk in QEMU). Without write
-buffering, the current record is 9900 iops, but the number is usually
-even lower with non-ideal hardware, for example, it may be 5000 iops.
-
-Even when this parameter is enabled, write buffering isn't enabled until
-the client explicitly allows it, because enabling it without the client
-being aware of the fact that his writes may be buffered may lead to data
-loss. Because of this, older versions of clients don't support write
-buffering at all, newer versions of the QEMU driver allow write buffering
-only if it's enabled in disk settings with `-blockdev cache.direct=false`,
-and newer versions of FIO only allow write buffering if you don't specify
-`-direct=1`. NBD and NFS drivers allow write buffering by default.
-
-You can overcome this restriction too with the `client_writeback_allowed`
-parameter, but you shouldn't do that unless you **really** know what you
-are doing.
-
-## client_max_buffered_bytes
-
-- Type: integer
-- Default: 33554432
-- Can be changed online: yes
-
-Maximum total size of buffered writes which triggers write-back when reached.
-
-## client_max_buffered_ops
-
-- Type: integer
-- Default: 1024
-- Can be changed online: yes
-
-Maximum number of buffered writes which triggers write-back when reached.
-Multiple consecutive modified data regions are counted as 1 write here.
-
-## client_max_writeback_iodepth
-
-- Type: integer
-- Default: 256
-- Can be changed online: yes
-
-Maximum number of parallel writes when flushing buffered data to the server.
-
-## nbd_timeout
-
-- Type: seconds
-- Default: 300
-
-Timeout for I/O operations for [NBD](../usage/nbd.en.md). If an operation
-executes for longer than this timeout, including when your cluster is just
-temporarily down for more than timeout, the NBD device will detach by itself
-(and possibly break the mounted file system).
-
-You can set timeout to 0 to never detach, but in that case you won't be
-able to remove the kernel device at all if the NBD process dies - you'll have
-to reboot the host.
-
-## nbd_max_devices
-
-- Type: integer
-- Default: 64
-
-Maximum number of NBD devices in the system. This value is passed as
-`nbds_max` parameter for the nbd kernel module when vitastor-nbd autoloads it.
-
-## nbd_max_part
-
-- Type: integer
-- Default: 3
-
-Maximum number of partitions per NBD device. This value is passed as
-`max_part` parameter for the nbd kernel module when vitastor-nbd autoloads it.
-Note that (nbds_max)*(1+max_part) usually can't exceed 256.
-
-## osd_nearfull_ratio
-
-- Type: number
-- Default: 0.95
-- Can be changed online: yes
-
-Ratio of used space on OSD to treat it as "almost full" in vitastor-cli status output.
-
-Remember that some client writes may hang or complete with an error if even
-just one OSD becomes 100 % full!
-
-However, unlike in Ceph, 100 % full Vitastor OSDs don't crash (in Ceph they're
-unable to start at all), so you'll be able to recover from "out of space" errors
-without destroying and recreating OSDs.

docs/config/client.ru.md

@@ -1,207 +0,0 @@
-[Документация](../../README-ru.md#документация) → [Конфигурация](../config.ru.md) → Параметры клиентского кода
-
------
-
-[Read in English](client.en.md)
-
-# Параметры клиентского кода
-
-Данные параметры применяются только к клиентам Vitastor (QEMU, fio, NBD и т.п.) и
-затрагивают логику их работы с кластером.
-
-- [client_iothread_count](#client_iothread_count)
-- [client_retry_interval](#client_retry_interval)
-- [client_eio_retry_interval](#client_eio_retry_interval)
-- [client_retry_enospc](#client_retry_enospc)
-- [client_max_dirty_bytes](#client_max_dirty_bytes)
-- [client_max_dirty_ops](#client_max_dirty_ops)
-- [client_enable_writeback](#client_enable_writeback)
-- [client_max_buffered_bytes](#client_max_buffered_bytes)
-- [client_max_buffered_ops](#client_max_buffered_ops)
-- [client_max_writeback_iodepth](#client_max_writeback_iodepth)
-- [nbd_timeout](#nbd_timeout)
-- [nbd_max_devices](#nbd_max_devices)
-- [nbd_max_part](#nbd_max_part)
-- [osd_nearfull_ratio](#osd_nearfull_ratio)
-
-## client_iothread_count
-
-- Тип: целое число
-- Значение по умолчанию: 0
-
-Число отдельных потоков для обработки ввода-вывода через TCP сеть на стороне
-клиентской библиотеки. Включение 4 потоков обычно позволяет поднять пиковую
-производительность каждого клиента примерно с 2-3 до 7-8 Гбайт/с линейного
-чтения/записи и примерно с 100-150 до 400 тысяч операций ввода-вывода в
-секунду, но ухудшает задержку. Увеличение задержки зависит от процессора:
-при отключённом энергосбережении CPU это всего ~10 микросекунд (равносильно
-падению iops с Q=1 с 10500 до 9500), а при включённом это может быть
-и 500 микросекунд (равносильно падению iops с Q=1 с 2000 до 1000). На работу
-RDMA данная опция не влияет.
-
-Рекомендуется включать клиентские потоки ввода-вывода, если вы не используете
-RDMA и хотите повысить пиковую производительность клиентов.
-
-## client_retry_interval
-
-- Тип: миллисекунды
-- Значение по умолчанию: 50
-- Минимальное значение: 10
-- Можно менять на лету: да
-
-Время повтора запросов ввода-вывода, неудачных из-за неактивных PG или
-ошибок сети.
-
-## client_eio_retry_interval
-
-- Тип: миллисекунды
-- Значение по умолчанию: 1000
-- Можно менять на лету: да
-
-Время повтора запросов ввода-вывода, неудачных из-за повреждения данных
-или незавершённых удалений EC-объектов (состояния PG has_incomplete).
-0 отключает повторы таких запросов и клиенты не блокируются, а вместо
-этого просто получают код ошибки EIO.
-
-## client_retry_enospc
-
-- Тип: булево (да/нет)
-- Значение по умолчанию: true
-- Можно менять на лету: да
-
-Повторять запросы записи, завершившиеся с ошибками нехватки места, т.е.
-ожидать, пока на OSD не освободится место.
-
-## client_max_dirty_bytes
-
-- Тип: целое число
-- Значение по умолчанию: 33554432
-- Можно менять на лету: да
-
-При работе без [immediate_commit](layout-cluster.ru.md#immediate_commit)=all - это лимит объёма "грязных" (не
-зафиксированных fsync-ом) данных, при достижении которого клиент будет
-принудительно вызывать fsync и фиксировать данные. Также стоит иметь в виду,
-что в этом случае до момента fsync клиент хранит копию незафиксированных
-данных в памяти, то есть, настройка влияет на потребление памяти клиентами.
-
-## client_max_dirty_ops
-
-- Тип: целое число
-- Значение по умолчанию: 1024
-- Можно менять на лету: да
-
-Аналогично client_max_dirty_bytes, но ограничивает количество
-незафиксированных операций записи вместо их общего объёма.
-
-## client_enable_writeback
-
-- Тип: булево (да/нет)
-- Значение по умолчанию: false
-- Можно менять на лету: да
-
-Данный параметр разрешает включать буферизацию записи в памяти. Буферизация
-означает, что операции записи отправляются на кластер Vitastor не сразу, а
-могут небольшое время накапливаться в памяти и сбрасываться сразу пакетами,
-до тех пор, пока либо не будет превышен лимит неотправленных записей, либо
-пока клиент не вызовет fsync.
-
-Буферизация значительно повышает производительность некоторых приложений,
-например, CrystalDiskMark в Windows (ха-ха :-D), но также и любых других,
-которые пишут на диск неоптимально: либо последовательно, но мелкими блоками
-(например, по 4 кб), либо случайно, но без параллелизма и без fsync - то
-есть, например, отправляя 128 операций записи в разные места диска, но не
-все сразу с помощью асинхронного I/O, а по одной.
-
-В QEMU с буферизацией записи можно ожидать показателя примерно 22000
-операций случайной записи в секунду в 1 поток и с глубиной очереди 1 (T1Q1)
-без fsync, почти вне зависимости от того, насколько хороши ваши диски - эта
-цифра упирается в сам QEMU. Без буферизации рекорд пока что - 9900 операций
-в секунду, но на железе похуже может быть и поменьше, например, 5000 операций
-в секунду.
-
-При этом, даже если данный параметр включён, буферизация не включается, если
-явно не разрешена клиентом, т.к. если клиент не знает, что запросы записи
-буферизуются, это может приводить к потере данных. Поэтому в старых версиях
-клиентских драйверов буферизация записи не включается вообще, в новых
-версиях QEMU-драйвера включается, только если разрешена опцией диска
-`-blockdev cache.direct=false`, а в fio - только если нет опции `-direct=1`.
-В NBD и NFS драйверах буферизация записи разрешена по умолчанию.
-
-Можно обойти и это ограничение с помощью параметра `client_writeback_allowed`,
-но делать так не надо, если только вы не уверены в том, что делаете, на все
-100%. :-)
-
-## client_max_buffered_bytes
-
-- Тип: целое число
-- Значение по умолчанию: 33554432
-- Можно менять на лету: да
-
-Максимальный общий размер буферизованных записей, при достижении которого
-начинается процесс сброса данных на сервер.
-
-## client_max_buffered_ops
-
-- Тип: целое число
-- Значение по умолчанию: 1024
-- Можно менять на лету: да
-
-Максимальное количество буферизованных записей, при достижении которого
-начинается процесс сброса данных на сервер. При этом несколько
-последовательных изменённых областей здесь считаются 1 записью.
-
-## client_max_writeback_iodepth
-
-- Тип: целое число
-- Значение по умолчанию: 256
-- Можно менять на лету: да
-
-Максимальное число параллельных операций записи при сбросе буферов на сервер.
-
-## nbd_timeout
-
-- Тип: секунды
-- Значение по умолчанию: 300
-
-Таймаут для операций чтения/записи через [NBD](../usage/nbd.ru.md). Если
-операция выполняется дольше таймаута, включая временную недоступность
-кластера на время, большее таймаута, NBD-устройство отключится само собой
-(и, возможно, сломает примонтированную ФС).
-
-Вы можете установить таймаут в 0, чтобы никогда не отключать устройство по
-таймауту, но в этом случае вы вообще не сможете удалить устройство, если
-процесс NBD умрёт - вам придётся перезагружать сервер.
-
-## nbd_max_devices
-
-- Тип: целое число
-- Значение по умолчанию: 64
-
-Максимальное число NBD-устройств в системе. Данное значение передаётся
-модулю ядра nbd как параметр `nbds_max`, когда его загружает vitastor-nbd.
-
-## nbd_max_part
-
-- Тип: целое число
-- Значение по умолчанию: 3
-
-Максимальное число разделов на одном NBD-устройстве. Данное значение передаётся
-модулю ядра nbd как параметр `max_part`, когда его загружает vitastor-nbd.
-Имейте в виду, что (nbds_max)*(1+max_part) обычно не может превышать 256.
-
-## osd_nearfull_ratio
-
-- Тип: число
-- Значение по умолчанию: 0.95
-- Можно менять на лету: да
-
-Доля занятого места на OSD, начиная с которой он считается "почти заполненным" в
-выводе vitastor-cli status.
-
-Помните, что часть клиентских запросов может зависнуть или завершиться с ошибкой,
-если на 100 % заполнится хотя бы 1 OSD!
-
-Однако, в отличие от Ceph, заполненные на 100 % OSD Vitastor не падают (в Ceph
-заполненные на 100% OSD вообще не могут стартовать), так что вы сможете
-восстановить работу кластера после ошибок отсутствия свободного места
-без уничтожения и пересоздания OSD.

docs/config/common.en.md

@@ -1,52 +0,0 @@
-[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
-- Can be changed online: yes
-
-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 connection endpoints can be changed online by updating global
-configuration in etcd itself - this allows to switch the cluster to new
-etcd addresses without downtime.
-
-## 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
-- Can be changed online: yes
-
-Log level. Raise if you want more verbose output.

docs/config/common.ru.md

@@ -1,50 +0,0 @@
-[Документация](../../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 можно поменять на лету, обновив конфигурацию в
-самом etcd - это позволяет переключить кластер на новые etcd без остановки.
-
-## etcd_prefix
-
-- Тип: строка
-- Значение по умолчанию: /vitastor
-
-Префикс для ключей etcd, которые использует Vitastor. Вы можете задать другой
-префикс, например, чтобы запустить несколько кластеров Vitastor с одним
-кластером etcd.
-
-## log_level
-
-- Тип: целое число
-- Значение по умолчанию: 0
-- Можно менять на лету: да
-
-Уровень логгирования. Повысьте, если хотите более подробный вывод.

docs/config/inode.en.md

@@ -1,32 +0,0 @@
-[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:
-
-```
-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.
-
-vitastor-cli, K8s, OpenStack and other drivers also store the reverse mapping in `/vitastor/index/image/<name>` keys
-in JSON format: `{"id":<inode>,"pool_id":<pool>}` and ID counters in `/vitastor/index/maxid/<pool>` as numbers
-to simplify ID generation.

docs/config/inode.ru.md

@@ -1,34 +0,0 @@
-[Документация](../../README-ru.md#документация) → [Конфигурация](../config.ru.md) → Метаданные образов в etcd
-
------
-
-[Read in English](inode.en.md)
-
-# Метаданные образов в etcd
-
-Список образов хранится в etcd в ключах `/vitastor/config/inode/<pool>/<inode>`.
-
-Вы можете даже создавать образы вручную:
-
-```
-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), ссылающийся на только что переименованный
-в качестве родительского.
-
-vitastor-cli и драйвера K8s, OpenStack и т.п. также хранят обратный маппинг в ключах `/vitastor/index/image/<name>`
-в JSON-формате: `{"id":<inode>,"pool_id":<pool>}` и счётчики ID `/vitastor/index/maxid/<pool>` в виде просто чисел
-для упрощения генерации ID новых образов.

docs/config/layout-cluster.en.md

@@ -1,113 +0,0 @@
-[Documentation](../../README.md#documentation) → [Configuration](../config.en.md) → Cluster-Wide Disk Layout Parameters
-
------
-
-[Читать на русском](layout-cluster.ru.md)
-
-# Cluster-Wide Disk Layout Parameters
-
-These parameters apply to clients and OSDs, are fixed at the moment of OSD drive
-initialization and can't be changed after it without losing data.
-
-OSDs with different values of these parameters (for example, SSD and SSD+HDD
-OSDs) can coexist in one Vitastor cluster within different pools. Each pool can
-only include OSDs with identical settings of these parameters.
-
-These parameters, when set to a non-default value, must also be specified in
-etcd for clients to be aware of their values, either in /vitastor/config/global
-or in pool configuration. Pool configuration overrides the global setting.
-If the value for a pool in etcd doesn't match on-disk OSD configuration, the
-OSD will refuse to start PGs of that pool.
-
-- [block_size](#block_size)
-- [bitmap_granularity](#bitmap_granularity)
-- [immediate_commit](#immediate_commit)
-
-## block_size
-
-- Type: integer
-- Default: 131072
-
-Size of objects (data blocks) into which all physical and virtual drives
-(within a pool) are subdivided in Vitastor. One of current main settings
-in Vitastor, affects memory usage, write amplification and I/O load
-distribution effectiveness.
-
-Recommended default block size is 128 KB for SSD and 1 MB for HDD. In fact,
-it's possible to use 1 MB for SSD too - it will lower memory usage, but
-may increase average WA and reduce linear performance.
-
-OSD memory usage is roughly (SIZE / BLOCK * 68 bytes) which is roughly
-544 MB per 1 TB of used disk space with the default 128 KB block size.
-With 1 MB it's 8 times lower.
-
-## bitmap_granularity
-
-- Type: integer
-- Default: 4096
-
-Required virtual disk write alignment ("sector size"). Must be a multiple
-of disk_alignment. It's called bitmap granularity because Vitastor tracks
-an allocation bitmap for each object containing 2 bits per each
-(bitmap_granularity) bytes.
-
-Can't be smaller than the OSD data device sector.
-
-## immediate_commit
-
-- Type: string
-- Default: all
-
-One of "none", "all" or "small". Global value, may be overriden [at pool level](pool.en.md#immediate_commit).
-
-This parameter is also really important for performance.
-
-TLDR: default "all" is optimal for server-grade SSDs with supercapacitor-based
-power loss protection (nonvolatile write-through cache) and also for most HDDs.
-"none" or "small" should be only selected if you use desktop SSDs without
-capacitors or drives with slow write-back cache that can't be disabled. Check
-immediate_commit of your OSDs in [ls-osd](../usage/cli.en.md#ls-osd).
-
-Detailed explanation:
-
-Desktop SSDs are very fast (100000+ iops) for simple random writes
-without cache flush. However, they are really slow (only around 1000 iops)
-if you try to fsync() each write, that is, if you want to guarantee that
-each change gets actually persisted to the physical media.
-
-Server-grade SSDs with "Advanced/Enhanced Power Loss Protection" or with
-"Supercapacitor-based Power Loss Protection", on the other hand, are equally
-fast with and without fsync because their cache is protected from sudden
-power loss by a built-in supercapacitor-based "UPS".
-
-Some software-defined storage systems always fsync each write and thus are
-really slow when used with desktop SSDs. Vitastor, however, can also
-efficiently utilize desktop SSDs by postponing fsync until the client calls
-it explicitly.
-
-This is what this parameter regulates. When it's set to "all" Vitastor
-cluster commits each change to disks immediately and clients just
-ignore fsyncs because they know for sure that they're unneeded. This reduces
-the amount of network roundtrips performed by clients and improves
-performance. So it's always better to use server grade SSDs with
-supercapacitors even with Vitastor, especially given that they cost only
-a bit more than desktop models.
-
-There is also a common SATA SSD (and HDD too!) firmware bug (or feature)
-that makes server SSDs which have supercapacitors slow with fsync. To check
-if your SSDs are affected, compare benchmark results from `fio -name=test
--ioengine=libaio -direct=1 -bs=4k -rw=randwrite -iodepth=1` with and without
-`-fsync=1`. Results should be the same. If fsync=1 result is worse you can
-try to work around this bug by "disabling" drive write-back cache by running
-`hdparm -W 0 /dev/sdXX` or `echo write through > /sys/block/sdXX/device/scsi_disk/*/cache_type`
-(IMPORTANT: don't mistake it with `/sys/block/sdXX/queue/write_cache` - it's
-unsafe to change by hand). The same may apply to newer HDDs with internal
-SSD cache or "media-cache" - for example, a lot of Seagate EXOS drives have
-it (they have internal SSD cache even though it's not stated in datasheets).
-
-Setting this parameter to "all" or "small" in OSD parameters requires enabling
-[disable_journal_fsync](layout-osd.en.md#disable_journal_fsync) and
-[disable_meta_fsync](layout-osd.en.md#disable_meta_fsync), setting it to
-"all" also requires enabling [disable_data_fsync](layout-osd.en.md#disable_data_fsync).
-vitastor-disk tried to do that by default, first checking/disabling drive cache.
-If it can't disable drive cache, OSD get initialized with "none".

docs/config/layout-cluster.ru.md

@@ -1,117 +0,0 @@
-[Документация](../../README-ru.md#документация) → [Конфигурация](../config.ru.md) → Дисковые параметры уровня кластера
-
------
-
-[Read in English](layout-cluster.en.md)
-
-# Дисковые параметры уровня кластера
-
-Данные параметры используются клиентами и OSD, задаются в момент инициализации
-диска OSD и не могут быть изменены после этого без потери данных.
-
-OSD с разными значениями данных параметров (например, SSD и гибридные SSD+HDD
-OSD) могут сосуществовать в одном кластере Vitastor в разных пулах. Один пул
-может включать только OSD с одинаковыми настройками этих параметров.
-
-Данные параметры, отличаясь от значения по умолчанию, должны также быть заданы
-в etcd, чтобы клиенты могли узнать их значение, либо в глобальной конфигурации
-/vitastor/config/global, либо в настройках пулов. Настройки пула переопределяют
-глобальное значение. Если значение в настройках пула не будет соответствовать
-конфигурации OSD, OSD откажется запускать PG данного пула.
-
-- [block_size](#block_size)
-- [bitmap_granularity](#bitmap_granularity)
-- [immediate_commit](#immediate_commit)
-
-## block_size
-
-- Тип: целое число
-- Значение по умолчанию: 131072
-
-Размер объектов (блоков данных), на которые делятся физические и виртуальные
-диски в Vitastor (в рамках каждого пула). Одна из ключевых на данный момент
-настроек, влияет на потребление памяти, объём избыточной записи (write
-amplification) и эффективность распределения нагрузки по OSD.
-
-Рекомендуемые по умолчанию размеры блока - 128 килобайт для SSD и 1 мегабайт
-для HDD. В принципе, для SSD можно тоже использовать блок размером 1 мегабайт,
-это понизит использование памяти, но ухудшит распределение нагрузки и в
-среднем увеличит WA.
-
-Потребление памяти OSD составляет примерно (РАЗМЕР / БЛОК * 68 байт),
-т.е. примерно 544 МБ памяти на 1 ТБ занятого места на диске при
-стандартном 128 КБ блоке. При 1 МБ блоке памяти нужно в 8 раз меньше.
-
-## bitmap_granularity
-
-- Тип: целое число
-- Значение по умолчанию: 4096
-
-Требуемое выравнивание записи на виртуальные диски (размер их "сектора").
-Должен быть кратен disk_alignment. Называется гранулярностью битовой карты
-потому, что Vitastor хранит битовую карту для каждого объекта, содержащую
-по 2 бита на каждые (bitmap_granularity) байт.
-
-Не может быть меньше размера сектора дисков данных OSD.
-
-## immediate_commit
-
-- Тип: строка
-- Значение по умолчанию: all
-
-Одно из значений "none", "small" или "all". Глобальное значение, может быть
-переопределено [на уровне пула](pool.ru.md#immediate_commit).
-
-Данный параметр тоже важен для производительности.
-
-Вкратце: значение по умолчанию "all" оптимально для всех серверных SSD с
-суперконденсаторами и также для большинства HDD. "none" и "small" имеет смысл
-устанавливать только при использовании SSD настольного класса без
-суперконденсаторов или дисков с медленным неотключаемым кэшем записи.
-Проверьте настройку immediate_commit своих OSD в выводе команды [ls-osd](../usage/cli.ru.md#ls-osd).
-
-Модели SSD для настольных компьютеров очень быстрые (100000+ операций в
-секунду) при простой случайной записи без сбросов кэша. Однако они очень
-медленные (всего порядка 1000 iops), если вы пытаетесь сбрасывать кэш после
-каждой записи, то есть, если вы пытаетесь гарантировать, что каждое
-изменение физически записывается в энергонезависимую память.
-
-С другой стороны, серверные SSD с конденсаторами - функцией, называемой
-"Advanced/Enhanced Power Loss Protection" или просто "Supercapacitor-based
-Power Loss Protection" - одинаково быстрые и со сбросом кэша, и без
-него, потому что их кэш защищён от потери питания встроенным "источником
-бесперебойного питания" на основе суперконденсаторов и на самом деле они
-его никогда не сбрасывают.
-
-Некоторые программные СХД всегда сбрасывают кэши дисков при каждой записи
-и поэтому работают очень медленно с настольными SSD. Vitastor, однако, может
-откладывать fsync до явного его вызова со стороны клиента и таким образом
-эффективно утилизировать настольные SSD.
-
-Данный параметр влияет как раз на это. Когда он установлен в значение "all",
-кластер Vitastor мгновенно фиксирует каждое изменение на физические
-носители и клиенты могут просто игнорировать запросы fsync, т.к. они точно
-знают, что fsync-и не нужны. Это уменьшает число необходимых обращений к OSD
-по сети и улучшает производительность. Поэтому даже с Vitastor лучше всегда
-использовать только серверные модели SSD с суперконденсаторами, особенно
-учитывая то, что стоят они ненамного дороже настольных.
-
-Также в прошивках SATA SSD (и даже HDD!) очень часто встречается либо баг,
-либо просто особенность логики, из-за которой серверные SSD, имеющие
-конденсаторы и защиту от потери питания, всё равно медленно работают с
-fsync. Чтобы понять, подвержены ли этой проблеме ваши SSD, сравните
-результаты тестов `fio -name=test -ioengine=libaio -direct=1 -bs=4k
--rw=randwrite -iodepth=1` без и с опцией `-fsync=1`. Результаты должны
-быть одинаковые. Если результат с `fsync=1` хуже, вы можете попробовать
-обойти проблему, "отключив" кэш записи диска командой `hdparm -W 0 /dev/sdXX`
-либо `echo write through > /sys/block/sdXX/device/scsi_disk/*/cache_type`
-(ВАЖНО: не перепутайте с `/sys/block/sdXX/queue/write_cache` - этот параметр
-менять руками небезопасно). Такая же проблема может встречаться и в новых
-HDD-дисках с внутренним SSD или "медиа" кэшем - например, она встречается во
-многих дисках Seagate EXOS (у них есть внутренний SSD-кэш, хотя это и не
-указано в спецификациях).
-
-Указание "all" или "small" в настройках / командной строке OSD требует
-включения [disable_journal_fsync](layout-osd.ru.md#disable_journal_fsync) и
-[disable_meta_fsync](layout-osd.ru.md#disable_meta_fsync), значение "all"
-также требует включения [disable_data_fsync](layout-osd.ru.md#disable_data_fsync).

docs/config/layout-osd.en.md

@@ -1,218 +0,0 @@
-[Documentation](../../README.md#documentation) → [Configuration](../config.en.md) → OSD Disk Layout Parameters
-
------
-
-[Читать на русском](layout-osd.ru.md)
-
-# OSD Disk Layout Parameters
-
-These parameters apply to OSDs, are fixed at the moment of OSD drive
-initialization and can't be changed after it without losing data.
-
-- [data_device](#data_device)
-- [meta_device](#meta_device)
-- [journal_device](#journal_device)
-- [journal_offset](#journal_offset)
-- [journal_size](#journal_size)
-- [meta_offset](#meta_offset)
-- [data_offset](#data_offset)
-- [data_size](#data_size)
-- [meta_block_size](#meta_block_size)
-- [journal_block_size](#journal_block_size)
-- [disable_data_fsync](#disable_data_fsync)
-- [disable_meta_fsync](#disable_meta_fsync)
-- [disable_journal_fsync](#disable_journal_fsync)
-- [disable_device_lock](#disable_device_lock)
-- [disk_alignment](#disk_alignment)
-- [data_csum_type](#data_csum_type)
-- [csum_block_size](#csum_block_size)
-
-## data_device
-
-- Type: string
-
-Path to the block device to use for data. It's highly recommendded to use
-stable paths for all device names: `/dev/disk/by-partuuid/xxx...` instead
-of just `/dev/sda` or `/dev/nvme0n1` to not mess up after server restart.
-Files can also be used instead of block devices, but this is implemented
-only for testing purposes and not for production.
-
-## meta_device
-
-- Type: string
-
-Path to the block device to use for the metadata. Metadata must be on a fast
-SSD or performance will suffer. If this option is skipped, `data_device` is
-used for the metadata.
-
-## journal_device
-
-- Type: string
-
-Path to the block device to use for the journal. Journal must be on a fast
-SSD or performance will suffer. If this option is skipped, `meta_device` is
-used for the journal, and if it's also empty, journal is put on
-`data_device`. It's almost always fine to put metadata and journal on the
-same device, in this case you only need to set `meta_device`.
-
-## journal_offset
-
-- Type: integer
-- Default: 0
-
-Offset on the device in bytes where the journal is stored.
-
-## journal_size
-
-- Type: integer
-
-Journal size in bytes. By default, all available space between journal_offset
-and data_offset, meta_offset or the end of the journal device is used.
-Large journals aren't needed in SSD-only setups, 32 MB is always enough.
-In SSD+HDD setups it is beneficial to use larger journals (for example, 1 GB)
-and enable [throttle_small_writes](osd.en.md#throttle_small_writes).
-
-## meta_offset
-
-- Type: integer
-- Default: 0
-
-Offset on the device in bytes where the metadata area is stored.
-Again, set it to something if you colocate metadata with journal or data.
-
-## data_offset
-
-- Type: integer
-- Default: 0
-
-Offset on the device in bytes where the data area is stored.
-Again, set it to something if you colocate data with journal or metadata.
-
-## data_size
-
-- Type: integer
-
-Data area size in bytes. By default, the whole data device up to the end
-will be used for the data area, but you can restrict it if you want to use
-a smaller part. Note that there is no option to set metadata area size -
-it's derived from the data area size.
-
-## meta_block_size
-
-- Type: integer
-- Default: 4096
-
-Physical block size of the metadata device. 4096 for most current
-HDDs and SSDs.
-
-## journal_block_size
-
-- Type: integer
-- Default: 4096
-
-Physical block size of the journal device. Must be a multiple of
-`disk_alignment`. 4096 for most current HDDs and SSDs.
-
-## disable_data_fsync
-
-- Type: boolean
-- Default: false
-
-Do not issue fsyncs to the data device, i.e. do not force it to flush cache.
-Safe ONLY if your data device has write-through cache or if write-back
-cache is disabled. If you disable drive cache manually with `hdparm` or
-writing to `/sys/.../scsi_disk/cache_type` then make sure that you do it
-every time before starting Vitastor OSD (vitastor-disk does it automatically).
-See also [immediate_commit](layout-cluster.en.md#immediate_commit)
-for information about how to benefit from disabled cache.
-
-## disable_meta_fsync
-
-- Type: boolean
-- Default: false
-
-Same as disable_data_fsync, but for the metadata device. If the metadata
-device is not set or if the data device is used for the metadata the option
-is ignored and disable_data_fsync value is used instead of it.
-
-## disable_journal_fsync
-
-- Type: boolean
-- Default: false
-
-Same as disable_data_fsync, but for the journal device. If the journal
-device is not set or if the metadata device is used for the journal the
-option is ignored and disable_meta_fsync value is used instead of it. If
-the same device is used for data, metadata and journal the option is also
-ignored and disable_data_fsync value is used instead of it.
-
-## disable_device_lock
-
-- Type: boolean
-- Default: false
-
-Do not lock data, metadata and journal block devices exclusively with
-flock(). Though it's not recommended, but you can use it you want to run
-multiple OSD with a single device and different offsets, without using
-partitions.
-
-## disk_alignment
-
-- Type: integer
-- Default: 4096
-
-Required physical disk write alignment. Most current SSD and HDD drives
-use 4 KB physical sectors even if they report 512 byte logical sector
-size, so 4 KB is a good default setting.
-
-Note, however, that physical sector size also affects WA, because with block
-devices it's impossible to write anything smaller than a block. So, when
-Vitastor has to write a single metadata entry that's only about 32 bytes in
-size, it actually has to write the whole 4 KB sector.
-
-Because of this it can actually be beneficial to use SSDs which work well
-with 512 byte sectors and use 512 byte disk_alignment, journal_block_size
-and meta_block_size. But at the moment, no such SSDs are known...
-
-Clients don't need to be aware of disk_alignment, so it's not required to
-put a modified value into etcd key /vitastor/config/global.
-
-## data_csum_type
-
-- Type: string
-- Default: none
-
-Data checksum type to use. May be "crc32c" or "none". Set to "crc32c" to
-enable data checksums.
-
-## csum_block_size
-
-- Type: integer
-- Default: 4096
-
-Checksum calculation block size.
-
-Must be equal or a multiple of [bitmap_granularity](layout-cluster.en.md#bitmap_granularity)
-(which is usually 4 KB).
-
-Checksums increase metadata size by 4 bytes per each csum_block_size of data.
-
-Checksums are always a tradeoff:
-1. You either sacrifice +1 GB RAM per 1 TB of data
-2. Or you raise csum_block_size, for example, to 32k and sacrifice
-   50% random write iops due to checksum read-modify-write
-3. Or you turn off [inmemory_metadata](osd.en.md#inmemory_metadata) and
-   sacrifice 50% random read iops due to checksum reads
-
-All-flash clusters usually have enough RAM to use default csum_block_size,
-which uses 1 GB RAM per 1 TB of data. HDD clusters usually don't.
-
-Thus, recommended setups are:
-1. All-flash, 1 GB RAM per 1 TB data: default (csum_block_size=4k)
-2. All-flash, less RAM: csum_block_size=4k + inmemory_metadata=false
-3. Hybrid HDD+SSD: csum_block_size=4k + inmemory_metadata=false
-4. HDD-only, faster random read: csum_block_size=32k
-5. HDD-only, faster random write: csum_block_size=4k +
-   inmemory_metadata=false + meta_io=cached
-
-See also [meta_io](osd.en.md#meta_io).

docs/config/layout-osd.ru.md

@@ -1,231 +0,0 @@
-[Документация](../../README-ru.md#документация) → [Конфигурация](../config.ru.md) → Дисковые параметры OSD
-
------
-
-[Read in English](layout-osd.en.md)
-
-# Дисковые параметры OSD
-
-Данные параметры используются только OSD и, также как и общекластерные
-дисковые параметры, задаются в момент инициализации дисков OSD и не могут быть
-изменены после этого без потери данных.
-
-- [data_device](#data_device)
-- [meta_device](#meta_device)
-- [journal_device](#journal_device)
-- [journal_offset](#journal_offset)
-- [journal_size](#journal_size)
-- [meta_offset](#meta_offset)
-- [data_offset](#data_offset)
-- [data_size](#data_size)
-- [meta_block_size](#meta_block_size)
-- [journal_block_size](#journal_block_size)
-- [disable_data_fsync](#disable_data_fsync)
-- [disable_meta_fsync](#disable_meta_fsync)
-- [disable_journal_fsync](#disable_journal_fsync)
-- [disable_device_lock](#disable_device_lock)
-- [disk_alignment](#disk_alignment)
-- [data_csum_type](#data_csum_type)
-- [csum_block_size](#csum_block_size)
-
-## data_device
-
-- Тип: строка
-
-Путь к диску (блочному устройству) для хранения данных. Крайне рекомендуется
-использовать стабильные пути: `/dev/disk/by-partuuid/xxx...` вместо простых
-`/dev/sda` или `/dev/nvme0n1`, чтобы пути не могли спутаться после
-перезагрузки сервера. Также вместо блочных устройств можно указывать файлы,
-но это реализовано только для тестирования, а не для боевой среды.
-
-## meta_device
-
-- Тип: строка
-
-Путь к диску метаданных. Метаданные должны располагаться на быстром
-SSD-диске, иначе производительность пострадает. Если эта опция не указана,
-для метаданных используется `data_device`.
-
-## journal_device
-
-- Тип: строка
-
-Путь к диску журнала. Журнал должен располагаться на быстром SSD-диске,
-иначе производительность пострадает. Если эта опция не указана,
-для журнала используется `meta_device`, если же пуста и она, журнал
-располагается на `data_device`. Нормально располагать журнал и метаданные
-на одном устройстве, в этом случае достаточно указать только `meta_device`.
-
-## journal_offset
-
-- Тип: целое число
-- Значение по умолчанию: 0
-
-Смещение на устройстве в байтах, по которому располагается журнал.
-
-## journal_size
-
-- Тип: целое число
-
-Размер журнала в байтах. По умолчанию для журнала используется всё доступное
-место между journal_offset и data_offset, meta_offset или концом диска.
-В SSD-кластерах большие журналы не нужны, достаточно 32 МБ. В гибридных
-(SSD+HDD) кластерах осмысленно использовать больший размер журнал (например, 1 ГБ)
-и включить [throttle_small_writes](osd.ru.md#throttle_small_writes).
-
-## meta_offset
-
-- Тип: целое число
-- Значение по умолчанию: 0
-
-Смещение на устройстве в байтах, по которому располагаются метаданные.
-Эту опцию нужно задать, если метаданные у вас хранятся на том же
-устройстве, что данные или журнал.
-
-## data_offset
-
-- Тип: целое число
-- Значение по умолчанию: 0
-
-Смещение на устройстве в байтах, по которому располагаются данные.
-Эту опцию нужно задать, если данные у вас хранятся на том же
-устройстве, что метаданные или журнал.
-
-## data_size
-
-- Тип: целое число
-
-Размер области данных в байтах. По умолчанию под данные будет использована
-вся доступная область устройства данных до конца устройства, но вы можете
-использовать эту опцию, чтобы ограничить её меньшим размером. Заметьте, что
-опции размера области метаданных нет - она вычисляется из размера области
-данных автоматически.
-
-## meta_block_size
-
-- Тип: целое число
-- Значение по умолчанию: 4096
-
-Размер физического блока устройства метаданных. 4096 для большинства
-современных SSD и HDD.
-
-## journal_block_size
-
-- Тип: целое число
-- Значение по умолчанию: 4096
-
-Размер физического блока устройства журнала. Должен быть кратен
-`disk_alignment`. 4096 для большинства современных SSD и HDD.
-
-## disable_data_fsync
-
-- Тип: булево (да/нет)
-- Значение по умолчанию: false
-
-Не отправлять fsync-и устройству данных, т.е. не заставлять его сбрасывать кэш.
-Безопасно, ТОЛЬКО если ваше устройство данных имеет кэш со сквозной
-записью (write-through) или если кэш с отложенной записью (write-back) отключён.
-Если вы отключаете кэш вручную через `hdparm` или запись в `/sys/.../scsi_disk/cache_type`,
-то удостоверьтесь, что вы делаете это каждый раз перед запуском Vitastor OSD
-(vitastor-disk делает это автоматически). Смотрите также опцию
-[immediate_commit](layout-cluster.ru.md#immediate_commit) для информации о том,
-как извлечь выгоду из отключённого кэша.
-
-## disable_meta_fsync
-
-- Тип: булево (да/нет)
-- Значение по умолчанию: false
-
-То же, что disable_data_fsync, но для устройства метаданных. Если устройство
-метаданных не задано или если оно равно устройству данных, значение опции
-игнорируется и вместо него используется значение опции disable_data_fsync.
-
-## disable_journal_fsync
-
-- Тип: булево (да/нет)
-- Значение по умолчанию: false
-
-То же, что disable_data_fsync, но для устройства журнала. Если устройство
-журнала не задано или если оно равно устройству метаданных, значение опции
-игнорируется и вместо него используется значение опции disable_meta_fsync.
-Если одно и то же устройство используется и под данные, и под журнал, и под
-метаданные - значение опции также игнорируется и вместо него используется
-значение опции disable_data_fsync.
-
-## disable_device_lock
-
-- Тип: булево (да/нет)
-- Значение по умолчанию: false
-
-Не блокировать устройства данных, метаданных и журнала от открытия их
-другими OSD с помощью flock(). Так делать не рекомендуется, но теоретически
-вы можете это использовать, чтобы запускать несколько OSD на одном
-устройстве с разными смещениями и без использования разделов.
-
-## disk_alignment
-
-- Тип: целое число
-- Значение по умолчанию: 4096
-
-Требуемое выравнивание записи на физические диски. Почти все современные
-SSD и HDD диски используют 4 КБ физические секторы, даже если показывают
-логический размер сектора 512 байт, поэтому 4 КБ - хорошее значение по
-умолчанию.
-
-Однако стоит понимать, что физический размер сектора тоже влияет на
-избыточную запись (WA), потому что ничего меньше блока (сектора) на блочное
-устройство записать невозможно. Таким образом, когда Vitastor-у нужно
-записать на диск всего лишь одну 32-байтную запись метаданных, фактически
-приходится перезаписывать 4 КБ сектор целиком.
-
-Поэтому, на самом деле, может быть выгодно найти SSD, хорошо работающие с
-меньшими, 512-байтными, блоками и использовать 512-байтные disk_alignment,
-journal_block_size и meta_block_size. Однако на данный момент такие SSD
-не известны...
-
-Клиентам не обязательно знать про disk_alignment, так что помещать значение
-этого параметра в etcd в /vitastor/config/global не нужно.
-
-## data_csum_type
-
-- Тип: строка
-- Значение по умолчанию: none
-
-Тип используемых OSD контрольных сумм данных. Может быть "crc32c" или "none".
-Установите в "crc32c", чтобы включить расчёт и проверку контрольных сумм данных.
-
-Следует понимать, что контрольные суммы в зависимости от размера блока их
-расчёта либо увеличивают потребление памяти, либо снижают производительность.
-Подробнее смотрите в описании параметра [csum_block_size](#csum_block_size).
-
-## csum_block_size
-
-- Тип: целое число
-- Значение по умолчанию: 4096
-
-Размер блока расчёта контрольных сумм.
-
-Должен быть равен или кратен [bitmap_granularity](layout-cluster.ru.md#bitmap_granularity)
-(который обычно равен 4 КБ).
-
-Контрольные суммы увеличивают размер метаданных на 4 байта на каждые
-csum_block_size данных.
-
-Контрольные суммы - это всегда компромисс:
-1. Вы либо жертвуете потреблением +1 ГБ памяти на 1 ТБ дискового пространства
-2. Либо вы повышаете csum_block_size до, скажем, 32k и жертвуете 50%
-   скорости случайной записи из-за цикла чтения-изменения-записи для расчёта
-   новых контрольных сумм
-3. Либо вы отключаете [inmemory_metadata](osd.ru.md#inmemory_metadata) и
-   жертвуете 50% скорости случайного чтения из-за чтения контрольных сумм
-   с диска
-
-Таким образом, рекомендуются следующие варианты настроек:
-1. All-flash, 1 ГБ памяти на 1 ТБ данных: по умолчанию (csum_block_size=4k)
-2. All-flash, меньше памяти: csum_block_size=4k + inmemory_metadata=false
-3. Гибридные HDD+SSD: csum_block_size=4k + inmemory_metadata=false
-4. Только HDD, быстрее случайное чтение: csum_block_size=32k
-5. Только HDD, быстрее случайная запись: csum_block_size=4k +
-   inmemory_metadata=false + meta_io=cached
-
-Смотрите также [meta_io](osd.ru.md#meta_io).

docs/config/monitor.en.md

@@ -1,177 +0,0 @@
-[Documentation](../../README.md#documentation) → [Configuration](../config.en.md) → Monitor Parameters
-
------
-
-[Читать на русском](monitor.ru.md)
-
-# Monitor Parameters
-
-These parameters only apply to Monitors.
-
-- [use_antietcd](#use_antietcd)
-- [enable_prometheus](#enable_prometheus)
-- [mon_http_port](#mon_http_port)
-- [mon_http_ip](#mon_http_ip)
-- [mon_https_cert](#mon_https_cert)
-- [mon_https_key](#mon_https_key)
-- [mon_https_client_auth](#mon_https_client_auth)
-- [mon_https_ca](#mon_https_ca)
-- [etcd_mon_ttl](#etcd_mon_ttl)
-- [etcd_mon_timeout](#etcd_mon_timeout)
-- [etcd_mon_retries](#etcd_mon_retries)
-- [mon_change_timeout](#mon_change_timeout)
-- [mon_stats_timeout](#mon_stats_timeout)
-- [osd_out_time](#osd_out_time)
-- [placement_levels](#placement_levels)
-- [use_old_pg_combinator](#use_old_pg_combinator)
-
-## use_antietcd
-
-- Type: boolean
-- Default: false
-
-Enable experimental built-in etcd replacement (clustered key-value database):
-[antietcd](https://git.yourcmc.ru/vitalif/antietcd/).
-
-When set to true, monitor runs internal antietcd automatically if it finds
-a network interface with an IP address matching one of addresses in the
-`etcd_address` configuration option (in `/etc/vitastor/vitastor.conf` or in
-the monitor command line). If there are multiple matching addresses, it also
-checks `antietcd_port` and antietcd is started for address with matching port.
-By default, antietcd accepts connection on the selected IP address, but it
-can also be overridden manually in the `antietcd_ip` option.
-
-When antietcd is started, monitor stores cluster metadata itself and exposes
-a etcd-compatible REST API. On disk, these metadata are stored in
-`/var/lib/vitastor/mon_2379.json.gz` (can be overridden in antietcd_data_file
-or antietcd_data_dir options). All other antietcd parameters
-(see [here](https://git.yourcmc.ru/vitalif/antietcd/)) except node_id,
-cluster, cluster_key, persist_filter, stale_read can also be set in
-Vitastor configuration with `antietcd_` prefix.
-
-You can dump/load data to or from antietcd using Antietcd `anticli` tool:
-
-```
-npm exec anticli -e http://etcd:2379/v3 get --prefix '' --no-temp > dump.json
-npm exec anticli -e http://antietcd:2379/v3 load < dump.json
-```
-
-## enable_prometheus
-
-- Type: boolean
-- Default: true
-
-Enable built-in Prometheus metrics exporter at mon_http_port (8060 by default).
-
-Note that only the active (master) monitor exposes metrics, others return
-HTTP 503. So you should add all monitor URLs to your Prometheus job configuration.
-
-Grafana dashboard suitable for this exporter is here: [Vitastor-Grafana-6+.json](../../mon/scripts/Vitastor-Grafana-6+.json).
-
-## mon_http_port
-
-- Type: integer
-- Default: 8060
-
-HTTP port for monitors to listen on (including metrics exporter)
-
-## mon_http_ip
-
-- Type: string
-
-IP address for monitors to listen on (all addresses by default)
-
-## mon_https_cert
-
-- Type: string
-
-Path to PEM SSL certificate file for monitor to listen using HTTPS
-
-## mon_https_key
-
-- Type: string
-
-Path to PEM SSL private key file for monitor to listen using HTTPS
-
-## mon_https_client_auth
-
-- Type: boolean
-- Default: false
-
-Enable HTTPS client certificate-based authorization for monitor connections
-
-## mon_https_ca
-
-- Type: string
-
-Path to CA certificate for client HTTPS authorization
-
-## etcd_mon_ttl
-
-- Type: seconds
-- Default: 1
-- Minimum: 5
-
-Monitor etcd lease refresh interval in seconds
-
-## etcd_mon_timeout
-
-- Type: milliseconds
-- Default: 1000
-
-etcd request timeout used by monitor
-
-## etcd_mon_retries
-
-- Type: integer
-- Default: 5
-
-Maximum number of attempts for one monitor etcd request
-
-## mon_change_timeout
-
-- Type: milliseconds
-- Default: 1000
-- Minimum: 100
-
-Optimistic retry interval for monitor etcd modification requests
-
-## mon_stats_timeout
-
-- Type: milliseconds
-- Default: 1000
-- Minimum: 100
-
-Interval for monitor to wait before updating aggregated statistics in
-etcd after receiving OSD statistics updates
-
-## osd_out_time
-
-- Type: seconds
-- Default: 600
-
-Time after which a failed OSD is removed from the data distribution.
-I.e. time which the monitor waits before attempting to restore data
-redundancy using other OSDs.
-
-## placement_levels
-
-- Type: json
-- Default: `{"host":100,"osd":101}`
-
-Levels for the placement tree. You can define arbitrary tree levels by
-defining them in this parameter. The configuration parameter value should
-contain a JSON object with level names as keys and integer priorities as
-values.  Smaller priority means higher level in tree. For example,
-"datacenter" should have smaller priority than "osd". "host" and "osd"
-levels are always predefined and can't be removed. If one of them is not
-present in the configuration, then it is defined with the default priority
-(100 for "host", 101 for "osd").
-
-## use_old_pg_combinator
-
-- Type: boolean
-- Default: false
-
-Use the old PG combination generator which doesn't support [level_placement](pool.en.md#level_placement)
-and [raw_placement](pool.en.md#raw_placement) for pools which don't use this features.

docs/config/monitor.ru.md

@@ -1,180 +0,0 @@
-[Документация](../../README-ru.md#документация) → [Конфигурация](../config.ru.md) → Параметры мониторов
-
------
-
-[Read in English](monitor.en.md)
-
-# Параметры мониторов
-
-Данные параметры используются только мониторами Vitastor.
-
-- [use_antietcd](#use_antietcd)
-- [enable_prometheus](#enable_prometheus)
-- [mon_http_port](#mon_http_port)
-- [mon_http_ip](#mon_http_ip)
-- [mon_https_cert](#mon_https_cert)
-- [mon_https_key](#mon_https_key)
-- [mon_https_client_auth](#mon_https_client_auth)
-- [mon_https_ca](#mon_https_ca)
-- [etcd_mon_ttl](#etcd_mon_ttl)
-- [etcd_mon_timeout](#etcd_mon_timeout)
-- [etcd_mon_retries](#etcd_mon_retries)
-- [mon_change_timeout](#mon_change_timeout)
-- [mon_stats_timeout](#mon_stats_timeout)
-- [osd_out_time](#osd_out_time)
-- [placement_levels](#placement_levels)
-- [use_old_pg_combinator](#use_old_pg_combinator)
-
-## use_antietcd
-
-- Тип: булево (да/нет)
-- Значение по умолчанию: false
-
-Включить экспериментальный встроенный заменитель etcd (кластерную БД ключ-значение):
-[antietcd](https://git.yourcmc.ru/vitalif/antietcd/).
-
-Если параметр установлен в true, монитор запускает antietcd автоматически,
-если обнаруживает сетевой интерфейс с одним из адресов, указанных в опции
-конфигурации `etcd_address` (в `/etc/vitastor/vitastor.conf` или в опциях
-командной строки монитора). Если таких адресов несколько, также проверяется
-опция `antietcd_port` и antietcd запускается для адреса с соответствующим
-портом. По умолчанию antietcd принимает подключения по выбранному совпадающему
-IP, но его также можно определить вручную опцией `antietcd_ip`.
-
-При запуске antietcd монитор сам хранит центральные метаданные кластера и
-выставляет etcd-совместимое REST API. На диске эти метаданные хранятся в файле
-`/var/lib/vitastor/mon_2379.json.gz` (можно переопределить параметрами
-antietcd_data_file или antietcd_data_dir). Все остальные параметры antietcd
-(смотрите [по ссылке](https://git.yourcmc.ru/vitalif/antietcd/)), за исключением
-node_id, cluster, cluster_key, persist_filter, stale_read также можно задавать
-в конфигурации Vitastor с префиксом `antietcd_`.
-
-Вы можете выгружать/загружать данные в или из antietcd с помощью его инструмента
-`anticli`:
-
-```
-npm exec anticli -e http://etcd:2379/v3 get --prefix '' --no-temp > dump.json
-npm exec anticli -e http://antietcd:2379/v3 load < dump.json
-```
-
-## enable_prometheus
-
-- Тип: булево (да/нет)
-- Значение по умолчанию: true
-
-Включить встроенный Prometheus-экспортер метрик на порту mon_http_port (по умолчанию 8060).
-
-Обратите внимание, что метрики выставляет только активный (главный) монитор, остальные
-возвращают статус HTTP 503, поэтому вам следует добавлять адреса всех мониторов
-в задание по сбору метрик Prometheus.
-
-Дашборд для Grafana, подходящий для этого экспортера: [Vitastor-Grafana-6+.json](../../mon/scripts/Vitastor-Grafana-6+.json).
-
-## mon_http_port
-
-- Тип: целое число
-- Значение по умолчанию: 8060
-
-Порт, на котором мониторы принимают HTTP-соединения (в том числе для отдачи метрик)
-
-## mon_http_ip
-
-- Тип: строка
-
-IP-адрес, на котором мониторы принимают HTTP-соединения (по умолчанию все адреса)
-
-## mon_https_cert
-
-- Тип: строка
-
-Путь к PEM-файлу SSL-сертификата для монитора, чтобы принимать соединения через HTTPS
-
-## mon_https_key
-
-- Тип: строка
-
-Путь к PEM-файлу секретного SSL-ключа для монитора, чтобы принимать соединения через HTTPS
-
-## mon_https_client_auth
-
-- Тип: булево (да/нет)
-- Значение по умолчанию: false
-
-Включить в HTTPS-сервере монитора авторизацию по клиентским сертификатам
-
-## mon_https_ca
-
-- Тип: строка
-
-Путь к удостоверяющему сертификату для авторизации клиентских HTTPS соединений
-
-## etcd_mon_ttl
-
-- Тип: секунды
-- Значение по умолчанию: 1
-- Минимальное значение: 5
-
-Интервал обновления etcd резервации (lease) монитором
-
-## etcd_mon_timeout
-
-- Тип: миллисекунды
-- Значение по умолчанию: 1000
-
-Таймаут выполнения запросов к etcd от монитора
-
-## etcd_mon_retries
-
-- Тип: целое число
-- Значение по умолчанию: 5
-
-Максимальное число попыток выполнения запросов к etcd монитором
-
-## mon_change_timeout
-
-- Тип: миллисекунды
-- Значение по умолчанию: 1000
-- Минимальное значение: 100
-
-Время повтора при коллизиях при запросах модификации в etcd, производимых монитором
-
-## mon_stats_timeout
-
-- Тип: миллисекунды
-- Значение по умолчанию: 1000
-- Минимальное значение: 100
-
-Интервал, который монитор ожидает при изменении статистики по отдельным
-OSD перед обновлением агрегированной статистики в etcd
-
-## osd_out_time
-
-- Тип: секунды
-- Значение по умолчанию: 600
-
-Время, через которое отключенный OSD исключается из распределения данных.
-То есть, время, которое монитор ожидает перед попыткой переместить данные
-на другие OSD и таким образом восстановить избыточность хранения.
-
-## placement_levels
-
-- Тип: json
-- Значение по умолчанию: `{"host":100,"osd":101}`
-
-Определения уровней для дерева размещения OSD. Вы можете определять
-произвольные уровни, помещая их в данный параметр конфигурации. Значение
-параметра должно содержать JSON-объект, ключи которого будут являться
-названиями уровней, а значения - целочисленными приоритетами. Меньшие
-приоритеты соответствуют верхним уровням дерева. Например, уровень
-"датацентр" должен иметь меньший приоритет, чем "OSD". Уровни с названиями
-"host" и "osd" являются предопределёнными и не могут быть удалены. Если
-один из них отсутствует в конфигурации, он доопределяется с приоритетом по
-умолчанию (100 для уровня "host", 101 для "osd").
-
-## use_old_pg_combinator
-
-- Тип: булево (да/нет)
-- Значение по умолчанию: false
-
-Использовать старый генератор комбинаций PG, не поддерживающий [level_placement](pool.ru.md#level_placement)
-и [raw_placement](pool.ru.md#raw_placement) для пулов, которые не используют данные функции.

docs/config/network.en.md

@@ -1,255 +0,0 @@
-[Documentation](../../README.md#documentation) → [Configuration](../config.en.md) → Network Protocol Parameters
-
------
-
-[Читать на русском](network.ru.md)
-
-# Network Protocol Parameters
-
-These parameters apply to clients and OSDs and affect network connection logic
-between clients, OSDs and etcd.
-
-- [tcp_header_buffer_size](#tcp_header_buffer_size)
-- [use_sync_send_recv](#use_sync_send_recv)
-- [use_rdma](#use_rdma)
-- [rdma_device](#rdma_device)
-- [rdma_port_num](#rdma_port_num)
-- [rdma_gid_index](#rdma_gid_index)
-- [rdma_mtu](#rdma_mtu)
-- [rdma_max_sge](#rdma_max_sge)
-- [rdma_max_msg](#rdma_max_msg)
-- [rdma_max_recv](#rdma_max_recv)
-- [rdma_max_send](#rdma_max_send)
-- [rdma_odp](#rdma_odp)
-- [peer_connect_interval](#peer_connect_interval)
-- [peer_connect_timeout](#peer_connect_timeout)
-- [osd_idle_timeout](#osd_idle_timeout)
-- [osd_ping_timeout](#osd_ping_timeout)
-- [max_etcd_attempts](#max_etcd_attempts)
-- [etcd_quick_timeout](#etcd_quick_timeout)
-- [etcd_slow_timeout](#etcd_slow_timeout)
-- [etcd_keepalive_timeout](#etcd_keepalive_timeout)
-- [etcd_ws_keepalive_interval](#etcd_ws_keepalive_interval)
-
-## tcp_header_buffer_size
-
-- Type: integer
-- Default: 65536
-
-Size of the buffer used to read data using an additional copy. Vitastor
-packet headers are 128 bytes, payload is always at least 4 KB, so it is
-usually beneficial to try to read multiple packets at once even though
-it requires to copy the data an additional time. The rest of each packet
-is received without an additional copy. You can try to play with this
-parameter and see how it affects random iops and linear bandwidth if you
-want.
-
-## use_sync_send_recv
-
-- Type: boolean
-- Default: false
-
-If true, synchronous send/recv syscalls are used instead of io_uring for
-socket communication. Useless for OSDs because they require io_uring anyway,
-but may be required for clients with old kernel versions.
-
-## use_rdma
-
-- Type: boolean
-- Default: true
-
-Try to use RDMA for communication if it's available. Disable if you don't
-want Vitastor to use RDMA. TCP-only clients can also talk to an RDMA-enabled
-cluster, so disabling RDMA may be needed if clients have RDMA devices,
-but they are not connected to the cluster.
-
-## rdma_device
-
-- Type: string
-
-RDMA device name to use for Vitastor OSD communications (for example,
-"rocep5s0f0"). Now Vitastor supports all adapters, even ones without
-ODP support, like Mellanox ConnectX-3 and non-Mellanox cards.
-
-Versions up to Vitastor 1.2.0 required ODP which is only present in
-Mellanox ConnectX >= 4. See also [rdma_odp](#rdma_odp).
-
-Run `ibv_devinfo -v` as root to list available RDMA devices and their
-features.
-
-Remember that you also have to configure your network switches if you use
-RoCE/RoCEv2, otherwise you may experience unstable performance. Refer to
-the manual of your network vendor for details about setting up the switch
-for RoCEv2 correctly. Usually it means setting up Lossless Ethernet with
-PFC (Priority Flow Control) and ECN (Explicit Congestion Notification).
-
-## rdma_port_num
-
-- Type: integer
-- Default: 1
-
-RDMA device port number to use. Only for devices that have more than 1 port.
-See `phys_port_cnt` in `ibv_devinfo -v` output to determine how many ports
-your device has.
-
-## rdma_gid_index
-
-- Type: integer
-- Default: 0
-
-Global address identifier index of the RDMA device to use. Different GID
-indexes may correspond to different protocols like RoCEv1, RoCEv2 and iWARP.
-Search for "GID" in `ibv_devinfo -v` output to determine which GID index
-you need.
-
-**IMPORTANT:** If you want to use RoCEv2 (as recommended) then the correct
-rdma_gid_index is usually 1 (IPv6) or 3 (IPv4).
-
-## rdma_mtu
-
-- Type: integer
-- Default: 4096
-
-RDMA Path MTU to use. Must be 1024, 2048 or 4096. There is usually no
-sense to change it from the default 4096.
-
-## rdma_max_sge
-
-- Type: integer
-- Default: 128
-
-Maximum number of scatter/gather entries to use for RDMA. OSDs negotiate
-the actual value when establishing connection anyway, so it's usually not
-required to change this parameter.
-
-## rdma_max_msg
-
-- Type: integer
-- Default: 132096
-
-Maximum size of a single RDMA send or receive operation in bytes.
-
-## rdma_max_recv
-
-- Type: integer
-- Default: 16
-
-Maximum number of RDMA receive buffers per connection (RDMA requires
-preallocated buffers to receive data). Each buffer is `rdma_max_msg` bytes
-in size. So this setting directly affects memory usage: a single Vitastor
-RDMA client uses `rdma_max_recv * rdma_max_msg * OSD_COUNT` bytes of memory.
-Default is roughly 2 MB * number of OSDs.
-
-## rdma_max_send
-
-- Type: integer
-- Default: 8
-
-Maximum number of outstanding RDMA send operations per connection. Should be
-less than `rdma_max_recv` so the receiving side doesn't run out of buffers.
-Doesn't affect memory usage - additional memory isn't allocated for send
-operations.
-
-## rdma_odp
-
-- Type: boolean
-- Default: false
-
-Use RDMA with On-Demand Paging. ODP is currently only available on Mellanox
-ConnectX-4 and newer adapters. ODP allows to not register memory explicitly
-for RDMA adapter to be able to use it. This, in turn, allows to skip memory
-copying during sending. One would think this should improve performance, but
-**in reality** RDMA performance with ODP is **drastically** worse. Example
-3-node cluster with 8 NVMe in each node and 2*25 GBit/s ConnectX-6 RDMA network
-without ODP pushes 3950000 read iops, but only 239000 iops with ODP...
-
-This happens because Mellanox ODP implementation seems to be based on
-message retransmissions when the adapter doesn't know about the buffer yet -
-it likely uses standard "RNR retransmissions" (RNR = receiver not ready)
-which is generally slow in RDMA/RoCE networks. Here's a presentation about
-it from ISPASS-2021 conference: https://tkygtr6.github.io/pub/ISPASS21_slides.pdf
-
-ODP support is retained in the code just in case a good ODP implementation
-appears one day.
-
-## peer_connect_interval
-
-- Type: seconds
-- Default: 5
-- Minimum: 1
-- Can be changed online: yes
-
-Interval before attempting to reconnect to an unavailable OSD.
-
-## peer_connect_timeout
-
-- Type: seconds
-- Default: 5
-- Minimum: 1
-- Can be changed online: yes
-
-Timeout for OSD connection attempts.
-
-## osd_idle_timeout
-
-- Type: seconds
-- Default: 5
-- Minimum: 1
-- Can be changed online: yes
-
-OSD connection inactivity time after which clients and other OSDs send
-keepalive requests to check state of the connection.
-
-## osd_ping_timeout
-
-- Type: seconds
-- Default: 5
-- Minimum: 1
-- Can be changed online: yes
-
-Maximum time to wait for OSD keepalive responses. If an OSD doesn't respond
-within this time, the connection to it is dropped and a reconnection attempt
-is scheduled.
-
-## max_etcd_attempts
-
-- Type: integer
-- Default: 5
-- Can be changed online: yes
-
-Maximum number of attempts for etcd requests which can't be retried
-indefinitely.
-
-## etcd_quick_timeout
-
-- Type: milliseconds
-- Default: 1000
-- Can be changed online: yes
-
-Timeout for etcd requests which should complete quickly, like lease refresh.
-
-## etcd_slow_timeout
-
-- Type: milliseconds
-- Default: 5000
-- Can be changed online: yes
-
-Timeout for etcd requests which are allowed to wait for some time.
-
-## etcd_keepalive_timeout
-
-- Type: seconds
-- Default: max(30, etcd_report_interval*2)
-- Can be changed online: yes
-
-Timeout for etcd connection HTTP Keep-Alive. Should be higher than
-etcd_report_interval to guarantee that keepalive actually works.
-
-## etcd_ws_keepalive_interval
-
-- Type: seconds
-- Default: 5
-- Can be changed online: yes
-
-etcd websocket ping interval required to keep the connection alive and
-detect disconnections quickly.

docs/config/network.ru.md

@@ -1,265 +0,0 @@
-[Документация](../../README-ru.md#документация) → [Конфигурация](../config.ru.md) → Параметры сетевого протокола
-
------
-
-[Read in English](network.en.md)
-
-# Параметры сетевого протокола
-
-Данные параметры используются клиентами и OSD и влияют на логику сетевого
-взаимодействия между клиентами, OSD, а также etcd.
-
-- [tcp_header_buffer_size](#tcp_header_buffer_size)
-- [use_sync_send_recv](#use_sync_send_recv)
-- [use_rdma](#use_rdma)
-- [rdma_device](#rdma_device)
-- [rdma_port_num](#rdma_port_num)
-- [rdma_gid_index](#rdma_gid_index)
-- [rdma_mtu](#rdma_mtu)
-- [rdma_max_sge](#rdma_max_sge)
-- [rdma_max_msg](#rdma_max_msg)
-- [rdma_max_recv](#rdma_max_recv)
-- [rdma_max_send](#rdma_max_send)
-- [rdma_odp](#rdma_odp)
-- [peer_connect_interval](#peer_connect_interval)
-- [peer_connect_timeout](#peer_connect_timeout)
-- [osd_idle_timeout](#osd_idle_timeout)
-- [osd_ping_timeout](#osd_ping_timeout)
-- [max_etcd_attempts](#max_etcd_attempts)
-- [etcd_quick_timeout](#etcd_quick_timeout)
-- [etcd_slow_timeout](#etcd_slow_timeout)
-- [etcd_keepalive_timeout](#etcd_keepalive_timeout)
-- [etcd_ws_keepalive_interval](#etcd_ws_keepalive_interval)
-
-## tcp_header_buffer_size
-
-- Тип: целое число
-- Значение по умолчанию: 65536
-
-Размер буфера для чтения данных с дополнительным копированием. Пакеты
-Vitastor содержат 128-байтные заголовки, за которыми следуют данные размером
-от 4 КБ и для мелких операций ввода-вывода обычно выгодно за 1 вызов читать
-сразу несколько пакетов, даже не смотря на то, что это требует лишний раз
-скопировать данные. Часть каждого пакета за пределами значения данного
-параметра читается без дополнительного копирования. Вы можете попробовать
-поменять этот параметр и посмотреть, как он влияет на производительность
-случайного и линейного доступа.
-
-## use_sync_send_recv
-
-- Тип: булево (да/нет)
-- Значение по умолчанию: false
-
-Если установлено в истину, то вместо io_uring для передачи данных по сети
-будут использоваться обычные синхронные системные вызовы send/recv. Для OSD
-это бессмысленно, так как OSD в любом случае нуждается в io_uring, но, в
-принципе, это может применяться для клиентов со старыми версиями ядра.
-
-## use_rdma
-
-- Тип: булево (да/нет)
-- Значение по умолчанию: true
-
-Пытаться использовать RDMA для связи при наличии доступных устройств.
-Отключите, если вы не хотите, чтобы Vitastor использовал RDMA.
-TCP-клиенты также могут работать с RDMA-кластером, так что отключать
-RDMA может быть нужно только если у клиентов есть RDMA-устройства,
-но они не имеют соединения с кластером Vitastor.
-
-## rdma_device
-
-- Тип: строка
-
-Название RDMA-устройства для связи с Vitastor OSD (например, "rocep5s0f0").
-Сейчас Vitastor поддерживает все модели адаптеров, включая те, у которых
-нет поддержки ODP, то есть вы можете использовать RDMA с ConnectX-3 и
-картами производства не Mellanox.
-
-Версии Vitastor до 1.2.0 включительно требовали ODP, который есть только
-на Mellanox ConnectX 4 и более новых. См. также [rdma_odp](#rdma_odp).
-
-Запустите `ibv_devinfo -v` от имени суперпользователя, чтобы посмотреть
-список доступных RDMA-устройств, их параметры и возможности.
-
-Обратите внимание, что если вы используете RoCE/RoCEv2, вам также необходимо
-правильно настроить для него коммутаторы, иначе вы можете столкнуться с
-нестабильной производительностью. Подробную информацию о настройке
-коммутатора для RoCEv2 ищите в документации производителя. Обычно это
-подразумевает настройку сети без потерь на основе PFC (Priority Flow
-Control) и ECN (Explicit Congestion Notification).
-
-## rdma_port_num
-
-- Тип: целое число
-- Значение по умолчанию: 1
-
-Номер порта RDMA-устройства, который следует использовать. Имеет смысл
-только для устройств, у которых более 1 порта. Чтобы узнать, сколько портов
-у вашего адаптера, посмотрите `phys_port_cnt` в выводе команды
-`ibv_devinfo -v`.
-
-## rdma_gid_index
-
-- Тип: целое число
-- Значение по умолчанию: 0
-
-Номер глобального идентификатора адреса RDMA-устройства, который следует
-использовать. Разным gid_index могут соответствовать разные протоколы связи:
-RoCEv1, RoCEv2, iWARP. Чтобы понять, какой нужен вам - смотрите строчки со
-словом "GID" в выводе команды `ibv_devinfo -v`.
-
-**ВАЖНО:** Если вы хотите использовать RoCEv2 (как мы и рекомендуем), то
-правильный rdma_gid_index, как правило, 1 (IPv6) или 3 (IPv4).
-
-## rdma_mtu
-
-- Тип: целое число
-- Значение по умолчанию: 4096
-
-Максимальная единица передачи (Path MTU) для RDMA. Должно быть равно 1024,
-2048 или 4096. Обычно нет смысла менять значение по умолчанию, равное 4096.
-
-## rdma_max_sge
-
-- Тип: целое число
-- Значение по умолчанию: 128
-
-Максимальное число записей разделения/сборки (scatter/gather) для RDMA.
-OSD в любом случае согласовывают реальное значение при установке соединения,
-так что менять этот параметр обычно не нужно.
-
-## rdma_max_msg
-
-- Тип: целое число
-- Значение по умолчанию: 132096
-
-Максимальный размер одной RDMA-операции отправки или приёма.
-
-## rdma_max_recv
-
-- Тип: целое число
-- Значение по умолчанию: 16
-
-Максимальное число буферов для RDMA-приёма данных на одно соединение
-(RDMA требует заранее выделенных буферов для приёма данных). Каждый буфер
-имеет размер `rdma_max_msg` байт. Таким образом, настройка прямо влияет на
-потребление памяти - один Vitastor-клиент с RDMA использует
-`rdma_max_recv * rdma_max_msg * ЧИСЛО_OSD` байт памяти, по умолчанию -
-примерно 2 МБ * число OSD.
-
-## rdma_max_send
-
-- Тип: целое число
-- Значение по умолчанию: 8
-
-Максимальное число RDMA-операций отправки, отправляемых в очередь одного
-соединения. Желательно, чтобы оно было меньше `rdma_max_recv`, чтобы
-у принимающей стороны в процессе работы не заканчивались буферы на приём.
-Не влияет на потребление памяти - дополнительная память на операции отправки
-не выделяется.
-
-## rdma_odp
-
-- Тип: булево (да/нет)
-- Значение по умолчанию: false
-
-Использовать RDMA с On-Demand Paging. ODP - функция, доступная пока что
-исключительно на адаптерах Mellanox ConnectX-4 и более новых. ODP позволяет
-не регистрировать память для её использования RDMA-картой. Благодаря этому
-можно не копировать данные при отправке их в сеть и, казалось бы, это должно
-улучшать производительность - но **по факту** получается так, что
-производительность только ухудшается, причём сильно. Пример - на 3-узловом
-кластере с 8 NVMe в каждом узле и сетью 2*25 Гбит/с на чтение с RDMA без ODP
-удаётся снять 3950000 iops, а с ODP - всего 239000 iops...
-
-Это происходит из-за того, что реализация ODP у Mellanox неоптимальная и
-основана на повторной передаче сообщений, когда карте не известен буфер -
-вероятно, на стандартных "RNR retransmission" (RNR = receiver not ready).
-А данные повторные передачи в RDMA/RoCE - всегда очень медленная штука.
-Презентация на эту тему с конференции ISPASS-2021: https://tkygtr6.github.io/pub/ISPASS21_slides.pdf
-
-Возможность использования ODP сохранена в коде на случай, если вдруг в один
-прекрасный день появится хорошая реализация ODP.
-
-## peer_connect_interval
-
-- Тип: секунды
-- Значение по умолчанию: 5
-- Минимальное значение: 1
-- Можно менять на лету: да
-
-Время ожидания перед повторной попыткой соединиться с недоступным OSD.
-
-## peer_connect_timeout
-
-- Тип: секунды
-- Значение по умолчанию: 5
-- Минимальное значение: 1
-- Можно менять на лету: да
-
-Максимальное время ожидания попытки соединения с OSD.
-
-## osd_idle_timeout
-
-- Тип: секунды
-- Значение по умолчанию: 5
-- Минимальное значение: 1
-- Можно менять на лету: да
-
-Время неактивности соединения с OSD, после которого клиенты или другие OSD
-посылают запрос проверки состояния соединения.
-
-## osd_ping_timeout
-
-- Тип: секунды
-- Значение по умолчанию: 5
-- Минимальное значение: 1
-- Можно менять на лету: да
-
-Максимальное время ожидания ответа на запрос проверки состояния соединения.
-Если OSD не отвечает за это время, соединение отключается и производится
-повторная попытка соединения.
-
-## max_etcd_attempts
-
-- Тип: целое число
-- Значение по умолчанию: 5
-- Можно менять на лету: да
-
-Максимальное число попыток выполнения запросов к etcd для тех запросов,
-которые нельзя повторять бесконечно.
-
-## etcd_quick_timeout
-
-- Тип: миллисекунды
-- Значение по умолчанию: 1000
-- Можно менять на лету: да
-
-Максимальное время выполнения запросов к etcd, которые должны завершаться
-быстро, таких, как обновление резервации (lease).
-
-## etcd_slow_timeout
-
-- Тип: миллисекунды
-- Значение по умолчанию: 5000
-- Можно менять на лету: да
-
-Максимальное время выполнения запросов к etcd, для которых не обязательно
-гарантировать быстрое выполнение.
-
-## etcd_keepalive_timeout
-
-- Тип: секунды
-- Значение по умолчанию: max(30, etcd_report_interval*2)
-- Можно менять на лету: да
-
-Таймаут для HTTP Keep-Alive в соединениях к etcd. Должен быть больше, чем
-etcd_report_interval, чтобы keepalive гарантированно работал.
-
-## etcd_ws_keepalive_interval
-
-- Тип: секунды
-- Значение по умолчанию: 5
-- Можно менять на лету: да
-
-Интервал проверки живости вебсокет-подключений к etcd.

docs/config/osd.en.md

@@ -1,631 +0,0 @@
-[Documentation](../../README.md#documentation) → [Configuration](../config.en.md) → Runtime OSD Parameters
-
------
-
-[Читать на русском](osd.ru.md)
-
-# Runtime OSD Parameters
-
-These parameters only apply to OSDs, are not fixed at the moment of OSD drive
-initialization and can be changed - either with an OSD restart or, for some of
-them, even without restarting by updating configuration in etcd.
-
-- [osd_iothread_count](#osd_iothread_count)
-- [etcd_report_interval](#etcd_report_interval)
-- [etcd_stats_interval](#etcd_stats_interval)
-- [run_primary](#run_primary)
-- [osd_network](#osd_network)
-- [bind_address](#bind_address)
-- [bind_port](#bind_port)
-- [autosync_interval](#autosync_interval)
-- [autosync_writes](#autosync_writes)
-- [recovery_queue_depth](#recovery_queue_depth)
-- [recovery_sleep_us](#recovery_sleep_us)
-- [recovery_pg_switch](#recovery_pg_switch)
-- [recovery_sync_batch](#recovery_sync_batch)
-- [readonly](#readonly)
-- [no_recovery](#no_recovery)
-- [no_rebalance](#no_rebalance)
-- [print_stats_interval](#print_stats_interval)
-- [slow_log_interval](#slow_log_interval)
-- [inode_vanish_time](#inode_vanish_time)
-- [max_write_iodepth](#max_write_iodepth)
-- [min_flusher_count](#min_flusher_count)
-- [max_flusher_count](#max_flusher_count)
-- [inmemory_metadata](#inmemory_metadata)
-- [inmemory_journal](#inmemory_journal)
-- [data_io](#data_io)
-- [meta_io](#meta_io)
-- [journal_io](#journal_io)
-- [journal_sector_buffer_count](#journal_sector_buffer_count)
-- [journal_no_same_sector_overwrites](#journal_no_same_sector_overwrites)
-- [throttle_small_writes](#throttle_small_writes)
-- [throttle_target_iops](#throttle_target_iops)
-- [throttle_target_mbs](#throttle_target_mbs)
-- [throttle_target_parallelism](#throttle_target_parallelism)
-- [throttle_threshold_us](#throttle_threshold_us)
-- [osd_memlock](#osd_memlock)
-- [auto_scrub](#auto_scrub)
-- [no_scrub](#no_scrub)
-- [scrub_interval](#scrub_interval)
-- [scrub_queue_depth](#scrub_queue_depth)
-- [scrub_sleep](#scrub_sleep)
-- [scrub_list_limit](#scrub_list_limit)
-- [scrub_find_best](#scrub_find_best)
-- [scrub_ec_max_bruteforce](#scrub_ec_max_bruteforce)
-- [recovery_tune_interval](#recovery_tune_interval)
-- [recovery_tune_util_low](#recovery_tune_util_low)
-- [recovery_tune_util_high](#recovery_tune_util_high)
-- [recovery_tune_client_util_low](#recovery_tune_client_util_low)
-- [recovery_tune_client_util_high](#recovery_tune_client_util_high)
-- [recovery_tune_agg_interval](#recovery_tune_agg_interval)
-- [recovery_tune_sleep_min_us](#recovery_tune_sleep_min_us)
-- [recovery_tune_sleep_cutoff_us](#recovery_tune_sleep_cutoff_us)
-
-## osd_iothread_count
-
-- Type: integer
-- Default: 0
-
-TCP network I/O thread count for OSD. When non-zero, a single OSD process
-may handle more TCP I/O, but at a cost of increased latency because thread
-switching overhead occurs. RDMA isn't affected by this option.
-
-Because of latency, instead of enabling OSD I/O threads it's recommended to
-just create multiple OSDs per disk, or use RDMA.
-
-## etcd_report_interval
-
-- Type: seconds
-- Default: 5
-
-Interval at which OSDs report their liveness to etcd. Affects OSD lease time
-and thus the failover speed. Lease time is equal to this parameter value
-plus max_etcd_attempts * etcd_quick_timeout because it should be guaranteed
-that every OSD always refreshes its lease in time.
-
-## etcd_stats_interval
-
-- Type: seconds
-- Default: 30
-
-Interval at which OSDs report their statistics to etcd. Highly affects the
-imposed load on etcd, because statistics include a key for every OSD and
-for every PG. At the same time, low statistic intervals make `vitastor-cli`
-statistics more responsive.
-
-## run_primary
-
-- Type: boolean
-- Default: true
-
-Start primary OSD logic on this OSD. As of now, can be turned off only for
-debugging purposes. It's possible to implement additional feature for the
-monitor which may allow to separate primary and secondary OSDs, but it's
-unclear why anyone could need it, so it's not implemented.
-
-## osd_network
-
-- Type: string or array of strings
-
-Network mask of the network (IPv4 or IPv6) to use for OSDs. Note that
-although it's possible to specify multiple networks here, this does not
-mean that OSDs will create multiple listening sockets - they'll only
-pick the first matching address of an UP + RUNNING interface. Separate
-networks for cluster and client connections are also not implemented, but
-they are mostly useless anyway, so it's not a big deal.
-
-## bind_address
-
-- Type: string
-- Default: 0.0.0.0
-
-Instead of the network mask, you can also set OSD listen address explicitly
-using this parameter. May be useful if you want to start OSDs on interfaces
-that are not UP + RUNNING.
-
-## bind_port
-
-- Type: integer
-
-By default, OSDs pick random ports to use for incoming connections
-automatically. With this option you can set a specific port for a specific
-OSD by hand.
-
-## autosync_interval
-
-- Type: seconds
-- Default: 5
-- Can be changed online: yes
-
-Time interval at which automatic fsyncs/flushes are issued by each OSD when
-the immediate_commit mode if disabled. fsyncs are required because without
-them OSDs quickly fill their journals, become unable to clear them and
-stall. Also this option limits the amount of recent uncommitted changes
-which OSDs may lose in case of a power outage in case when clients don't
-issue fsyncs at all.
-
-## autosync_writes
-
-- Type: integer
-- Default: 128
-- Can be changed online: yes
-
-Same as autosync_interval, but sets the maximum number of uncommitted write
-operations before issuing an fsync operation internally.
-
-## recovery_queue_depth
-
-- Type: integer
-- Default: 1
-- Can be changed online: yes
-
-Maximum recovery and rebalance operations initiated by each OSD in parallel.
-Note that each OSD talks to a lot of other OSDs so actual number of parallel
-recovery operations per each OSD is greater than just recovery_queue_depth.
-Increasing this parameter can speedup recovery if [auto-tuning](#recovery_tune_interval)
-allows it or if it is disabled.
-
-## recovery_sleep_us
-
-- Type: microseconds
-- Default: 0
-- Can be changed online: yes
-
-Delay for all recovery- and rebalance- related operations. If non-zero,
-such operations are artificially slowed down to reduce the impact on
-client I/O.
-
-## recovery_pg_switch
-
-- Type: integer
-- Default: 128
-- Can be changed online: yes
-
-Number of recovery operations before switching to recovery of the next PG.
-The idea is to mix all PGs during recovery for more even space and load
-distribution but still benefit from recovery queue depth greater than 1.
-Degraded PGs are anyway scanned first.
-
-## recovery_sync_batch
-
-- Type: integer
-- Default: 16
-- Can be changed online: yes
-
-Maximum number of recovery operations before issuing an additional fsync.
-
-## readonly
-
-- Type: boolean
-- Default: false
-
-Read-only mode. If this is enabled, an OSD will never issue any writes to
-the underlying device. This may be useful for recovery purposes.
-
-## no_recovery
-
-- Type: boolean
-- Default: false
-- Can be changed online: yes
-
-Disable automatic background recovery of objects. Note that it doesn't
-affect implicit recovery of objects happening during writes - a write is
-always made to a full set of at least pg_minsize OSDs.
-
-## no_rebalance
-
-- Type: boolean
-- Default: false
-- Can be changed online: yes
-
-Disable background movement of data between different OSDs. Disabling it
-means that PGs in the `has_misplaced` state will be left in it indefinitely.
-
-## print_stats_interval
-
-- Type: seconds
-- Default: 3
-- Can be changed online: yes
-
-Time interval at which OSDs print simple human-readable operation
-statistics on stdout.
-
-## slow_log_interval
-
-- Type: seconds
-- Default: 10
-- Can be changed online: yes
-
-Time interval at which OSDs dump slow or stuck operations on stdout, if
-they're any. Also it's the time after which an operation is considered
-"slow".
-
-## inode_vanish_time
-
-- Type: seconds
-- Default: 60
-- Can be changed online: yes
-
-Number of seconds after which a deleted inode is removed from OSD statistics.
-
-## max_write_iodepth
-
-- Type: integer
-- Default: 128
-- Can be changed online: yes
-
-Parallel client write operation limit per one OSD. Operations that exceed
-this limit are pushed to a temporary queue instead of being executed
-immediately.
-
-## min_flusher_count
-
-- Type: integer
-- Default: 1
-- Can be changed online: yes
-
-Flusher is a micro-thread that moves data from the journal to the data
-area of the device. Their number is auto-tuned between minimum and maximum.
-Minimum number is set by this parameter.
-
-## max_flusher_count
-
-- Type: integer
-- Default: 256
-- Can be changed online: yes
-
-Maximum number of journal flushers (see above min_flusher_count).
-
-## inmemory_metadata
-
-- Type: boolean
-- Default: true
-
-This parameter makes Vitastor always keep metadata area of the block device
-in memory. It's required for good performance because it allows to avoid
-additional read-modify-write cycles during metadata modifications. Metadata
-area size is currently roughly 224 MB per 1 TB of data. You can turn it off
-to reduce memory usage by this value, but it will hurt performance. This
-restriction is likely to be removed in the future along with the upgrade
-of the metadata storage scheme.
-
-## inmemory_journal
-
-- Type: boolean
-- Default: true
-
-This parameter make Vitastor always keep journal area of the block
-device in memory. Turning it off will, again, reduce memory usage, but
-hurt performance because flusher coroutines will have to read data from
-the disk back before copying it into the main area. The memory usage benefit
-is typically very small because it's sufficient to have 16-32 MB journal
-for SSD OSDs. However, in theory it's possible that you'll want to turn it
-off for hybrid (HDD+SSD) OSDs with large journals on quick devices.
-
-## data_io
-
-- Type: string
-- Default: direct
-
-I/O mode for *data*. One of "direct", "cached" or "directsync". Corresponds
-to O_DIRECT, O_SYNC and O_DIRECT|O_SYNC, respectively.
-
-Choose "cached" to use Linux page cache. This may improve read performance
-for hot data and slower disks - HDDs and maybe SATA SSDs - but will slightly
-decrease write performance for fast disks because page cache is an overhead
-itself.
-
-Choose "directsync" to use [immediate_commit](layout-cluster.ru.md#immediate_commit)
-(which requires disable_data_fsync) with drives having write-back cache
-which can't be turned off, for example, Intel Optane. Also note that *some*
-desktop SSDs (for example, HP EX950) may ignore O_SYNC thus making
-disable_data_fsync unsafe even with "directsync".
-
-## meta_io
-
-- Type: string
-- Default: direct
-
-I/O mode for *metadata*. One of "direct", "cached" or "directsync".
-
-"cached" may improve read performance, but only under the following conditions:
-1. your drives are relatively slow (HDD, SATA SSD), and
-2. checksums are enabled, and
-3. [inmemory_metadata](#inmemory_metadata) is disabled.
-Under all these conditions, metadata blocks are read from disk on every
-read request to verify checksums and caching them may reduce this extra
-read load. Without (3) metadata is never read from the disk after starting,
-and without (2) metadata blocks are read from disk only during journal
-flushing.
-
-"directsync" is the same as above.
-
-If the same device is used for data and metadata, meta_io by default is set
-to the same value as [data_io](#data_io).
-
-## journal_io
-
-- Type: string
-- Default: direct
-
-I/O mode for *journal*. One of "direct", "cached" or "directsync".
-
-Here, "cached" may only improve read performance for recent writes and
-only if [inmemory_journal](#inmemory_journal) is turned off.
-
-If the same device is used for metadata and journal, journal_io by default
-is set to the same value as [meta_io](#meta_io).
-
-## journal_sector_buffer_count
-
-- Type: integer
-- Default: 32
-
-Maximum number of buffers that can be used for writing journal metadata
-blocks. The only situation when you should increase it to a larger value
-is when you enable journal_no_same_sector_overwrites. In this case set
-it to, for example, 1024.
-
-## journal_no_same_sector_overwrites
-
-- Type: boolean
-- Default: false
-
-Enable this option for SSDs like Intel D3-S4510 and D3-S4610 which REALLY
-don't like when a program overwrites the same sector multiple times in a
-row and slow down significantly (from 25000+ iops to ~3000 iops). When
-this option is set, Vitastor will always move to the next sector of the
-journal after writing it instead of possibly overwriting it the second time.
-
-Most (99%) other SSDs don't need this option.
-
-## throttle_small_writes
-
-- Type: boolean
-- Default: false
-- Can be changed online: yes
-
-Enable soft throttling of small journaled writes. Useful for hybrid OSDs
-with fast journal/metadata devices and slow data devices. The idea is that
-small writes complete very quickly because they're first written to the
-journal device, but moving them to the main device is slow. So if an OSD
-allows clients to issue a lot of small writes it will perform very good
-for several seconds and then the journal will fill up and the performance
-will drop to almost zero. Throttling is meant to prevent this problem by
-artifically slowing quick writes down based on the amount of free space in
-the journal. When throttling is used, the performance of small writes will
-decrease smoothly instead of abrupt drop at the moment when the journal
-fills up.
-
-## throttle_target_iops
-
-- Type: integer
-- Default: 100
-- Can be changed online: yes
-
-Target maximum number of throttled operations per second under the condition
-of full journal. Set it to approximate random write iops of your data devices
-(HDDs).
-
-## throttle_target_mbs
-
-- Type: integer
-- Default: 100
-- Can be changed online: yes
-
-Target maximum bandwidth in MB/s of throttled operations per second under
-the condition of full journal. Set it to approximate linear write
-performance of your data devices (HDDs).
-
-## throttle_target_parallelism
-
-- Type: integer
-- Default: 1
-- Can be changed online: yes
-
-Target maximum parallelism of throttled operations under the condition of
-full journal. Set it to approximate internal parallelism of your data
-devices (1 for HDDs, 4-8 for SSDs).
-
-## throttle_threshold_us
-
-- Type: microseconds
-- Default: 50
-- Can be changed online: yes
-
-Minimal computed delay to be applied to throttled operations. Usually
-doesn't need to be changed.
-
-## osd_memlock
-
-- Type: boolean
-- Default: false
-
-Lock all OSD memory to prevent it from being unloaded into swap with
-mlockall(). Requires sufficient ulimit -l (max locked memory).
-
-## auto_scrub
-
-- Type: boolean
-- Default: false
-- Can be changed online: yes
-
-Data scrubbing is the process of background verification of copies to find
-and repair corrupted blocks. It's not run automatically by default since
-it's a new feature. Set this parameter to true to enable automatic scrubs.
-
-This parameter makes OSDs automatically schedule data scrubbing of clean PGs
-every `scrub_interval` (see below). You can also start/schedule scrubbing
-manually by setting `next_scrub` JSON key to the desired UNIX time of the
-next scrub in `/pg/history/...` values in etcd.
-
-## no_scrub
-
-- Type: boolean
-- Default: false
-- Can be changed online: yes
-
-Temporarily disable scrubbing and stop running scrubs.
-
-## scrub_interval
-
-- Type: string
-- Default: 30d
-- Can be changed online: yes
-
-Default automatic scrubbing interval for all pools. Numbers without suffix
-are treated as seconds, possible unit suffixes include 's' (seconds),
-'m' (minutes), 'h' (hours), 'd' (days), 'M' (months) and 'y' (years).
-
-## scrub_queue_depth
-
-- Type: integer
-- Default: 1
-- Can be changed online: yes
-
-Number of parallel scrubbing operations per one OSD.
-
-## scrub_sleep
-
-- Type: milliseconds
-- Default: 0
-- Can be changed online: yes
-
-Additional interval between two consecutive scrubbing operations on one OSD.
-Can be used to slow down scrubbing if it affects user load too much.
-
-## scrub_list_limit
-
-- Type: integer
-- Default: 1000
-- Can be changed online: yes
-
-Number of objects to list in one listing operation during scrub.
-
-## scrub_find_best
-
-- Type: boolean
-- Default: true
-- Can be changed online: yes
-
-Find and automatically restore best versions of objects with unmatched
-copies. In replicated setups, the best version is the version with most
-matching replicas. In EC setups, the best version is the subset of data
-and parity chunks without mismatches.
-
-The hypothetical situation where you might want to disable it is when
-you have 3 replicas and you are paranoid that 2 HDDs out of 3 may silently
-corrupt an object in the same way (for example, zero it out) and only
-1 HDD will remain good. In this case disabling scrub_find_best may help
-you to recover the data! See also scrub_ec_max_bruteforce below.
-
-## scrub_ec_max_bruteforce
-
-- Type: integer
-- Default: 100
-- Can be changed online: yes
-
-Vitastor can locate corrupted chunks in EC setups with more than 1 parity
-chunk by brute-forcing all possible error locations. This configuration
-value limits the maximum number of checked combinations. You can try to
-increase it if you have EC N+K setup with N and K large enough for
-combination count `C(N+K-1, K-1) = (N+K-1)! / (K-1)! / N!` to be greater
-than the default 100.
-
-If there are too many possible combinations or if multiple combinations give
-correct results then objects are marked inconsistent and aren't recovered
-automatically.
-
-In replicated setups bruteforcing isn't needed, Vitastor just assumes that
-the variant with most available equal copies is correct. For example, if
-you have 3 replicas and 1 of them differs, this one is considered to be
-corrupted. But if there is no "best" version with more copies than all
-others have then the object is also marked as inconsistent.
-
-## recovery_tune_interval
-
-- Type: seconds
-- Default: 1
-- Can be changed online: yes
-
-Interval at which OSD re-considers client and recovery load and automatically
-adjusts [recovery_sleep_us](#recovery_sleep_us). Recovery auto-tuning is
-disabled if recovery_tune_interval is set to 0.
-
-Auto-tuning targets utilization. Utilization is a measure of load and is
-equal to the product of iops and average latency (so it may be greater
-than 1). You set "low" and "high" client utilization thresholds and two
-corresponding target recovery utilization levels. OSD calculates desired
-recovery utilization from client utilization using linear interpolation
-and auto-tunes recovery operation delay to make actual recovery utilization
-match desired.
-
-This allows to reduce recovery/rebalance impact on client operations. It is
-of course impossible to remove it completely, but it should become adequate.
-In some tests rebalance could earlier drop client write speed from 1.5 GB/s
-to 50-100 MB/s, with default auto-tuning settings it now only reduces
-to ~1 GB/s.
-
-## recovery_tune_util_low
-
-- Type: number
-- Default: 0.1
-- Can be changed online: yes
-
-Desired recovery/rebalance utilization when client load is high, i.e. when
-it is at or above recovery_tune_client_util_high.
-
-## recovery_tune_util_high
-
-- Type: number
-- Default: 1
-- Can be changed online: yes
-
-Desired recovery/rebalance utilization when client load is low, i.e. when
-it is at or below recovery_tune_client_util_low.
-
-## recovery_tune_client_util_low
-
-- Type: number
-- Default: 0
-- Can be changed online: yes
-
-Client utilization considered "low".
-
-## recovery_tune_client_util_high
-
-- Type: number
-- Default: 0.5
-- Can be changed online: yes
-
-Client utilization considered "high".
-
-## recovery_tune_agg_interval
-
-- Type: integer
-- Default: 10
-- Can be changed online: yes
-
-The number of last auto-tuning iterations to use for calculating the
-delay as average. Lower values result in quicker response to client
-load change, higher values result in more stable delay. Default value of 10
-is usually fine.
-
-## recovery_tune_sleep_min_us
-
-- Type: microseconds
-- Default: 10
-- Can be changed online: yes
-
-Minimum possible value for auto-tuned recovery_sleep_us. Lower values
-are changed to 0.
-
-## recovery_tune_sleep_cutoff_us
-
-- Type: microseconds
-- Default: 10000000
-- Can be changed online: yes
-
-Maximum possible value for auto-tuned recovery_sleep_us. Higher values
-are treated as outliers and ignored in aggregation.

docs/config/osd.ru.md

@@ -1,662 +0,0 @@
-[Документация](../../README-ru.md#документация) → [Конфигурация](../config.ru.md) → Изменяемые параметры OSD
-
------
-
-[Read in English](osd.en.md)
-
-# Изменяемые параметры OSD
-
-Данные параметры используются только OSD, но, в отличие от дисковых параметров,
-не фиксируются в момент инициализации дисков OSD и могут быть изменены в любой
-момент с помощью перезапуска OSD, а некоторые и без перезапуска, с помощью
-изменения конфигурации в etcd.
-
-- [osd_iothread_count](#osd_iothread_count)
-- [etcd_report_interval](#etcd_report_interval)
-- [etcd_stats_interval](#etcd_stats_interval)
-- [run_primary](#run_primary)
-- [osd_network](#osd_network)
-- [bind_address](#bind_address)
-- [bind_port](#bind_port)
-- [autosync_interval](#autosync_interval)
-- [autosync_writes](#autosync_writes)
-- [recovery_queue_depth](#recovery_queue_depth)
-- [recovery_sleep_us](#recovery_sleep_us)
-- [recovery_pg_switch](#recovery_pg_switch)
-- [recovery_sync_batch](#recovery_sync_batch)
-- [readonly](#readonly)
-- [no_recovery](#no_recovery)
-- [no_rebalance](#no_rebalance)
-- [print_stats_interval](#print_stats_interval)
-- [slow_log_interval](#slow_log_interval)
-- [inode_vanish_time](#inode_vanish_time)
-- [max_write_iodepth](#max_write_iodepth)
-- [min_flusher_count](#min_flusher_count)
-- [max_flusher_count](#max_flusher_count)
-- [inmemory_metadata](#inmemory_metadata)
-- [inmemory_journal](#inmemory_journal)
-- [data_io](#data_io)
-- [meta_io](#meta_io)
-- [journal_io](#journal_io)
-- [journal_sector_buffer_count](#journal_sector_buffer_count)
-- [journal_no_same_sector_overwrites](#journal_no_same_sector_overwrites)
-- [throttle_small_writes](#throttle_small_writes)
-- [throttle_target_iops](#throttle_target_iops)
-- [throttle_target_mbs](#throttle_target_mbs)
-- [throttle_target_parallelism](#throttle_target_parallelism)
-- [throttle_threshold_us](#throttle_threshold_us)
-- [osd_memlock](#osd_memlock)
-- [auto_scrub](#auto_scrub)
-- [no_scrub](#no_scrub)
-- [scrub_interval](#scrub_interval)
-- [scrub_queue_depth](#scrub_queue_depth)
-- [scrub_sleep](#scrub_sleep)
-- [scrub_list_limit](#scrub_list_limit)
-- [scrub_find_best](#scrub_find_best)
-- [scrub_ec_max_bruteforce](#scrub_ec_max_bruteforce)
-- [recovery_tune_interval](#recovery_tune_interval)
-- [recovery_tune_util_low](#recovery_tune_util_low)
-- [recovery_tune_util_high](#recovery_tune_util_high)
-- [recovery_tune_client_util_low](#recovery_tune_client_util_low)
-- [recovery_tune_client_util_high](#recovery_tune_client_util_high)
-- [recovery_tune_agg_interval](#recovery_tune_agg_interval)
-- [recovery_tune_sleep_min_us](#recovery_tune_sleep_min_us)
-- [recovery_tune_sleep_cutoff_us](#recovery_tune_sleep_cutoff_us)
-
-## osd_iothread_count
-
-- Тип: целое число
-- Значение по умолчанию: 0
-
-Число отдельных потоков для обработки ввода-вывода через TCP-сеть на
-стороне OSD. Включение опции позволяет каждому отдельному OSD передавать
-по сети больше данных, но ухудшает задержку из-за накладных расходов
-переключения потоков. На работу RDMA опция не влияет.
-
-Из-за задержек вместо включения потоков ввода-вывода OSD рекомендуется
-просто создавать по несколько OSD на каждом диске, или использовать RDMA.
-
-## etcd_report_interval
-
-- Тип: секунды
-- Значение по умолчанию: 5
-
-Интервал, с которым OSD сообщает о том, что жив, в etcd. Значение параметра
-влияет на время резервации (lease) OSD и поэтому - на скорость переключения
-при падении OSD. Время lease равняется значению этого параметра плюс
-max_etcd_attempts * etcd_quick_timeout.
-
-## etcd_stats_interval
-
-- Тип: секунды
-- Значение по умолчанию: 30
-
-Интервал, с которым OSD обновляет свою статистику в etcd. Сильно влияет на
-создаваемую нагрузку на etcd, потому что статистика содержит по ключу на
-каждый OSD и на каждую PG. В то же время низкий интервал делает
-статистику, печатаемую `vitastor-cli`, отзывчивей.
-
-## run_primary
-
-- Тип: булево (да/нет)
-- Значение по умолчанию: true
-
-Запускать логику первичного OSD на данном OSD. На данный момент отключать
-эту опцию может иметь смысл только в целях отладки. В теории, можно
-реализовать дополнительный режим для монитора, который позволит отделять
-первичные OSD от вторичных, но пока не понятно, зачем это может кому-то
-понадобиться, поэтому это не реализовано.
-
-## osd_network
-
-- Тип: строка или массив строк
-
-Маска подсети (IPv4 или IPv6) для использования для соединений с OSD.
-Имейте в виду, что хотя сейчас и можно передать в этот параметр несколько
-подсетей, это не означает, что OSD будут создавать несколько слушающих
-сокетов - они лишь будут выбирать адрес первого поднятого (состояние UP +
-RUNNING), подходящий под заданную маску. Также не реализовано разделение
-кластерной и публичной сетей OSD. Правда, от него обычно всё равно довольно
-мало толку, так что особенной проблемы в этом нет.
-
-## bind_address
-
-- Тип: строка
-- Значение по умолчанию: 0.0.0.0
-
-Этим параметром можно явным образом задать адрес, на котором будет ожидать
-соединений OSD (вместо использования маски подсети). Может быть полезно,
-например, чтобы запускать OSD на неподнятых интерфейсах (не UP + RUNNING).
-
-## bind_port
-
-- Тип: целое число
-
-По умолчанию OSD сами выбирают случайные порты для входящих подключений.
-С помощью данной опции вы можете задать порт для отдельного OSD вручную.
-
-## autosync_interval
-
-- Тип: секунды
-- Значение по умолчанию: 5
-- Можно менять на лету: да
-
-Временной интервал отправки автоматических fsync-ов (операций очистки кэша)
-каждым OSD для случая, когда режим immediate_commit отключён. fsync-и нужны
-OSD, чтобы успевать очищать журнал - без них OSD быстро заполняют журналы и
-перестают обрабатывать операции записи. Также эта опция ограничивает объём
-недавних незафиксированных изменений, которые OSD могут терять при
-отключении питания, если клиенты вообще не отправляют fsync.
-
-## autosync_writes
-
-- Тип: целое число
-- Значение по умолчанию: 128
-- Можно менять на лету: да
-
-Аналогично autosync_interval, но задаёт не временной интервал, а
-максимальное количество незафиксированных операций записи перед
-принудительной отправкой fsync-а.
-
-## recovery_queue_depth
-
-- Тип: целое число
-- Значение по умолчанию: 1
-- Можно менять на лету: да
-
-Максимальное число параллельных операций восстановления, инициируемых одним
-OSD в любой момент времени. Имейте в виду, что каждый OSD обычно работает с
-многими другими OSD, так что на практике параллелизм восстановления больше,
-чем просто recovery_queue_depth. Увеличение значения этого параметра может
-ускорить восстановление если [автотюнинг скорости](#recovery_tune_interval)
-разрешает это или если он отключён.
-
-## recovery_sleep_us
-
-- Тип: микросекунды
-- Значение по умолчанию: 0
-- Можно менять на лету: да
-
-Delay for all recovery- and rebalance- related operations. If non-zero,
-such operations are artificially slowed down to reduce the impact on
-client I/O.
-
-## recovery_pg_switch
-
-- Тип: целое число
-- Значение по умолчанию: 128
-- Можно менять на лету: да
-
-Число операций восстановления перед переключением на восстановление другой PG.
-Идея заключается в том, чтобы восстанавливать все PG одновременно для более
-равномерного распределения места и нагрузки, но при этом всё равно выигрывать
-от глубины очереди восстановления, большей, чем 1. Деградированные PG в любом
-случае сканируются первыми.
-
-## recovery_sync_batch
-
-- Тип: целое число
-- Значение по умолчанию: 16
-- Можно менять на лету: да
-
-Максимальное число операций восстановления перед дополнительным fsync.
-
-## readonly
-
-- Тип: булево (да/нет)
-- Значение по умолчанию: false
-
-Режим "только чтение". Если включить этот режим, OSD не будет писать ничего
-на диск. Может быть полезно в целях восстановления.
-
-## no_recovery
-
-- Тип: булево (да/нет)
-- Значение по умолчанию: false
-- Можно менять на лету: да
-
-Отключить автоматическое фоновое восстановление объектов. Обратите внимание,
-что эта опция не отключает восстановление объектов, происходящее при
-записи - запись всегда производится в полный набор из как минимум pg_minsize
-OSD.
-
-## no_rebalance
-
-- Тип: булево (да/нет)
-- Значение по умолчанию: false
-- Можно менять на лету: да
-
-Отключить фоновое перемещение объектов между разными OSD. Отключение
-означает, что PG, находящиеся в состоянии `has_misplaced`, будут оставлены
-в нём на неопределённый срок.
-
-## print_stats_interval
-
-- Тип: секунды
-- Значение по умолчанию: 3
-- Можно менять на лету: да
-
-Временной интервал, с которым OSD печатают простую человекочитаемую
-статистику выполнения операций в стандартный вывод.
-
-## slow_log_interval
-
-- Тип: секунды
-- Значение по умолчанию: 10
-- Можно менять на лету: да
-
-Временной интервал, с которым OSD выводят в стандартный вывод список
-медленных или зависших операций, если таковые имеются. Также время, при
-превышении которого операция считается "медленной".
-
-## inode_vanish_time
-
-- Тип: секунды
-- Значение по умолчанию: 60
-- Можно менять на лету: да
-
-Число секунд, через которое удалённые инод удаляется и из статистики OSD.
-
-## max_write_iodepth
-
-- Тип: целое число
-- Значение по умолчанию: 128
-- Можно менять на лету: да
-
-Максимальное число одновременных клиентских операций записи на один OSD.
-Операции, превышающие этот лимит, не исполняются сразу, а сохраняются во
-временной очереди.
-
-## min_flusher_count
-
-- Тип: целое число
-- Значение по умолчанию: 1
-- Можно менять на лету: да
-
-Flusher - это микро-поток (корутина), которая копирует данные из журнала в
-основную область устройства данных. Их число настраивается динамически между
-минимальным и максимальным значением. Этот параметр задаёт минимальное число.
-
-## max_flusher_count
-
-- Тип: целое число
-- Значение по умолчанию: 256
-- Можно менять на лету: да
-
-Максимальное число микро-потоков очистки журнала (см. выше min_flusher_count).
-
-## inmemory_metadata
-
-- Тип: булево (да/нет)
-- Значение по умолчанию: true
-
-Данный параметр заставляет Vitastor всегда держать область метаданных диска
-в памяти. Это нужно, чтобы избегать дополнительных операций чтения с диска
-при записи. Размер области метаданных на данный момент составляет примерно
-224 МБ на 1 ТБ данных. При включении потребление памяти снизится примерно
-на эту величину, но при этом также снизится и производительность. В будущем,
-после обновления схемы хранения метаданных, это ограничение, скорее всего,
-будет ликвидировано.
-
-## inmemory_journal
-
-- Тип: булево (да/нет)
-- Значение по умолчанию: true
-
-Данный параметр заставляет Vitastor всегда держать в памяти журналы OSD.
-Отключение параметра, опять же, снижает потребление памяти, но ухудшает
-производительность, так как для копирования данных из журнала в основную
-область устройства OSD будут вынуждены читать их обратно с диска. Выигрыш
-по памяти при этом обычно крайне низкий, так как для SSD OSD обычно
-достаточно 16- или 32-мегабайтного журнала. Однако в теории отключение
-параметра может оказаться полезным для гибридных OSD (HDD+SSD) с большими
-журналами, расположенными на быстром по сравнению с HDD устройстве.
-
-## data_io
-
-- Тип: строка
-- Значение по умолчанию: direct
-
-Режим ввода-вывода для *данных*. Одно из значений "direct", "cached" или
-"directsync", означающих O_DIRECT, O_SYNC и O_DIRECT|O_SYNC, соответственно.
-
-Выберите "cached", чтобы использовать системный кэш Linux (page cache) при
-чтении и записи. Это может улучшить скорость чтения горячих данных с
-относительно медленных дисков - HDD и, возможно, SATA SSD - но немного
-снижает производительность записи для быстрых дисков, так как кэш сам по
-себе тоже добавляет накладные расходы.
-
-Выберите "directsync", если хотите задействовать
-[immediate_commit](layout-cluster.ru.md#immediate_commit) (требующий
-включенияd disable_data_fsync) на дисках с неотключаемым кэшем. Пример таких
-дисков - Intel Optane. При этом также стоит иметь в виду, что *некоторые*
-настольные SSD (например, HP EX950) игнорируют флаг O_SYNC, делая отключение
-fsync небезопасным даже с режимом "directsync".
-
-## meta_io
-
-- Тип: строка
-- Значение по умолчанию: direct
-
-Режим ввода-вывода для *метаданных*. Одно из значений "direct", "cached" или
-"directsync".
-
-"cached" может улучшить скорость чтения, если:
-1. у вас медленные диски (HDD, SATA SSD)
-2. контрольные суммы включены
-3. параметр [inmemory_metadata](#inmemory_metadata) отключён.
-При этих условиях блоки метаданных читаются с диска при каждом запросе чтения
-для проверки контрольных сумм и их кэширование может снизить дополнительную
-нагрузку на диск. Без (3) метаданные никогда не читаются с диска после
-запуска OSD, а без (2) блоки метаданных читаются только при сбросе журнала.
-
-Если одно и то же устройство используется для данных и метаданных, режим
-ввода-вывода метаданных по умолчанию устанавливается равным [data_io](#data_io).
-
-## journal_io
-
-- Тип: строка
-- Значение по умолчанию: direct
-
-Режим ввода-вывода для *журнала*. Одно из значений "direct", "cached" или
-"directsync".
-
-Здесь "cached" может улучшить скорость чтения только недавно записанных
-данных и только если параметр [inmemory_journal](#inmemory_journal)
-отключён.
-
-Если одно и то же устройство используется для метаданных и журнала,
-режим ввода-вывода журнала по умолчанию устанавливается равным
-[meta_io](#meta_io).
-
-## journal_sector_buffer_count
-
-- Тип: целое число
-- Значение по умолчанию: 32
-
-Максимальное число буферов, разрешённых для использования под записываемые
-в журнал блоки метаданных. Единственная ситуация, в которой этот параметр
-нужно менять - это если вы включаете journal_no_same_sector_overwrites. В
-этом случае установите данный параметр, например, в 1024.
-
-## journal_no_same_sector_overwrites
-
-- Тип: булево (да/нет)
-- Значение по умолчанию: false
-
-Включайте данную опцию для SSD вроде Intel D3-S4510 и D3-S4610, которые
-ОЧЕНЬ не любят, когда ПО перезаписывает один и тот же сектор несколько раз
-подряд. Такие SSD при многократной перезаписи одного и того же сектора
-сильно замедляются - условно, с 25000 и более iops до 3000 iops. Когда
-данная опция установлена, Vitastor всегда переходит к следующему сектору
-журнала после записи вместо потенциально повторной перезаписи того же
-самого сектора.
-
-Почти все другие SSD (99% моделей) не требуют данной опции.
-
-## throttle_small_writes
-
-- Тип: булево (да/нет)
-- Значение по умолчанию: false
-- Можно менять на лету: да
-
-Разрешить мягкое ограничение скорости журналируемой записи. Полезно для
-гибридных OSD с быстрыми устройствами метаданных и медленными устройствами
-данных. Идея заключается в том, что мелкие записи в этой ситуации могут
-завершаться очень быстро, так как они изначально записываются на быстрое
-журнальное устройство (SSD). Но перемещать их потом на основное медленное
-устройство долго. Поэтому если OSD быстро примет от клиентов очень много
-мелких операций записи, он быстро заполнит свой журнал, после чего
-производительность записи резко упадёт практически до нуля. Ограничение
-скорости записи призвано решить эту проблему с помощью искусственного
-замедления операций записи на основании объёма свободного места в журнале.
-Когда эта опция включена, производительность мелких операций записи будет
-снижаться плавно, а не резко в момент окончательного заполнения журнала.
-
-## throttle_target_iops
-
-- Тип: целое число
-- Значение по умолчанию: 100
-- Можно менять на лету: да
-
-Расчётное максимальное число ограничиваемых операций в секунду при условии
-отсутствия свободного места в журнале. Устанавливайте приблизительно равным
-максимальной производительности случайной записи ваших устройств данных
-(HDD) в операциях в секунду.
-
-## throttle_target_mbs
-
-- Тип: целое число
-- Значение по умолчанию: 100
-- Можно менять на лету: да
-
-Расчётный максимальный размер в МБ/с ограничиваемых операций в секунду при
-условии отсутствия свободного места в журнале. Устанавливайте приблизительно
-равным максимальной производительности линейной записи ваших устройств
-данных (HDD).
-
-## throttle_target_parallelism
-
-- Тип: целое число
-- Значение по умолчанию: 1
-- Можно менять на лету: да
-
-Расчётный максимальный параллелизм ограничиваемых операций в секунду при
-условии отсутствия свободного места в журнале. Устанавливайте приблизительно
-равным внутреннему параллелизму ваших устройств данных (1 для HDD, 4-8
-для SSD).
-
-## throttle_threshold_us
-
-- Тип: микросекунды
-- Значение по умолчанию: 50
-- Можно менять на лету: да
-
-Минимальная применимая к ограничиваемым операциям задержка. Обычно не
-требует изменений.
-
-## osd_memlock
-
-- Тип: булево (да/нет)
-- Значение по умолчанию: false
-
-Блокировать всю память OSD с помощью mlockall, чтобы запретить её выгрузку
-в пространство подкачки. Требует достаточного значения ulimit -l (лимита
-заблокированной памяти).
-
-## auto_scrub
-
-- Тип: булево (да/нет)
-- Значение по умолчанию: false
-- Можно менять на лету: да
-
-Скраб - процесс фоновой проверки копий данных, предназначенный, чтобы
-находить и исправлять повреждённые блоки. По умолчанию эти проверки ещё не
-запускаются автоматически, так как являются новой функцией. Чтобы включить
-автоматическое планирование скрабов, установите данный параметр в true.
-
-Включённый параметр заставляет OSD автоматически планировать фоновую
-проверку чистых PG раз в `scrub_interval` (см. ниже). Вы также можете
-запустить или запланировать проверку вручную, установив значение ключа JSON
-`next_scrub` внутри ключей etcd `/pg/history/...` в UNIX-время следующей
-желаемой проверки.
-
-## no_scrub
-
-- Тип: булево (да/нет)
-- Значение по умолчанию: false
-- Можно менять на лету: да
-
-Временно отключить и остановить запущенные скрабы.
-
-## scrub_interval
-
-- Тип: строка
-- Значение по умолчанию: 30d
-- Можно менять на лету: да
-
-Интервал автоматической фоновой проверки по умолчанию для всех пулов.
-Значения без указанной единицы измерения считаются в секундах, допустимые
-символы единиц измерения в конце: 's' (секунды),
-'m' (минуты), 'h' (часы), 'd' (дни), 'M' (месяца) или 'y' (годы).
-
-## scrub_queue_depth
-
-- Тип: целое число
-- Значение по умолчанию: 1
-- Можно менять на лету: да
-
-Число параллельных операций фоновой проверки на один OSD.
-
-## scrub_sleep
-
-- Тип: миллисекунды
-- Значение по умолчанию: 0
-- Можно менять на лету: да
-
-Дополнительный интервал ожидания после фоновой проверки каждого объекта на
-одном OSD. Может использоваться для замедления скраба, если он слишком
-сильно влияет на пользовательскую нагрузку.
-
-## scrub_list_limit
-
-- Тип: целое число
-- Значение по умолчанию: 1000
-- Можно менять на лету: да
-
-Размер загружаемых за одну операцию списков объектов в процессе фоновой
-проверки.
-
-## scrub_find_best
-
-- Тип: булево (да/нет)
-- Значение по умолчанию: true
-- Можно менять на лету: да
-
-Находить и автоматически восстанавливать "лучшие версии" объектов с
-несовпадающими копиями/частями. При использовании репликации "лучшая"
-версия - версия, доступная в большем числе экземпляров, чем другие. При
-использовании кодов коррекции ошибок "лучшая" версия - это подмножество
-частей данных и чётности, полностью соответствующих друг другу.
-
-Гипотетическая ситуация, в которой вы можете захотеть отключить этот
-поиск - это если у вас 3 реплики и вы боитесь, что 2 диска из 3 могут
-незаметно и одинаково повредить данные одного и того же объекта, например,
-занулив его, и только 1 диск останется неповреждённым. В этой ситуации
-отключение этого параметра поможет вам восстановить данные! Смотрите также
-описание следующего параметра - scrub_ec_max_bruteforce.
-
-## scrub_ec_max_bruteforce
-
-- Тип: целое число
-- Значение по умолчанию: 100
-- Можно менять на лету: да
-
-Vitastor старается определить повреждённые части объектов при использовании
-EC (кодов коррекции ошибок) с более, чем 1 диском чётности, путём перебора
-всех возможных комбинаций ошибочных частей. Данное значение конфигурации
-ограничивает число перебираемых комбинаций. Вы можете попробовать поднять
-его, если используете схему кодирования EC N+K с N и K, достаточно большими
-для того, чтобы число сочетаний `C(N+K-1, K-1) = (N+K-1)! / (K-1)! / N!`
-было больше, чем стандартное значение 100.
-
-Если возможных комбинаций слишком много или если корректная комбинаций не
-определяется однозначно, объекты помечаются неконсистентными (inconsistent)
-и не восстанавливаются автоматически.
-
-При использовании репликации перебор не нужен, Vitastor просто предполагает,
-что вариант объекта с наибольшим количеством одинаковых копий корректен.
-Например, если вы используете 3 реплики и 1 из них отличается, эта 1 копия
-считается некорректной. Однако, если "лучшую" версию с числом доступных
-копий большим, чем у всех других версий, найти невозможно, то объект тоже
-маркируется неконсистентным.
-
-## recovery_tune_interval
-
-- Тип: секунды
-- Значение по умолчанию: 1
-- Можно менять на лету: да
-
-Интервал, с которым OSD пересматривает клиентскую нагрузку и нагрузку
-восстановления и автоматически подстраивает [recovery_sleep_us](#recovery_sleep_us).
-Автотюнинг (автоподстройка) отключается, если recovery_tune_interval
-устанавливается в значение 0.
-
-Автотюнинг регулирует утилизацию. Утилизация является мерой нагрузки
-и равна произведению числа операций в секунду и средней задержки
-(то есть, она может быть выше 1). Вы задаёте два уровня клиентской
-утилизации - "низкий" и "высокий" (low и high) и два соответствующих
-целевых уровня утилизации операциями восстановления. OSD рассчитывает
-желаемый уровень утилизации восстановления линейной интерполяцией от
-клиентской утилизации и подстраивает задержку операций восстановления
-так, чтобы фактическая утилизация восстановления совпадала с желаемой.
-
-Это позволяет снизить влияние восстановления и ребаланса на клиентские
-операции. Конечно, невозможно исключить такое влияние полностью, но оно
-должно становиться адекватнее. В некоторых тестах перебалансировка могла
-снижать клиентскую скорость записи с 1.5 ГБ/с до 50-100 МБ/с, а теперь, с
-настройками автотюнинга по умолчанию, она снижается только до ~1 ГБ/с.
-
-## recovery_tune_util_low
-
-- Тип: число
-- Значение по умолчанию: 0.1
-- Можно менять на лету: да
-
-Желаемая утилизация восстановления в моменты, когда клиентская нагрузка
-высокая, то есть, находится на уровне или выше recovery_tune_client_util_high.
-
-## recovery_tune_util_high
-
-- Тип: число
-- Значение по умолчанию: 1
-- Можно менять на лету: да
-
-Желаемая утилизация восстановления в моменты, когда клиентская нагрузка
-низкая, то есть, находится на уровне или ниже recovery_tune_client_util_low.
-
-## recovery_tune_client_util_low
-
-- Тип: число
-- Значение по умолчанию: 0
-- Можно менять на лету: да
-
-Клиентская утилизация, которая считается "низкой".
-
-## recovery_tune_client_util_high
-
-- Тип: число
-- Значение по умолчанию: 0.5
-- Можно менять на лету: да
-
-Клиентская утилизация, которая считается "высокой".
-
-## recovery_tune_agg_interval
-
-- Тип: целое число
-- Значение по умолчанию: 10
-- Можно менять на лету: да
-
-Число последних итераций автоподстройки для расчёта задержки как среднего
-значения. Меньшие значения параметра ускоряют отклик на изменение нагрузки,
-большие значения делают задержку стабильнее. Значение по умолчанию 10
-обычно нормальное и не требует изменений.
-
-## recovery_tune_sleep_min_us
-
-- Тип: микросекунды
-- Значение по умолчанию: 10
-- Можно менять на лету: да
-
-Минимальное возможное значение авто-подстроенного recovery_sleep_us.
-Меньшие значения заменяются на 0.
-
-## recovery_tune_sleep_cutoff_us
-
-- Тип: микросекунды
-- Значение по умолчанию: 10000000
-- Можно менять на лету: да
-
-Максимальное возможное значение авто-подстроенного recovery_sleep_us.
-Большие значения считаются случайными выбросами и игнорируются в
-усреднении.

docs/config/pool.en.md

@@ -1,430 +0,0 @@
-[Documentation](../../README.md#documentation) → [Configuration](../config.en.md) → Pool configuration
-
------
-
-[Читать на русском](pool.ru.md)
-
-# Pool configuration
-
-Pool configuration is set in etcd key `/vitastor/config/pools` in the following
-JSON format:
-
-```
-{
-  "<Numeric ID>": {
-    "name": "<name>",
-    ...other parameters...
-  }
-}
-```
-
-Pool configuration is also affected by:
-
-- [OSD Placement Tree](#placement-tree)
-- [Separate OSD settings](#osd-settings)
-
-Parameters:
-
-- [name](#name)
-- [scheme](#scheme)
-- [pg_size](#pg_size)
-- [parity_chunks](#parity_chunks)
-- [pg_minsize](#pg_minsize)
-- [pg_count](#pg_count)
-- [failure_domain](#failure_domain)
-- [level_placement](#level_placement)
-- [raw_placement](#raw_placement)
-- [max_osd_combinations](#max_osd_combinations)
-- [block_size](#block_size)
-- [bitmap_granularity](#bitmap_granularity)
-- [immediate_commit](#immediate_commit)
-- [pg_stripe_size](#pg_stripe_size)
-- [root_node](#root_node)
-- [osd_tags](#osd_tags)
-- [primary_affinity_tags](#primary_affinity_tags)
-- [scrub_interval](#scrub_interval)
-- [used_for_fs](#used_for_fs)
-
-Examples:
-
-- [Replicated Pool](#replicated-pool)
-- [Erasure-coded Pool](#erasure-coded-pool)
-
-# Placement Tree
-
-OSD placement tree is set in a separate etcd key `/vitastor/config/node_placement`
-in the following JSON format:
-
-```
-{
-  "<node name or OSD number>": {
-    "level": "<level>",
-    "parent": "<parent node name, if any>"
-  },
-  ...
-}
-```
-
-Here, if a node name is a number then it is assumed to refer to an OSD.
-Level of the OSD is always "osd" and cannot be overriden. You may only
-override parent node of the OSD which is its host by default.
-
-Non-numeric node names refer to other placement tree nodes like hosts, racks,
-datacenters and so on.
-
-Hosts of all OSDs are auto-created in the tree with level "host" and name
-equal to the host name reported by a corresponding OSD. You can refer to them
-without adding them to this JSON tree manually.
-
-Level may be "host", "osd" or refer to some other placement tree level
-from [placement_levels](monitor.en.md#placement_levels).
-
-Parent node reference is required for intermediate tree nodes.
-
-# OSD settings
-
-Separate OSD settings are set in etc keys `/vitastor/config/osd/<number>`
-in JSON format `{"<key>":<value>}`.
-
-As of now, the following settings are supported:
-
-- [reweight](#reweight)
-- [tags](#tags)
-- [noout](#noout)
-
-## reweight
-
-- Type: number, between 0 and 1
-- Default: 1
-
-Every OSD receives PGs proportional to its size. Reweight is a multiplier for
-OSD size used during PG distribution.
-
-This means an OSD configured with reweight lower than 1 receives less PGs than
-it normally would. An OSD with reweight = 0 won't store any data. You can set
-reweight to 0 to trigger rebalance and remove all data from an OSD.
-
-## tags
-
-- Type: string or array of strings
-
-Sets tag or multiple tags for this OSD. Tags can be used to group OSDs into
-subsets and then use a specific subset for pool instead of all OSDs.
-For example you can mark SSD OSDs with tag "ssd" and HDD OSDs with "hdd" and
-such tags will work as device classes.
-
-## noout
-
-- Type: boolean
-- Default: false
-
-If set to true, [osd_out_time](monitor.en.md#osd_out_time) is ignored for this
-OSD and it's never removed from data distribution by the monitor.
-
-# Pool parameters
-
-## name
-
-- Type: string
-- Required
-
-Pool name.
-
-## scheme
-
-- Type: string
-- Required
-- One of: "replicated", "xor", "ec" or "jerasure"
-
-Redundancy scheme used for data in this pool. "jerasure" is an alias for "ec",
-both use Reed-Solomon-Vandermonde codes based on ISA-L or jerasure libraries.
-Fast ISA-L based implementation is used automatically when it's available,
-slower jerasure version is used otherwise.
-
-## pg_size
-
-- Type: integer
-- Required
-
-Total number of disks for PGs of this pool - i.e., number of replicas for
-replicated pools and number of data plus parity disks for EC/XOR pools.
-
-## parity_chunks
-
-- Type: integer
-
-Number of parity chunks for EC/XOR pools. For such pools, data will be lost
-if you lose more than parity_chunks disks at once, so this parameter can be
-equally described as FTT (number of failures to tolerate).
-
-Required for EC/XOR pools, ignored for replicated pools.
-
-## pg_minsize
-
-- Type: integer
-- Required
-
-Number of available live disks for PGs of this pool to remain active.
-That is, if it becomes impossible to place PG data on at least (pg_minsize)
-OSDs, PG is deactivated for both read and write. So you know that a fresh
-write always goes to at least (pg_minsize) OSDs (disks).
-
-For example, the difference between pg_minsize 2 and 1 in a 3-way replicated
-pool (pg_size=3) is:
-- If 2 hosts go down with pg_minsize=2, the pool becomes inactive and remains
-  inactive for [osd_out_time](monitor.en.md#osd_out_time) (10 minutes). After
-  this timeout, the monitor selects replacement hosts/OSDs and the pool comes
-  up and starts to heal. Therefore, if you don't have replacement OSDs, i.e.
-  if you only have 3 hosts with OSDs and 2 of them are down, the pool remains
-  inactive until you add or return at least 1 host (or change failure_domain
-  to "osd").
-- If 2 hosts go down with pg_minsize=1, the pool only experiences a short
-  I/O pause until the monitor notices that OSDs are down (5-10 seconds with
-  the default [etcd_report_interval](osd.en.md#etcd_report_interval)). After
-  this pause, I/O resumes, but new data is temporarily written in only 1 copy.
-  Then, after osd_out_time, the monitor also selects replacement OSDs and the
-  pool starts to heal.
-
-So, pg_minsize regulates the number of failures that a pool can tolerate
-without temporary downtime for [osd_out_time](monitor.en.md#osd_out_time),
-but at a cost of slightly reduced storage reliability.
-
-FIXME: pg_minsize behaviour may be changed in the future to only make PGs
-read-only instead of deactivating them.
-
-## pg_count
-
-- Type: integer
-- Required
-
-Number of PGs for this pool. The value should be big enough for the monitor /
-LP solver to be able to optimize data placement.
-
-"Enough" is usually around 10-100 PGs per OSD, i.e. you set pg_count for pool
-to (total OSD count * 10 / pg_size). You can round it to the closest power of 2,
-because it makes it easier to reduce or increase PG count later by dividing or
-multiplying it by 2.
-
-In Vitastor, PGs are ephemeral, so you can change pool PG count anytime just
-by overwriting pool configuration in etcd. Amount of the data affected by
-rebalance will be smaller if the new PG count is a multiple of the old PG count
-or vice versa.
-
-## failure_domain
-
-- Type: string
-- Default: host
-
-Failure domain specification. Must be "host" or "osd" or refer to one of the
-placement tree levels, defined in [placement_levels](monitor.en.md#placement_levels).
-
-Two replicas, or two parts in case of EC/XOR, of the same block of data are
-never put on OSDs in the same failure domain (for example, on the same host).
-So failure domain specifies the unit which failure you are protecting yourself
-from.
-
-## level_placement
-
-- Type: string
-
-Additional failure domain rules, applied in conjuction with failure_domain.
-Must be specified in the following form:
-
-`<placement level>=<sequence of characters>, <level2>=<sequence2>, ...`
-
-Sequence should be exactly [pg_size](#pg_size) character long. Each character
-corresponds to an OSD in the PG of this pool. Equal characters mean that
-corresponding items of the PG should be placed into the same placement tree
-item at this level. Different characters mean that items should be placed into
-different items.
-
-For example, if you want a EC 4+2 pool and you want every 2 chunks to be stored
-in its own datacenter and you also want each chunk to be stored on a different
-host, you should set `level_placement` to `dc=112233 host=123456`.
-
-Or you can set `level_placement` to `dc=112233` and leave `failure_domain` empty,
-because `host` is the default `failure_domain` and it will be applied anyway.
-
-Without this rule, it may happen that 3 chunks will be stored on OSDs in the
-same datacenter, and the data will become inaccessibly if that datacenter goes
-down in this case.
-
-Of course, you should group your hosts into datacenters before applying the rule
-by setting [placement_levels](monitor.en.md#placement_levels) to something like
-`{"dc":90,"host":100,"osd":110}` and add DCs to [node_placement](#placement-tree),
-like `{"dc1":{"level":"dc"},"host1":{"parent":"dc1"},...}`.
-
-## raw_placement
-
-- Type: string
-
-Raw PG placement rules, specified in the form of a DSL (domain-specific language).
-Use only if you really know what you're doing :)
-
-DSL specification:
-
-```
-dsl := item | item ("\n" | ",") items
-item := "any" | rules
-rules := rule | rule rules
-rule := level operator arg
-level := /\w+/
-operator := "!=" | "=" | ">" | "?="
-arg := value | "(" values ")"
-values := value | value "," values
-value := item_ref | constant_id
-item_ref := /\d+/
-constant_id := /"([^"]+)"/
-```
-
-"?=" operator means "preferred". I.e. `dc ?= "meow"` means "prefer datacenter meow
-for this chunk, but put into another dc if it's unavailable".
-
-Examples:
-
-- Simple 3 replicas with failure_domain=host: `any, host!=1, host!=(1,2)`
-- EC 4+2 in 3 DC: `any, dc=1 host!=1, dc!=1, dc=3 host!=3, dc!=(1,3), dc=5 host!=5`
-- 1 replica in fixed DC + 2 in random DCs: `dc?=meow, dc!=1, dc!=(1,2)`
-
-## max_osd_combinations
-
-- Type: integer
-- Default: 10000
-
-Vitastor data placement algorithm is based on the LP solver and OSD combinations
-which are fed to it are generated ramdonly. This parameter specifies the maximum
-number of combinations to generate when optimising PG placement.
-
-This parameter usually doesn't require to be changed.
-
-## block_size
-
-- Type: integer
-- Default: 131072
-
-Block size for this pool. The value from /vitastor/config/global is used when
-unspecified. Only OSDs with matching block_size are used for each pool. If you
-want to further restrict OSDs for the pool, use [osd_tags](#osd_tags).
-
-Read more about this parameter in [Cluster-Wide Disk Layout Parameters](layout-cluster.en.md#block_size).
-
-## bitmap_granularity
-
-- Type: integer
-- Default: 4096
-
-"Sector" size of virtual disks in this pool. The value from /vitastor/config/global
-is used when unspecified. Similarly to block_size, only OSDs with matching
-bitmap_granularity are used for each pool.
-
-Read more about this parameter in [Cluster-Wide Disk Layout Parameters](layout-cluster.en.md#bitmap_granularity).
-
-## immediate_commit
-
-- Type: string, one of "all", "small" and "none"
-- Default: none
-
-Immediate commit setting for this pool. The value from /vitastor/config/global
-is used when unspecified. Similarly to block_size, only OSDs with compatible
-bitmap_granularity are used for each pool. "Compatible" means that a pool with
-non-immediate commit will use OSDs with immediate commit enabled, but not vice
-versa. I.e., pools with "none" use all OSDs, pools with "small" only use OSDs
-with "all" or "small", and pools with "all" only use OSDs with "all".
-
-Read more about this parameter in [Cluster-Wide Disk Layout Parameters](layout-cluster.en.md#immediate_commit).
-
-## pg_stripe_size
-
-- Type: integer
-- Default: 0
-
-Specifies the stripe size for this pool according to which images are split into
-different PGs. Stripe size can't be smaller than [block_size](layout-cluster.en.md#block_size)
-multiplied by (pg_size - parity_chunks) for EC/XOR pools, or 1 for replicated pools,
-and the same value is used by default.
-
-This means first `pg_stripe_size = (block_size * (pg_size-parity_chunks))` bytes
-of an image go to one PG, next `pg_stripe_size` bytes go to another PG and so on.
-
-Usually doesn't require to be changed separately from the block size.
-
-## root_node
-
-- Type: string
-
-Specifies the root node of the OSD tree to restrict this pool OSDs to.
-Referenced root node must exist in /vitastor/config/node_placement.
-
-## osd_tags
-
-- Type: string or array of strings
-
-Specifies OSD tags to restrict this pool to. If multiple tags are specified,
-only OSDs having all of these tags will be used for this pool.
-
-## primary_affinity_tags
-
-- Type: string or array of strings
-
-Specifies OSD tags to prefer putting primary OSDs in this pool to.
-Note that for EC/XOR pools Vitastor always prefers to put primary OSD on one
-of the OSDs containing a data chunk for a PG.
-
-## scrub_interval
-
-- Type: time interval (number + unit s/m/h/d/M/y)
-
-Automatic scrubbing interval for this pool. Overrides
-[global scrub_interval setting](osd.en.md#scrub_interval).
-
-## used_for_fs
-
-- Type: string
-
-If non-empty, the pool is marked as used for VitastorFS with metadata stored
-in block image (regular Vitastor volume) named as the value of this pool parameter.
-
-When a pool is marked as used for VitastorFS, regular block volume creation in it
-is disabled (vitastor-cli refuses to create images without --force) to protect
-the user from block volume and FS file ID collisions and data loss.
-
-[vitastor-nfs](../usage/nfs.ru.md), in its turn, refuses to use pools not marked
-for the corresponding FS when starting. This also implies that you can use one
-pool only for one VitastorFS.
-
-The second thing that is disabled for VitastorFS pools is reporting per-inode space
-usage statistics in etcd because a FS pool may store a very large number of files
-and statistics for them all would take a lot of space in etcd.
-
-# Examples
-
-## Replicated pool
-
-```
-{
-  "1": {
-    "name":"testpool",
-    "scheme":"replicated",
-    "pg_size":2,
-    "pg_minsize":1,
-    "pg_count":256,
-    "failure_domain":"host"
-  }
-}
-```
-
-## Erasure-coded pool
-
-```
-{
-  "2": {
-    "name":"ecpool",
-    "scheme":"ec",
-    "pg_size":3,
-    "parity_chunks":1,
-    "pg_minsize":2,
-    "pg_count":256,
-    "failure_domain":"host"
-  }
-}
-```

docs/config/pool.ru.md

@@ -1,438 +0,0 @@
-[Документация](../../README-ru.md#документация) → [Конфигурация](../config.ru.md) → Конфигурация пулов
-
------
-
-[Read in English](pool.en.md)
-
-# Конфигурация пулов
-
-Настройки пулов задаются в ключе etcd `/vitastor/config/pools` в JSON-формате:
-
-```
-{
-  "<Численный ID>": {
-    "name": "<имя>",
-    ...остальные параметры...
-  }
-}
-```
-
-На настройку пулов также влияют:
-
-- [Дерево размещения OSD](#дерево-размещения)
-- [Настройки отдельных OSD](#настройки-osd)
-
-Параметры:
-
-- [name](#name)
-- [scheme](#scheme)
-- [pg_size](#pg_size)
-- [parity_chunks](#parity_chunks)
-- [pg_minsize](#pg_minsize)
-- [pg_count](#pg_count)
-- [failure_domain](#failure_domain)
-- [level_placement](#level_placement)
-- [raw_placement](#raw_placement)
-- [max_osd_combinations](#max_osd_combinations)
-- [block_size](#block_size)
-- [bitmap_granularity](#bitmap_granularity)
-- [immediate_commit](#immediate_commit)
-- [pg_stripe_size](#pg_stripe_size)
-- [root_node](#root_node)
-- [osd_tags](#osd_tags)
-- [primary_affinity_tags](#primary_affinity_tags)
-- [scrub_interval](#scrub_interval)
-- [used_for_fs](#used_for_fs)
-
-Примеры:
-
-- [Реплицированный пул](#реплицированный-пул)
-- [Пул с кодами коррекции ошибок 2+1](#пул-с-кодами-коррекции-ошибок)
-
-# Дерево размещения
-
-Дерево размещения OSD задаётся в отдельном ключе etcd `/vitastor/config/node_placement`
-в следующем JSON-формате:
-
-```
-{
-  "<имя узла или номер OSD>": {
-    "level": "<уровень>",
-    "parent": "<имя родительского узла, если есть>"
-  },
-  ...
-}
-```
-
-Здесь, если название узла - число, считается, что это OSD. Уровень OSD
-всегда равен "osd" и не может быть переопределён. Для OSD вы можете только
-переопределить родительский узел. По умолчанию родителем OSD считается его хост.
-
-Нечисловые имена узлов относятся к другим узлам дерева OSD, таким, как хосты (серверы),
-стойки, датацентры и так далее.
-
-Хосты всех OSD автоматически создаются в дереве с уровнем "host" и именем, равным имени хоста,
-сообщаемым соответствующим OSD. Вы можете ссылаться на эти хосты, не заводя их
-в дереве вручную.
-
-Уровень может быть "host", "osd" или относиться к другому уровню размещения из
-[placement_levels](monitor.ru.md#placement_levels).
-
-Родительский узел нужен только для промежуточных узлов дерева.
-
-# Настройки OSD
-
-Настройки отдельных OSD задаются в ключах etcd `/vitastor/config/osd/<number>`
-в JSON-формате `{"<key>":<value>}`.
-
-На данный момент поддерживаются следующие настройки:
-
-- [reweight](#reweight)
-- [tags](#tags)
-- [noout](#noout)
-
-## reweight
-
-- Тип: число, от 0 до 1
-- По умолчанию: 1
-
-Каждый OSD получает число PG, пропорциональное его размеру. Reweight - это
-множитель для размера, используемый в процессе распределения PG.
-
-Это значит, что OSD, сконфигурированный с reweight меньше 1 будет получать
-меньше PG, чем обычно. OSD с reweight, равным 0, не будет участвовать в
-хранении данных вообще. Вы можете установить reweight в 0, чтобы убрать
-все данные с OSD.
-
-## tags
-
-- Тип: строка или массив строк
-
-Задаёт тег или набор тегов для данного OSD. Теги можно использовать, чтобы
-делить OSD на множества и потом размещать пул только на части OSD, а не на
-всех. Можно, например, пометить SSD OSD тегом "ssd", а HDD тегом "hdd", в
-этом смысле теги работают аналогично классам устройств.
-
-## noout
-
-- Тип: булево (да/нет)
-- Значение по умолчанию: false
-
-Если установлено в true, то [osd_out_time](monitor.ru.md#osd_out_time) для этого
-OSD игнорируется и OSD не удаляется из распределения данных монитором.
-
-# Параметры
-
-## name
-
-- Тип: строка
-- Обязательный
-
-Название пула.
-
-## scheme
-
-- Тип: строка
-- Обязательный
-- Возможные значения: "replicated", "xor", "ec" или "jerasure"
-
-Схема избыточности, используемая в данном пуле. "jerasure" - синоним для "ec",
-в обеих схемах используются коды Рида-Соломона-Вандермонда, реализованные на
-основе библиотек ISA-L или jerasure. Быстрая реализация на основе ISA-L
-используется автоматически, когда доступна, в противном случае используется
-более медленная jerasure-версия.
-
-## pg_size
-
-- Тип: целое число
-- Обязательный
-
-Размер PG данного пула, т.е. число реплик для реплицированных пулов или
-число дисков данных плюс дисков чётности для пулов EC/XOR.
-
-## parity_chunks
-
-- Тип: целое число
-
-Число дисков чётности для EC/XOR пулов. Иными словами, число дисков, при
-одновременной потере которых данные будут потеряны.
-
-Игнорируется для реплицированных пулов, обязательно для EC/XOR.
-
-## pg_minsize
-
-- Тип: целое число
-- Обязательный
-
-Число доступных дисков для PG данного пула, при котором PG остаются активны.
-Если становится невозможно размещать новые данные в PG как минимум на pg_minsize
-OSD, PG деактивируется на чтение и запись. Иными словами, всегда известно,
-что новые блоки данных всегда записываются как минимум на pg_minsize дисков.
-
-Для примера, разница между pg_minsize 2 и 1 в реплицированном пуле с 3 копиями
-данных (pg_size=3), проявляется следующим образом:
-- Если 2 сервера отключаются при pg_minsize=2, пул становится неактивным и
-  остаётся неактивным в течение [osd_out_time](monitor.ru.md#osd_out_time)
-  (10 минут), после чего монитор назначает другие OSD/серверы на замену, пул
-  поднимается и начинает восстанавливать недостающие копии данных. Соответственно,
-  если OSD на замену нет - то есть, если у вас всего 3 сервера с OSD и 2 из них
-  недоступны - пул так и остаётся недоступным до тех пор, пока вы не вернёте
-  или не добавите хотя бы 1 сервер (или не переключите failure_domain на "osd").
-- Если 2 сервера отключаются при pg_minsize=1, ввод-вывод лишь приостанавливается
-  на короткое время, до тех пор, пока монитор не поймёт, что OSD отключены
-  (что занимает 5-10 секунд при стандартном [etcd_report_interval](osd.ru.md#etcd_report_interval)).
-  После этого ввод-вывод восстанавливается, но новые данные временно пишутся
-  всего в 1 копии. Когда же проходит osd_out_time, монитор точно так же назначает
-  другие OSD на замену выбывшим и пул начинает восстанавливать копии данных.
-
-То есть, pg_minsize регулирует число отказов, которые пул может пережить без
-временной остановки обслуживания на [osd_out_time](monitor.ru.md#osd_out_time),
-но ценой немного пониженных гарантий надёжности.
-
-FIXME: Поведение pg_minsize может быть изменено в будущем с полной деактивации
-PG на перевод их в режим только для чтения.
-
-## pg_count
-
-- Тип: целое число
-- Обязательный
-
-Число PG для данного пула. Число должно быть достаточно большим, чтобы монитор
-мог равномерно распределить по ним данные.
-
-Обычно это означает примерно 10-100 PG на 1 OSD, т.е. pg_count можно устанавливать
-равным (общему числу OSD * 10 / pg_size). Значение можно округлить до ближайшей
-степени 2, чтобы потом было легче уменьшать или увеличивать число PG, умножая
-или деля его на 2.
-
-PG в Vitastor эферемерны, то есть вы можете менять их число в любой момент,
-просто перезаписывая конфигурацию пулов в etcd. Однако объём перемещения данных
-при этом будет минимален, если новое число PG кратно старому (или наоборот).
-
-## failure_domain
-
-- Тип: строка
-- По умолчанию: host
-
-Домен отказа для пула. Может быть равен "host" или "osd" или любому другому
-уровню дерева OSD, задаваемому в настройке [placement_levels](monitor.ru.md#placement_levels).
-
-Смысл домена отказа в том, что 2 копии, или 2 части одного блока данных в случае
-кодов коррекции ошибок, никогда не помещаются на OSD, принадлежащие одному домену отказа.
-Иными словами, домен отказа - это то, от отказа чего вы защищаете себя избыточным
-хранением.
-
-## level_placement
-
-- Тип: строка
-
-Правила дополнительных доменов отказа, применяемые вместе с failure_domain.
-Должны задаваться в следующем виде:
-
-`<уровень>=<последовательность символов>, <уровень2>=<последовательность2>, ...`
-
-Каждая `<последовательность>` должна состоять ровно из [pg_size](#pg_size) символов.
-Каждый символ соответствует одному OSD (размещению одной части PG) этого пула.
-Одинаковые символы означают, что соответствующие части размещаются в один и тот же
-узел дерева OSD на заданном `<уровне>`. Разные символы означают, что части
-размещаются в разные узлы.
-
-Например, если вы хотите сделать пул EC 4+2 и хотите поместить каждые 2 части
-данных в свой датацентр, и также вы хотите, чтобы каждая часть размещалась на
-другом хосте, то вы должны задать `level_placement` равным `dc=112233 host=123456`.
-
-Либо вы просто можете задать `level_placement` равным `dc=112233` и оставить
-`failure_domain` пустым, т.к. `host` это его значение по умолчанию и оно также
-применится автоматически.
-
-Без этого правила может получиться так, что в одном из датацентров окажется
-3 части данных одной PG и данные окажутся недоступными при временном отключении
-этого датацентра.
-
-Естественно, перед установкой правила вам нужно сгруппировать ваши хосты в
-датацентры, установив [placement_levels](monitor.ru.md#placement_levels) во что-то
-типа `{"dc":90,"host":100,"osd":110}` и добавив датацентры в [node_placement](#дерево-размещения),
-примерно так: `{"dc1":{"level":"dc"},"host1":{"parent":"dc1"},...}`.
-
-## raw_placement
-
-- Type: string
-
-Низкоуровневые правила генерации PG в форме DSL (доменно-специфичного языка).
-Используйте, только если действительно знаете, зачем вам это надо :)
-
-Спецификация DSL:
-
-```
-dsl := item | item ("\n" | ",") items
-item := "any" | rules
-rules := rule | rule rules
-rule := level operator arg
-level := /\w+/
-operator := "!=" | "=" | ">" | "?="
-arg := value | "(" values ")"
-values := value | value "," values
-value := item_ref | constant_id
-item_ref := /\d+/
-constant_id := /"([^"]+)"/
-```
-
-Оператор "?=" означает "предпочитаемый". Т.е. `dc ?= "meow"` означает "предпочитать
-датацентр meow для этой части данных, но разместить её в другом датацентре, если
-meow недоступен".
-
-Примеры:
-
-- Простые 3 реплики с failure_domain=host: `any, host!=1, host!=(1,2)`
-- EC 4+2 в 3 датацентрах: `any, dc=1 host!=1, dc!=1, dc=3 host!=3, dc!=(1,3), dc=5 host!=5`
-- 1 копия в фиксированном ДЦ + 2 в других ДЦ: `dc?=meow, dc!=1, dc!=(1,2)`
-
-## max_osd_combinations
-
-- Тип: целое число
-- По умолчанию: 10000
-
-Алгоритм распределения данных Vitastor основан на решателе задачи линейного
-программирования. При этом для снижения сложности задачи возможные комбинации OSD
-генерируются случайно и ограничиваются количеством, равным значению этого параметра.
-
-Обычно данный параметр не требует изменений.
-
-## block_size
-
-- Тип: целое число
-- По умолчанию: 131072
-
-Размер блока для данного пула. Если не задан, используется значение из
-/vitastor/config/global. Если в вашем кластере есть OSD с разными размерами
-блока, пул будет использовать только OSD с размером блока, равным размеру блока
-пула. Если вы хотите сильнее ограничить набор используемых для пула OSD -
-используйте [osd_tags](#osd_tags).
-
-О самом параметре читайте в разделе [Дисковые параметры уровня кластера](layout-cluster.ru.md#block_size).
-
-## bitmap_granularity
-
-- Тип: целое число
-- По умолчанию: 4096
-
-Размер "сектора" виртуальных дисков в данном пуле. Если не задан, используется
-значение из /vitastor/config/global. Аналогично block_size, каждый пул будет
-использовать только OSD с совпадающей с пулом настройкой bitmap_granularity.
-
-О самом параметре читайте в разделе [Дисковые параметры уровня кластера](layout-cluster.ru.md#bitmap_granularity).
-
-## immediate_commit
-
-- Тип: строка "all", "small" или "none"
-- По умолчанию: none
-
-Настройка мгновенного коммита для данного пула. Если не задана, используется
-значение из /vitastor/config/global. Аналогично block_size, каждый пул будет
-использовать только OSD с *совместимыми* настройками immediate_commit.
-"Совместимыми" означает, что пул с отключенным мгновенным коммитом будет
-использовать OSD с включённым мгновенным коммитом, но не наоборот. То есть,
-пул со значением "none" будет использовать все OSD, пул со "small" будет
-использовать OSD с "all" или "small", а пул с "all" будет использовать только
-OSD с "all".
-
-О самом параметре читайте в разделе [Дисковые параметры уровня кластера](layout-cluster.ru.md#immediate_commit).
-
-## pg_stripe_size
-
-- Тип: целое число
-- По умолчанию: 0
-
-Данный параметр задаёт размер полосы "нарезки" образов на PG. Размер полосы не может
-быть меньше, чем [block_size](#block_size), умноженный на
-(pg_size - parity_chunks) для EC-пулов или 1 для реплицированных пулов. То же
-значение используется по умолчанию.
-
-Это означает, что по умолчанию первые `pg_stripe_size = (block_size * (pg_size-parity_chunks))` байт
-образа помещаются в одну PG, следующие `pg_stripe_size` байт помещаются в другую
-и т.п.
-
-Данный параметр обычно тоже не требует изменений.
-
-## root_node
-
-- Тип: строка
-
-Корневой узел дерева OSD для ограничения OSD, выбираемых для пула. Задаваемый
-узел должен быть предварительно задан в /vitastor/config/node_placement.
-
-## osd_tags
-
-- Тип: строка или массив строк
-
-Теги OSD для ограничения OSD, выбираемых для пула. Если задаётся несколько тегов
-массивом, то выбираются только OSD, у которых есть все эти теги.
-
-## primary_affinity_tags
-
-- Тип: строка или массив строк
-
-Теги OSD, по которым должны выбираться OSD, предпочитаемые в качестве первичных
-для PG этого пула. Имейте в виду, что для EC-пулов Vitastor также всегда
-предпочитает помещать первичный OSD на один из OSD с данными, а не с чётностью.
-
-## scrub_interval
-
-- Тип: временной интервал (число + единица измерения s/m/h/d/M/y)
-
-Интервал скраба, то есть, автоматической фоновой проверки данных для данного пула.
-Переопределяет [глобальную настройку scrub_interval](osd.ru.md#scrub_interval).
-
-## used_for_fs
-
-- Type: string
-
-Если непусто, пул помечается как используемый для файловой системы VitastorFS с
-метаданными, хранимыми в блочном образе Vitastor с именем, равным значению
-этого параметра.
-
-Когда пул помечается как используемый для VitastorFS, создание обычных блочных
-образов в нём отключается (vitastor-cli отказывается создавать образы без --force),
-чтобы защитить пользователя от коллизий ID файлов и блочных образов и, таким
-образом, от потери данных.
-
-[vitastor-nfs](../usage/nfs.ru.md), в свою очередь, при запуске отказывается
-использовать для ФС пулы, не выделенные для неё. Это также означает, что один
-пул может использоваться только для одной VitastorFS.
-
-Также для ФС-пулов отключается передача статистики в etcd по отдельным инодам,
-так как ФС-пул может содержать очень много файлов и статистика по ним всем
-заняла бы очень много места в etcd.
-
-# Примеры
-
-## Реплицированный пул
-
-```
-{
-  "1": {
-    "name":"testpool",
-    "scheme":"replicated",
-    "pg_size":2,
-    "pg_minsize":1,
-    "pg_count":256,
-    "failure_domain":"host"
-  }
-}
-```
-
-## Пул с кодами коррекции ошибок
-
-```
-{
-  "2": {
-    "name":"ecpool",
-    "scheme":"ec",
-    "pg_size":3,
-    "parity_chunks":1,
-    "pg_minsize":2,
-    "pg_count":256,
-    "failure_domain":"host"
-  }
-}
-```

docs/config/src/client.en.md

@@ -1,4 +0,0 @@
-# Client Parameters
-
-These parameters apply only to Vitastor clients (QEMU, fio, NBD and so on) and
-affect their interaction with the cluster.

docs/config/src/client.ru.md

@@ -1,4 +0,0 @@
-# Параметры клиентского кода
-
-Данные параметры применяются только к клиентам Vitastor (QEMU, fio, NBD и т.п.) и
-затрагивают логику их работы с кластером.

docs/config/src/client.yml

@@ -1,255 +0,0 @@
-- name: client_iothread_count
-  type: int
-  default: 0
-  online: false
-  info: |
-    Number of separate threads for handling TCP network I/O at client library
-    side. Enabling 4 threads usually allows to increase peak performance of each
-    client from approx. 2-3 to 7-8 GByte/s linear read/write and from approx.
-    100-150 to 400 thousand iops, but at the same time it increases latency.
-    Latency increase depends on CPU: with CPU power saving disabled latency
-    only increases by ~10 us (equivalent to Q=1 iops decrease from 10500 to 9500),
-    with CPU power saving enabled it may be as high as 500 us (equivalent to Q=1
-    iops decrease from 2000 to 1000). RDMA isn't affected by this option.
-
-    It's recommended to enable client I/O threads if you don't use RDMA and want
-    to increase peak client performance.
-  info_ru: |
-    Число отдельных потоков для обработки ввода-вывода через TCP сеть на стороне
-    клиентской библиотеки. Включение 4 потоков обычно позволяет поднять пиковую
-    производительность каждого клиента примерно с 2-3 до 7-8 Гбайт/с линейного
-    чтения/записи и примерно с 100-150 до 400 тысяч операций ввода-вывода в
-    секунду, но ухудшает задержку. Увеличение задержки зависит от процессора:
-    при отключённом энергосбережении CPU это всего ~10 микросекунд (равносильно
-    падению iops с Q=1 с 10500 до 9500), а при включённом это может быть
-    и 500 микросекунд (равносильно падению iops с Q=1 с 2000 до 1000). На работу
-    RDMA данная опция не влияет.
-
-    Рекомендуется включать клиентские потоки ввода-вывода, если вы не используете
-    RDMA и хотите повысить пиковую производительность клиентов.
-- name: client_retry_interval
-  type: ms
-  min: 10
-  default: 50
-  online: true
-  info: |
-    Retry time for I/O requests failed due to inactive PGs or network
-    connectivity errors.
-  info_ru: |
-    Время повтора запросов ввода-вывода, неудачных из-за неактивных PG или
-    ошибок сети.
-- name: client_eio_retry_interval
-  type: ms
-  default: 1000
-  online: true
-  info: |
-    Retry time for I/O requests failed due to data corruption or unfinished
-    EC object deletions (has_incomplete PG state). 0 disables such retries
-    and clients are not blocked and just get EIO error code instead.
-  info_ru: |
-    Время повтора запросов ввода-вывода, неудачных из-за повреждения данных
-    или незавершённых удалений EC-объектов (состояния PG has_incomplete).
-    0 отключает повторы таких запросов и клиенты не блокируются, а вместо
-    этого просто получают код ошибки EIO.
-- name: client_retry_enospc
-  type: bool
-  default: true
-  online: true
-  info: |
-    Retry writes on out of space errors to wait until some space is freed on
-    OSDs.
-  info_ru: |
-    Повторять запросы записи, завершившиеся с ошибками нехватки места, т.е.
-    ожидать, пока на OSD не освободится место.
-- name: client_max_dirty_bytes
-  type: int
-  default: 33554432
-  online: true
-  info: |
-    Without [immediate_commit](layout-cluster.en.md#immediate_commit)=all this parameter sets the limit of "dirty"
-    (not committed by fsync) data allowed by the client before forcing an
-    additional fsync and committing the data. Also note that the client always
-    holds a copy of uncommitted data in memory so this setting also affects
-    RAM usage of clients.
-  info_ru: |
-    При работе без [immediate_commit](layout-cluster.ru.md#immediate_commit)=all - это лимит объёма "грязных" (не
-    зафиксированных fsync-ом) данных, при достижении которого клиент будет
-    принудительно вызывать fsync и фиксировать данные. Также стоит иметь в виду,
-    что в этом случае до момента fsync клиент хранит копию незафиксированных
-    данных в памяти, то есть, настройка влияет на потребление памяти клиентами.
-- name: client_max_dirty_ops
-  type: int
-  default: 1024
-  online: true
-  info: |
-    Same as client_max_dirty_bytes, but instead of total size, limits the number
-    of uncommitted write operations.
-  info_ru: |
-    Аналогично client_max_dirty_bytes, но ограничивает количество
-    незафиксированных операций записи вместо их общего объёма.
-- name: client_enable_writeback
-  type: bool
-  default: false
-  online: true
-  info: |
-    This parameter enables client-side write buffering. This means that write
-    requests are accumulated in memory for a short time before being sent to
-    a Vitastor cluster which allows to send them in parallel and increase
-    performance of some applications. Writes are buffered until client forces
-    a flush with fsync() or until the amount of buffered writes exceeds the
-    limit.
-
-    Write buffering significantly increases performance of some applications,
-    for example, CrystalDiskMark under Windows (LOL :-D), but also any other
-    applications if they do writes in one of two non-optimal ways: either if
-    they do a lot of small (4 kb or so) sequential writes, or if they do a lot
-    of small random writes, but without any parallelism or asynchrony, and also
-    without calling fsync().
-
-    With write buffering enabled, you can expect around 22000 T1Q1 random write
-    iops in QEMU more or less regardless of the quality of your SSDs, and this
-    number is in fact bound by QEMU itself rather than Vitastor (check it
-    yourself by adding a "driver=null-co" disk in QEMU). Without write
-    buffering, the current record is 9900 iops, but the number is usually
-    even lower with non-ideal hardware, for example, it may be 5000 iops.
-
-    Even when this parameter is enabled, write buffering isn't enabled until
-    the client explicitly allows it, because enabling it without the client
-    being aware of the fact that his writes may be buffered may lead to data
-    loss. Because of this, older versions of clients don't support write
-    buffering at all, newer versions of the QEMU driver allow write buffering
-    only if it's enabled in disk settings with `-blockdev cache.direct=false`,
-    and newer versions of FIO only allow write buffering if you don't specify
-    `-direct=1`. NBD and NFS drivers allow write buffering by default.
-
-    You can overcome this restriction too with the `client_writeback_allowed`
-    parameter, but you shouldn't do that unless you **really** know what you
-    are doing.
-  info_ru: |
-    Данный параметр разрешает включать буферизацию записи в памяти. Буферизация
-    означает, что операции записи отправляются на кластер Vitastor не сразу, а
-    могут небольшое время накапливаться в памяти и сбрасываться сразу пакетами,
-    до тех пор, пока либо не будет превышен лимит неотправленных записей, либо
-    пока клиент не вызовет fsync.
-
-    Буферизация значительно повышает производительность некоторых приложений,
-    например, CrystalDiskMark в Windows (ха-ха :-D), но также и любых других,
-    которые пишут на диск неоптимально: либо последовательно, но мелкими блоками
-    (например, по 4 кб), либо случайно, но без параллелизма и без fsync - то
-    есть, например, отправляя 128 операций записи в разные места диска, но не
-    все сразу с помощью асинхронного I/O, а по одной.
-
-    В QEMU с буферизацией записи можно ожидать показателя примерно 22000
-    операций случайной записи в секунду в 1 поток и с глубиной очереди 1 (T1Q1)
-    без fsync, почти вне зависимости от того, насколько хороши ваши диски - эта
-    цифра упирается в сам QEMU. Без буферизации рекорд пока что - 9900 операций
-    в секунду, но на железе похуже может быть и поменьше, например, 5000 операций
-    в секунду.
-
-    При этом, даже если данный параметр включён, буферизация не включается, если
-    явно не разрешена клиентом, т.к. если клиент не знает, что запросы записи
-    буферизуются, это может приводить к потере данных. Поэтому в старых версиях
-    клиентских драйверов буферизация записи не включается вообще, в новых
-    версиях QEMU-драйвера включается, только если разрешена опцией диска
-    `-blockdev cache.direct=false`, а в fio - только если нет опции `-direct=1`.
-    В NBD и NFS драйверах буферизация записи разрешена по умолчанию.
-
-    Можно обойти и это ограничение с помощью параметра `client_writeback_allowed`,
-    но делать так не надо, если только вы не уверены в том, что делаете, на все
-    100%. :-)
-- name: client_max_buffered_bytes
-  type: int
-  default: 33554432
-  online: true
-  info: |
-    Maximum total size of buffered writes which triggers write-back when reached.
-  info_ru: |
-    Максимальный общий размер буферизованных записей, при достижении которого
-    начинается процесс сброса данных на сервер.
-- name: client_max_buffered_ops
-  type: int
-  default: 1024
-  online: true
-  info: |
-    Maximum number of buffered writes which triggers write-back when reached.
-    Multiple consecutive modified data regions are counted as 1 write here.
-  info_ru: |
-    Максимальное количество буферизованных записей, при достижении которого
-    начинается процесс сброса данных на сервер. При этом несколько
-    последовательных изменённых областей здесь считаются 1 записью.
-- name: client_max_writeback_iodepth
-  type: int
-  default: 256
-  online: true
-  info: |
-    Maximum number of parallel writes when flushing buffered data to the server.
-  info_ru: |
-    Максимальное число параллельных операций записи при сбросе буферов на сервер.
-- name: nbd_timeout
-  type: sec
-  default: 300
-  online: false
-  info: |
-    Timeout for I/O operations for [NBD](../usage/nbd.en.md). If an operation
-    executes for longer than this timeout, including when your cluster is just
-    temporarily down for more than timeout, the NBD device will detach by itself
-    (and possibly break the mounted file system).
-
-    You can set timeout to 0 to never detach, but in that case you won't be
-    able to remove the kernel device at all if the NBD process dies - you'll have
-    to reboot the host.
-  info_ru: |
-    Таймаут для операций чтения/записи через [NBD](../usage/nbd.ru.md). Если
-    операция выполняется дольше таймаута, включая временную недоступность
-    кластера на время, большее таймаута, NBD-устройство отключится само собой
-    (и, возможно, сломает примонтированную ФС).
-
-    Вы можете установить таймаут в 0, чтобы никогда не отключать устройство по
-    таймауту, но в этом случае вы вообще не сможете удалить устройство, если
-    процесс NBD умрёт - вам придётся перезагружать сервер.
-- name: nbd_max_devices
-  type: int
-  default: 64
-  online: false
-  info: |
-    Maximum number of NBD devices in the system. This value is passed as
-    `nbds_max` parameter for the nbd kernel module when vitastor-nbd autoloads it.
-  info_ru: |
-    Максимальное число NBD-устройств в системе. Данное значение передаётся
-    модулю ядра nbd как параметр `nbds_max`, когда его загружает vitastor-nbd.
-- name: nbd_max_part
-  type: int
-  default: 3
-  online: false
-  info: |
-    Maximum number of partitions per NBD device. This value is passed as
-    `max_part` parameter for the nbd kernel module when vitastor-nbd autoloads it.
-    Note that (nbds_max)*(1+max_part) usually can't exceed 256.
-  info_ru: |
-    Максимальное число разделов на одном NBD-устройстве. Данное значение передаётся
-    модулю ядра nbd как параметр `max_part`, когда его загружает vitastor-nbd.
-    Имейте в виду, что (nbds_max)*(1+max_part) обычно не может превышать 256.
-- name: osd_nearfull_ratio
-  type: float
-  default: 0.95
-  online: true
-  info: |
-    Ratio of used space on OSD to treat it as "almost full" in vitastor-cli status output.
-
-    Remember that some client writes may hang or complete with an error if even
-    just one OSD becomes 100 % full!
-
-    However, unlike in Ceph, 100 % full Vitastor OSDs don't crash (in Ceph they're
-    unable to start at all), so you'll be able to recover from "out of space" errors
-    without destroying and recreating OSDs.
-  info_ru: |
-    Доля занятого места на OSD, начиная с которой он считается "почти заполненным" в
-    выводе vitastor-cli status.
-
-    Помните, что часть клиентских запросов может зависнуть или завершиться с ошибкой,
-    если на 100 % заполнится хотя бы 1 OSD!
-
-    Однако, в отличие от Ceph, заполненные на 100 % OSD Vitastor не падают (в Ceph
-    заполненные на 100% OSD вообще не могут стартовать), так что вы сможете
-    восстановить работу кластера после ошибок отсутствия свободного места
-    без уничтожения и пересоздания OSD.

docs/config/src/common.en.md

@@ -1,3 +0,0 @@
-# Common Parameters
-
-These are the most common parameters which apply to all components of Vitastor.

docs/config/src/common.ru.md

@@ -1,3 +0,0 @@
-# Общие параметры
-
-Это наиболее общие параметры, используемые всеми компонентами Vitastor.

docs/config/src/common.yml

@@ -1,44 +0,0 @@
-- name: config_path
-  type: string
-  default: "/etc/vitastor/vitastor.conf"
-  info: |
-    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.
-  info_ru: |
-    Путь к файлу конфигурации в формате JSON. Файл конфигурации необязателен,
-    без него Vitastor тоже будет работать, если переданы необходимые параметры.
-- name: etcd_address
-  type: string or array of strings
-  type_ru: строка или массив строк
-  online: true
-  info: |
-    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 connection endpoints can be changed online by updating global
-    configuration in etcd itself - this allows to switch the cluster to new
-    etcd addresses without downtime.
-  info_ru: |
-    Адрес(а) подключения к etcd. Несколько адресов могут разделяться запятой
-    или указываться в виде JSON-массива `["10.0.115.10:2379/v3","10.0.115.11:2379/v3"]`.
-
-    Адреса подключения к etcd можно поменять на лету, обновив конфигурацию в
-    самом etcd - это позволяет переключить кластер на новые etcd без остановки.
-- name: etcd_prefix
-  type: string
-  default: "/vitastor"
-  info: |
-    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.
-  info_ru: |
-    Префикс для ключей etcd, которые использует Vitastor. Вы можете задать другой
-    префикс, например, чтобы запустить несколько кластеров Vitastor с одним
-    кластером etcd.
-- name: log_level
-  type: int
-  default: 0
-  online: true
-  info: Log level. Raise if you want more verbose output.
-  info_ru: Уровень логгирования. Повысьте, если хотите более подробный вывод.

docs/config/src/include.js

@@ -1,145 +0,0 @@
-#!/usr/bin/nodejs
-
-const fsp = require('fs').promises;
-
-run(process.argv).catch(console.error);
-
-async function run(argv)
-{
-    if (argv.length < 3)
-    {
-        console.log('Markdown preprocessor\nUSAGE: ./include.js file.md');
-        return;
-    }
-    const index_file = await fsp.realpath(argv[2]);
-    const re = /(\{\{[\s\S]*?\}\}|\[[^\]]+\]\([^\)]+\)|(?:^|\n)#[^\n]+)/;
-    let text = await fsp.readFile(index_file, { encoding: 'utf-8' });
-    text = text.split(re);
-    let included = {};
-    let heading = 0, heading_name = '', m;
-    for (let i = 0; i < text.length; i++)
-    {
-        if (text[i].substr(0, 2) == '{{')
-        {
-            // Inclusion
-            let incfile = text[i].substr(2, text[i].length-4);
-            let section = null;
-            let indent = heading;
-            incfile = incfile.replace(/\s*\|\s*indent\s*=\s*(-?\d+)\s*$/, (m, m1) => { indent = parseInt(m1); return ''; });
-            incfile = incfile.replace(/\s*#\s*([^#]+)$/, (m, m1) => { section = m1; return ''; });
-            let inc_heading = section;
-            incfile = rel2abs(index_file, incfile);
-            let inc = await fsp.readFile(incfile, { encoding: 'utf-8' });
-            inc = inc.trim().replace(/^[\s\S]+?\n#/, '#'); // remove until the first header
-            inc = inc.split(re);
-            const indent_str = new Array(indent+1).join('#');
-            let section_start = -1, section_end = -1;
-            for (let j = 0; j < inc.length; j++)
-            {
-                if ((m = /^(\n?)(#+\s*)([\s\S]+)$/.exec(inc[j])))
-                {
-                    if (!inc_heading)
-                    {
-                        inc_heading = m[3].trim();
-                    }
-                    if (section)
-                    {
-                        if (m[3].trim() == section)
-                            section_start = j;
-                        else if (section_start >= 0)
-                        {
-                            section_end = j;
-                            break;
-                        }
-                    }
-                    inc[j] = m[1] + indent_str + m[2] + m[3];
-                }
-                else if ((m = /^(\[[^\]]+\]\()([^\)]+)(\))$/.exec(inc[j])) && !/^https?:(\/\/)|^#/.exec(m[2]))
-                {
-                    const abs_m2 = rel2abs(incfile, m[2]);
-                    const rel_m = abs2rel(__filename, abs_m2);
-                    if (rel_m.substr(0, 9) == '../../../') // outside docs
-                        inc[j] = m[1] + 'https://git.yourcmc.ru/vitalif/vitastor/src/branch/master/'+rel2abs('docs/config/src/include.js', rel_m) + m[3];
-                    else
-                        inc[j] = m[1] + abs_m2 + m[3];
-                }
-            }
-            if (section)
-            {
-                inc = section_start >= 0 ? inc.slice(section_start, section_end < 0 ? inc.length : section_end) : [];
-            }
-            if (inc.length)
-            {
-                if (!inc_heading)
-                    inc_heading = heading_name||'';
-                included[incfile+(section ? '#'+section : '')] = '#'+inc_heading.toLowerCase().replace(/\P{L}+/ug, '-').replace(/^-|-$/g, '');
-                inc[0] = inc[0].replace(/^\s+/, '');
-                inc[inc.length-1] = inc[inc.length-1].replace(/\s+$/, '');
-            }
-            text.splice(i, 1, ...inc);
-            i = i + inc.length - 1;
-        }
-        else if ((m = /^\n?(#+)\s*([\s\S]+)$/.exec(text[i])))
-        {
-            // Heading
-            heading = m[1].length;
-            heading_name = m[2].trim();
-        }
-    }
-    for (let i = 0; i < text.length; i++)
-    {
-        if ((m = /^(\[[^\]]+\]\()([^\)]+)(\))$/.exec(text[i])) && !/^https?:(\/\/)|^#/.exec(m[2]))
-        {
-            const p = m[2].indexOf('#');
-            if (included[m[2]])
-            {
-                text[i] = m[1]+included[m[2]]+m[3];
-            }
-            else if (p >= 0 && included[m[2].substr(0, p)])
-            {
-                text[i] = m[1]+m[2].substr(p)+m[3];
-            }
-        }
-    }
-    console.log(text.join(''));
-}
-
-function rel2abs(ref, rel)
-{
-    rel = [ ...ref.replace(/^(.*)\/[^\/]+$/, '$1').split(/\/+/), ...rel.split(/\/+/) ];
-    return killdots(rel).join('/');
-}
-
-function abs2rel(ref, abs)
-{
-    ref = ref.split(/\/+/);
-    abs = abs.split(/\/+/);
-    while (ref.length > 1 && ref[0] == abs[0])
-    {
-        ref.shift();
-        abs.shift();
-    }
-    for (let i = 1; i < ref.length; i++)
-    {
-        abs.unshift('..');
-    }
-    return killdots(abs).join('/');
-}
-
-function killdots(rel)
-{
-    for (let i = 0; i < rel.length; i++)
-    {
-        if (rel[i] == '.')
-        {
-            rel.splice(i, 1);
-            i--;
-        }
-        else if (i >= 1 && rel[i] == '..' && rel[i-1] != '..')
-        {
-            rel.splice(i-1, 2);
-            i -= 2;
-        }
-    }
-    return rel;
-}

docs/config/src/included.en.md

@@ -1,71 +0,0 @@
-# Vitastor
-
-{{../../../README.md#The Idea}}
-
-{{../../../README.md#Talks and presentations}}
-
-{{../../intro/features.en.md}}
-
-{{../../intro/quickstart.en.md}}
-
-{{../../intro/architecture.en.md}}
-
-## Installation
-
-{{../../installation/packages.en.md}}
-
-{{../../installation/proxmox.en.md}}
-
-{{../../installation/openstack.en.md}}
-
-{{../../installation/kubernetes.en.md}}
-
-{{../../installation/source.en.md}}
-
-{{../../config.en.md|indent=1}}
-
-{{../../config/common.en.md|indent=2}}
-
-{{../../config/network.en.md|indent=2}}
-
-{{../../config/client.en.md|indent=2}}
-
-{{../../config/layout-cluster.en.md|indent=2}}
-
-{{../../config/layout-osd.en.md|indent=2}}
-
-{{../../config/osd.en.md|indent=2}}
-
-{{../../config/monitor.en.md|indent=2}}
-
-{{../../config/pool.en.md|indent=2}}
-
-{{../../config/inode.en.md|indent=2}}
-
-## Usage
-
-{{../../usage/cli.en.md}}
-
-{{../../usage/disk.en.md}}
-
-{{../../usage/fio.en.md}}
-
-{{../../usage/nbd.en.md}}
-
-{{../../usage/qemu.en.md}}
-
-{{../../usage/nfs.en.md}}
-
-{{../../usage/admin.en.md}}
-
-## Performance
-
-{{../../performance/understanding.en.md}}
-
-{{../../performance/theoretical.en.md}}
-
-{{../../performance/comparison1.en.md}}
-
-{{../../performance/bench2.en.md}}
-
-{{../../intro/author.en.md|indent=1}}

docs/config/src/included.ru.md

@@ -1,71 +0,0 @@
-# Vitastor
-
-{{../../../README-ru.md#Идея|indent=0}}
-
-{{../../../README-ru.md#Презентации и записи докладов|indent=0}}
-
-{{../../intro/features.ru.md}}
-
-{{../../intro/quickstart.ru.md}}
-
-{{../../intro/architecture.ru.md}}
-
-## Установка
-
-{{../../installation/packages.ru.md}}
-
-{{../../installation/proxmox.ru.md}}
-
-{{../../installation/openstack.ru.md}}
-
-{{../../installation/kubernetes.ru.md}}
-
-{{../../installation/source.ru.md}}
-
-{{../../config.ru.md|indent=1}}
-
-{{../../config/common.ru.md|indent=2}}
-
-{{../../config/network.ru.md|indent=2}}
-
-{{../../config/client.ru.md|indent=2}}
-
-{{../../config/layout-cluster.ru.md|indent=2}}
-
-{{../../config/layout-osd.ru.md|indent=2}}
-
-{{../../config/osd.ru.md|indent=2}}
-
-{{../../config/monitor.ru.md|indent=2}}
-
-{{../../config/pool.ru.md|indent=2}}
-
-{{../../config/inode.ru.md|indent=2}}
-
-## Использование
-
-{{../../usage/cli.ru.md}}
-
-{{../../usage/disk.ru.md}}
-
-{{../../usage/fio.ru.md}}
-
-{{../../usage/nbd.ru.md}}
-
-{{../../usage/qemu.ru.md}}
-
-{{../../usage/nfs.ru.md}}
-
-{{../../usage/admin.ru.md}}
-
-## Производительность
-
-{{../../performance/understanding.ru.md}}
-
-{{../../performance/theoretical.ru.md}}
-
-{{../../performance/comparison1.ru.md}}
-
-{{../../performance/bench2.ru.md}}
-
-{{../../intro/author.ru.md|indent=1}}

docs/config/src/layout-cluster.en.md

@@ -1,14 +0,0 @@
-# Cluster-Wide Disk Layout Parameters
-
-These parameters apply to clients and OSDs, are fixed at the moment of OSD drive
-initialization and can't be changed after it without losing data.
-
-OSDs with different values of these parameters (for example, SSD and SSD+HDD
-OSDs) can coexist in one Vitastor cluster within different pools. Each pool can
-only include OSDs with identical settings of these parameters.
-
-These parameters, when set to a non-default value, must also be specified in
-etcd for clients to be aware of their values, either in /vitastor/config/global
-or in pool configuration. Pool configuration overrides the global setting.
-If the value for a pool in etcd doesn't match on-disk OSD configuration, the
-OSD will refuse to start PGs of that pool.

docs/config/src/layout-cluster.ru.md

@@ -1,14 +0,0 @@
-# Дисковые параметры уровня кластера
-
-Данные параметры используются клиентами и OSD, задаются в момент инициализации
-диска OSD и не могут быть изменены после этого без потери данных.
-
-OSD с разными значениями данных параметров (например, SSD и гибридные SSD+HDD
-OSD) могут сосуществовать в одном кластере Vitastor в разных пулах. Один пул
-может включать только OSD с одинаковыми настройками этих параметров.
-
-Данные параметры, отличаясь от значения по умолчанию, должны также быть заданы
-в etcd, чтобы клиенты могли узнать их значение, либо в глобальной конфигурации
-/vitastor/config/global, либо в настройках пулов. Настройки пула переопределяют
-глобальное значение. Если значение в настройках пула не будет соответствовать
-конфигурации OSD, OSD откажется запускать PG данного пула.

docs/config/src/layout-cluster.yml

@@ -1,161 +0,0 @@
-- name: block_size
-  type: int
-  default: 131072
-  info: |
-    Size of objects (data blocks) into which all physical and virtual drives
-    (within a pool) are subdivided in Vitastor. One of current main settings
-    in Vitastor, affects memory usage, write amplification and I/O load
-    distribution effectiveness.
-
-    Recommended default block size is 128 KB for SSD and 1 MB for HDD. In fact,
-    it's possible to use 1 MB for SSD too - it will lower memory usage, but
-    may increase average WA and reduce linear performance.
-
-    OSD memory usage is roughly (SIZE / BLOCK * 68 bytes) which is roughly
-    544 MB per 1 TB of used disk space with the default 128 KB block size.
-    With 1 MB it's 8 times lower.
-  info_ru: |
-    Размер объектов (блоков данных), на которые делятся физические и виртуальные
-    диски в Vitastor (в рамках каждого пула). Одна из ключевых на данный момент
-    настроек, влияет на потребление памяти, объём избыточной записи (write
-    amplification) и эффективность распределения нагрузки по OSD.
-
-    Рекомендуемые по умолчанию размеры блока - 128 килобайт для SSD и 1 мегабайт
-    для HDD. В принципе, для SSD можно тоже использовать блок размером 1 мегабайт,
-    это понизит использование памяти, но ухудшит распределение нагрузки и в
-    среднем увеличит WA.
-
-    Потребление памяти OSD составляет примерно (РАЗМЕР / БЛОК * 68 байт),
-    т.е. примерно 544 МБ памяти на 1 ТБ занятого места на диске при
-    стандартном 128 КБ блоке. При 1 МБ блоке памяти нужно в 8 раз меньше.
-- name: bitmap_granularity
-  type: int
-  default: 4096
-  info: |
-    Required virtual disk write alignment ("sector size"). Must be a multiple
-    of disk_alignment. It's called bitmap granularity because Vitastor tracks
-    an allocation bitmap for each object containing 2 bits per each
-    (bitmap_granularity) bytes.
-
-    Can't be smaller than the OSD data device sector.
-  info_ru: |
-    Требуемое выравнивание записи на виртуальные диски (размер их "сектора").
-    Должен быть кратен disk_alignment. Называется гранулярностью битовой карты
-    потому, что Vitastor хранит битовую карту для каждого объекта, содержащую
-    по 2 бита на каждые (bitmap_granularity) байт.
-
-    Не может быть меньше размера сектора дисков данных OSD.
-- name: immediate_commit
-  type: string
-  default: all
-  info: |
-    One of "none", "all" or "small". Global value, may be overriden [at pool level](pool.en.md#immediate_commit).
-
-    This parameter is also really important for performance.
-
-    TLDR: default "all" is optimal for server-grade SSDs with supercapacitor-based
-    power loss protection (nonvolatile write-through cache) and also for most HDDs.
-    "none" or "small" should be only selected if you use desktop SSDs without
-    capacitors or drives with slow write-back cache that can't be disabled. Check
-    immediate_commit of your OSDs in [ls-osd](../usage/cli.en.md#ls-osd).
-
-    Detailed explanation:
-
-    Desktop SSDs are very fast (100000+ iops) for simple random writes
-    without cache flush. However, they are really slow (only around 1000 iops)
-    if you try to fsync() each write, that is, if you want to guarantee that
-    each change gets actually persisted to the physical media.
-
-    Server-grade SSDs with "Advanced/Enhanced Power Loss Protection" or with
-    "Supercapacitor-based Power Loss Protection", on the other hand, are equally
-    fast with and without fsync because their cache is protected from sudden
-    power loss by a built-in supercapacitor-based "UPS".
-
-    Some software-defined storage systems always fsync each write and thus are
-    really slow when used with desktop SSDs. Vitastor, however, can also
-    efficiently utilize desktop SSDs by postponing fsync until the client calls
-    it explicitly.
-
-    This is what this parameter regulates. When it's set to "all" Vitastor
-    cluster commits each change to disks immediately and clients just
-    ignore fsyncs because they know for sure that they're unneeded. This reduces
-    the amount of network roundtrips performed by clients and improves
-    performance. So it's always better to use server grade SSDs with
-    supercapacitors even with Vitastor, especially given that they cost only
-    a bit more than desktop models.
-
-    There is also a common SATA SSD (and HDD too!) firmware bug (or feature)
-    that makes server SSDs which have supercapacitors slow with fsync. To check
-    if your SSDs are affected, compare benchmark results from `fio -name=test
-    -ioengine=libaio -direct=1 -bs=4k -rw=randwrite -iodepth=1` with and without
-    `-fsync=1`. Results should be the same. If fsync=1 result is worse you can
-    try to work around this bug by "disabling" drive write-back cache by running
-    `hdparm -W 0 /dev/sdXX` or `echo write through > /sys/block/sdXX/device/scsi_disk/*/cache_type`
-    (IMPORTANT: don't mistake it with `/sys/block/sdXX/queue/write_cache` - it's
-    unsafe to change by hand). The same may apply to newer HDDs with internal
-    SSD cache or "media-cache" - for example, a lot of Seagate EXOS drives have
-    it (they have internal SSD cache even though it's not stated in datasheets).
-
-    Setting this parameter to "all" or "small" in OSD parameters requires enabling
-    [disable_journal_fsync](layout-osd.en.md#disable_journal_fsync) and
-    [disable_meta_fsync](layout-osd.en.md#disable_meta_fsync), setting it to
-    "all" also requires enabling [disable_data_fsync](layout-osd.en.md#disable_data_fsync).
-    vitastor-disk tried to do that by default, first checking/disabling drive cache.
-    If it can't disable drive cache, OSD get initialized with "none".
-  info_ru: |
-    Одно из значений "none", "small" или "all". Глобальное значение, может быть
-    переопределено [на уровне пула](pool.ru.md#immediate_commit).
-
-    Данный параметр тоже важен для производительности.
-
-    Вкратце: значение по умолчанию "all" оптимально для всех серверных SSD с
-    суперконденсаторами и также для большинства HDD. "none" и "small" имеет смысл
-    устанавливать только при использовании SSD настольного класса без
-    суперконденсаторов или дисков с медленным неотключаемым кэшем записи.
-    Проверьте настройку immediate_commit своих OSD в выводе команды [ls-osd](../usage/cli.ru.md#ls-osd).
-
-    Модели SSD для настольных компьютеров очень быстрые (100000+ операций в
-    секунду) при простой случайной записи без сбросов кэша. Однако они очень
-    медленные (всего порядка 1000 iops), если вы пытаетесь сбрасывать кэш после
-    каждой записи, то есть, если вы пытаетесь гарантировать, что каждое
-    изменение физически записывается в энергонезависимую память.
-
-    С другой стороны, серверные SSD с конденсаторами - функцией, называемой
-    "Advanced/Enhanced Power Loss Protection" или просто "Supercapacitor-based
-    Power Loss Protection" - одинаково быстрые и со сбросом кэша, и без
-    него, потому что их кэш защищён от потери питания встроенным "источником
-    бесперебойного питания" на основе суперконденсаторов и на самом деле они
-    его никогда не сбрасывают.
-
-    Некоторые программные СХД всегда сбрасывают кэши дисков при каждой записи
-    и поэтому работают очень медленно с настольными SSD. Vitastor, однако, может
-    откладывать fsync до явного его вызова со стороны клиента и таким образом
-    эффективно утилизировать настольные SSD.
-
-    Данный параметр влияет как раз на это. Когда он установлен в значение "all",
-    кластер Vitastor мгновенно фиксирует каждое изменение на физические
-    носители и клиенты могут просто игнорировать запросы fsync, т.к. они точно
-    знают, что fsync-и не нужны. Это уменьшает число необходимых обращений к OSD
-    по сети и улучшает производительность. Поэтому даже с Vitastor лучше всегда
-    использовать только серверные модели SSD с суперконденсаторами, особенно
-    учитывая то, что стоят они ненамного дороже настольных.
-
-    Также в прошивках SATA SSD (и даже HDD!) очень часто встречается либо баг,
-    либо просто особенность логики, из-за которой серверные SSD, имеющие
-    конденсаторы и защиту от потери питания, всё равно медленно работают с
-    fsync. Чтобы понять, подвержены ли этой проблеме ваши SSD, сравните
-    результаты тестов `fio -name=test -ioengine=libaio -direct=1 -bs=4k
-    -rw=randwrite -iodepth=1` без и с опцией `-fsync=1`. Результаты должны
-    быть одинаковые. Если результат с `fsync=1` хуже, вы можете попробовать
-    обойти проблему, "отключив" кэш записи диска командой `hdparm -W 0 /dev/sdXX`
-    либо `echo write through > /sys/block/sdXX/device/scsi_disk/*/cache_type`
-    (ВАЖНО: не перепутайте с `/sys/block/sdXX/queue/write_cache` - этот параметр
-    менять руками небезопасно). Такая же проблема может встречаться и в новых
-    HDD-дисках с внутренним SSD или "медиа" кэшем - например, она встречается во
-    многих дисках Seagate EXOS (у них есть внутренний SSD-кэш, хотя это и не
-    указано в спецификациях).
-
-    Указание "all" или "small" в настройках / командной строке OSD требует
-    включения [disable_journal_fsync](layout-osd.ru.md#disable_journal_fsync) и
-    [disable_meta_fsync](layout-osd.ru.md#disable_meta_fsync), значение "all"
-    также требует включения [disable_data_fsync](layout-osd.ru.md#disable_data_fsync).

docs/config/src/layout-osd.en.md

@@ -1,4 +0,0 @@
-# OSD Disk Layout Parameters
-
-These parameters apply to OSDs, are fixed at the moment of OSD drive
-initialization and can't be changed after it without losing data.

docs/config/src/layout-osd.ru.md

@@ -1,5 +0,0 @@
-# Дисковые параметры OSD
-
-Данные параметры используются только OSD и, также как и общекластерные
-дисковые параметры, задаются в момент инициализации дисков OSD и не могут быть
-изменены после этого без потери данных.

docs/config/src/layout-osd.yml

@@ -1,276 +0,0 @@
-- name: data_device
-  type: string
-  info: |
-    Path to the block device to use for data. It's highly recommendded to use
-    stable paths for all device names: `/dev/disk/by-partuuid/xxx...` instead
-    of just `/dev/sda` or `/dev/nvme0n1` to not mess up after server restart.
-    Files can also be used instead of block devices, but this is implemented
-    only for testing purposes and not for production.
-  info_ru: |
-    Путь к диску (блочному устройству) для хранения данных. Крайне рекомендуется
-    использовать стабильные пути: `/dev/disk/by-partuuid/xxx...` вместо простых
-    `/dev/sda` или `/dev/nvme0n1`, чтобы пути не могли спутаться после
-    перезагрузки сервера. Также вместо блочных устройств можно указывать файлы,
-    но это реализовано только для тестирования, а не для боевой среды.
-- name: meta_device
-  type: string
-  info: |
-    Path to the block device to use for the metadata. Metadata must be on a fast
-    SSD or performance will suffer. If this option is skipped, `data_device` is
-    used for the metadata.
-  info_ru: |
-    Путь к диску метаданных. Метаданные должны располагаться на быстром
-    SSD-диске, иначе производительность пострадает. Если эта опция не указана,
-    для метаданных используется `data_device`.
-- name: journal_device
-  type: string
-  info: |
-    Path to the block device to use for the journal. Journal must be on a fast
-    SSD or performance will suffer. If this option is skipped, `meta_device` is
-    used for the journal, and if it's also empty, journal is put on
-    `data_device`. It's almost always fine to put metadata and journal on the
-    same device, in this case you only need to set `meta_device`.
-  info_ru: |
-    Путь к диску журнала. Журнал должен располагаться на быстром SSD-диске,
-    иначе производительность пострадает. Если эта опция не указана,
-    для журнала используется `meta_device`, если же пуста и она, журнал
-    располагается на `data_device`. Нормально располагать журнал и метаданные
-    на одном устройстве, в этом случае достаточно указать только `meta_device`.
-- name: journal_offset
-  type: int
-  default: 0
-  info: Offset on the device in bytes where the journal is stored.
-  info_ru: Смещение на устройстве в байтах, по которому располагается журнал.
-- name: journal_size
-  type: int
-  info: |
-    Journal size in bytes. By default, all available space between journal_offset
-    and data_offset, meta_offset or the end of the journal device is used.
-    Large journals aren't needed in SSD-only setups, 32 MB is always enough.
-    In SSD+HDD setups it is beneficial to use larger journals (for example, 1 GB)
-    and enable [throttle_small_writes](osd.en.md#throttle_small_writes).
-  info_ru: |
-    Размер журнала в байтах. По умолчанию для журнала используется всё доступное
-    место между journal_offset и data_offset, meta_offset или концом диска.
-    В SSD-кластерах большие журналы не нужны, достаточно 32 МБ. В гибридных
-    (SSD+HDD) кластерах осмысленно использовать больший размер журнал (например, 1 ГБ)
-    и включить [throttle_small_writes](osd.ru.md#throttle_small_writes).
-- name: meta_offset
-  type: int
-  default: 0
-  info: |
-    Offset on the device in bytes where the metadata area is stored.
-    Again, set it to something if you colocate metadata with journal or data.
-  info_ru: |
-    Смещение на устройстве в байтах, по которому располагаются метаданные.
-    Эту опцию нужно задать, если метаданные у вас хранятся на том же
-    устройстве, что данные или журнал.
-- name: data_offset
-  type: int
-  default: 0
-  info: |
-    Offset on the device in bytes where the data area is stored.
-    Again, set it to something if you colocate data with journal or metadata.
-  info_ru: |
-    Смещение на устройстве в байтах, по которому располагаются данные.
-    Эту опцию нужно задать, если данные у вас хранятся на том же
-    устройстве, что метаданные или журнал.
-- name: data_size
-  type: int
-  info: |
-    Data area size in bytes. By default, the whole data device up to the end
-    will be used for the data area, but you can restrict it if you want to use
-    a smaller part. Note that there is no option to set metadata area size -
-    it's derived from the data area size.
-  info_ru: |
-    Размер области данных в байтах. По умолчанию под данные будет использована
-    вся доступная область устройства данных до конца устройства, но вы можете
-    использовать эту опцию, чтобы ограничить её меньшим размером. Заметьте, что
-    опции размера области метаданных нет - она вычисляется из размера области
-    данных автоматически.
-- name: meta_block_size
-  type: int
-  default: 4096
-  info: |
-    Physical block size of the metadata device. 4096 for most current
-    HDDs and SSDs.
-  info_ru: |
-    Размер физического блока устройства метаданных. 4096 для большинства
-    современных SSD и HDD.
-- name: journal_block_size
-  type: int
-  default: 4096
-  info: |
-    Physical block size of the journal device. Must be a multiple of
-    `disk_alignment`. 4096 for most current HDDs and SSDs.
-  info_ru: |
-    Размер физического блока устройства журнала. Должен быть кратен
-    `disk_alignment`. 4096 для большинства современных SSD и HDD.
-- name: disable_data_fsync
-  type: bool
-  default: false
-  info: |
-    Do not issue fsyncs to the data device, i.e. do not force it to flush cache.
-    Safe ONLY if your data device has write-through cache or if write-back
-    cache is disabled. If you disable drive cache manually with `hdparm` or
-    writing to `/sys/.../scsi_disk/cache_type` then make sure that you do it
-    every time before starting Vitastor OSD (vitastor-disk does it automatically).
-    See also [immediate_commit](layout-cluster.en.md#immediate_commit)
-    for information about how to benefit from disabled cache.
-  info_ru: |
-    Не отправлять fsync-и устройству данных, т.е. не заставлять его сбрасывать кэш.
-    Безопасно, ТОЛЬКО если ваше устройство данных имеет кэш со сквозной
-    записью (write-through) или если кэш с отложенной записью (write-back) отключён.
-    Если вы отключаете кэш вручную через `hdparm` или запись в `/sys/.../scsi_disk/cache_type`,
-    то удостоверьтесь, что вы делаете это каждый раз перед запуском Vitastor OSD
-    (vitastor-disk делает это автоматически). Смотрите также опцию
-    [immediate_commit](layout-cluster.ru.md#immediate_commit) для информации о том,
-    как извлечь выгоду из отключённого кэша.
-- name: disable_meta_fsync
-  type: bool
-  default: false
-  info: |
-    Same as disable_data_fsync, but for the metadata device. If the metadata
-    device is not set or if the data device is used for the metadata the option
-    is ignored and disable_data_fsync value is used instead of it.
-  info_ru: |
-    То же, что disable_data_fsync, но для устройства метаданных. Если устройство
-    метаданных не задано или если оно равно устройству данных, значение опции
-    игнорируется и вместо него используется значение опции disable_data_fsync.
-- name: disable_journal_fsync
-  type: bool
-  default: false
-  info: |
-    Same as disable_data_fsync, but for the journal device. If the journal
-    device is not set or if the metadata device is used for the journal the
-    option is ignored and disable_meta_fsync value is used instead of it. If
-    the same device is used for data, metadata and journal the option is also
-    ignored and disable_data_fsync value is used instead of it.
-  info_ru: |
-    То же, что disable_data_fsync, но для устройства журнала. Если устройство
-    журнала не задано или если оно равно устройству метаданных, значение опции
-    игнорируется и вместо него используется значение опции disable_meta_fsync.
-    Если одно и то же устройство используется и под данные, и под журнал, и под
-    метаданные - значение опции также игнорируется и вместо него используется
-    значение опции disable_data_fsync.
-- name: disable_device_lock
-  type: bool
-  default: false
-  info: |
-    Do not lock data, metadata and journal block devices exclusively with
-    flock(). Though it's not recommended, but you can use it you want to run
-    multiple OSD with a single device and different offsets, without using
-    partitions.
-  info_ru: |
-    Не блокировать устройства данных, метаданных и журнала от открытия их
-    другими OSD с помощью flock(). Так делать не рекомендуется, но теоретически
-    вы можете это использовать, чтобы запускать несколько OSD на одном
-    устройстве с разными смещениями и без использования разделов.
-- name: disk_alignment
-  type: int
-  default: 4096
-  info: |
-    Required physical disk write alignment. Most current SSD and HDD drives
-    use 4 KB physical sectors even if they report 512 byte logical sector
-    size, so 4 KB is a good default setting.
-
-    Note, however, that physical sector size also affects WA, because with block
-    devices it's impossible to write anything smaller than a block. So, when
-    Vitastor has to write a single metadata entry that's only about 32 bytes in
-    size, it actually has to write the whole 4 KB sector.
-
-    Because of this it can actually be beneficial to use SSDs which work well
-    with 512 byte sectors and use 512 byte disk_alignment, journal_block_size
-    and meta_block_size. But at the moment, no such SSDs are known...
-
-    Clients don't need to be aware of disk_alignment, so it's not required to
-    put a modified value into etcd key /vitastor/config/global.
-  info_ru: |
-    Требуемое выравнивание записи на физические диски. Почти все современные
-    SSD и HDD диски используют 4 КБ физические секторы, даже если показывают
-    логический размер сектора 512 байт, поэтому 4 КБ - хорошее значение по
-    умолчанию.
-
-    Однако стоит понимать, что физический размер сектора тоже влияет на
-    избыточную запись (WA), потому что ничего меньше блока (сектора) на блочное
-    устройство записать невозможно. Таким образом, когда Vitastor-у нужно
-    записать на диск всего лишь одну 32-байтную запись метаданных, фактически
-    приходится перезаписывать 4 КБ сектор целиком.
-
-    Поэтому, на самом деле, может быть выгодно найти SSD, хорошо работающие с
-    меньшими, 512-байтными, блоками и использовать 512-байтные disk_alignment,
-    journal_block_size и meta_block_size. Однако на данный момент такие SSD
-    не известны...
-
-    Клиентам не обязательно знать про disk_alignment, так что помещать значение
-    этого параметра в etcd в /vitastor/config/global не нужно.
-- name: data_csum_type
-  type: string
-  default: none
-  info: |
-    Data checksum type to use. May be "crc32c" or "none". Set to "crc32c" to
-    enable data checksums.
-  info_ru: |
-    Тип используемых OSD контрольных сумм данных. Может быть "crc32c" или "none".
-    Установите в "crc32c", чтобы включить расчёт и проверку контрольных сумм данных.
-
-    Следует понимать, что контрольные суммы в зависимости от размера блока их
-    расчёта либо увеличивают потребление памяти, либо снижают производительность.
-    Подробнее смотрите в описании параметра [csum_block_size](#csum_block_size).
-- name: csum_block_size
-  type: int
-  default: 4096
-  info: |
-    Checksum calculation block size.
-
-    Must be equal or a multiple of [bitmap_granularity](layout-cluster.en.md#bitmap_granularity)
-    (which is usually 4 KB).
-
-    Checksums increase metadata size by 4 bytes per each csum_block_size of data.
-
-    Checksums are always a tradeoff:
-    1. You either sacrifice +1 GB RAM per 1 TB of data
-    2. Or you raise csum_block_size, for example, to 32k and sacrifice
-       50% random write iops due to checksum read-modify-write
-    3. Or you turn off [inmemory_metadata](osd.en.md#inmemory_metadata) and
-       sacrifice 50% random read iops due to checksum reads
-
-    All-flash clusters usually have enough RAM to use default csum_block_size,
-    which uses 1 GB RAM per 1 TB of data. HDD clusters usually don't.
-
-    Thus, recommended setups are:
-    1. All-flash, 1 GB RAM per 1 TB data: default (csum_block_size=4k)
-    2. All-flash, less RAM: csum_block_size=4k + inmemory_metadata=false
-    3. Hybrid HDD+SSD: csum_block_size=4k + inmemory_metadata=false
-    4. HDD-only, faster random read: csum_block_size=32k
-    5. HDD-only, faster random write: csum_block_size=4k +
-       inmemory_metadata=false + meta_io=cached
-
-    See also [meta_io](osd.en.md#meta_io).
-  info_ru: |
-    Размер блока расчёта контрольных сумм.
-
-    Должен быть равен или кратен [bitmap_granularity](layout-cluster.ru.md#bitmap_granularity)
-    (который обычно равен 4 КБ).
-
-    Контрольные суммы увеличивают размер метаданных на 4 байта на каждые
-    csum_block_size данных.
-
-    Контрольные суммы - это всегда компромисс:
-    1. Вы либо жертвуете потреблением +1 ГБ памяти на 1 ТБ дискового пространства
-    2. Либо вы повышаете csum_block_size до, скажем, 32k и жертвуете 50%
-       скорости случайной записи из-за цикла чтения-изменения-записи для расчёта
-       новых контрольных сумм
-    3. Либо вы отключаете [inmemory_metadata](osd.ru.md#inmemory_metadata) и
-       жертвуете 50% скорости случайного чтения из-за чтения контрольных сумм
-       с диска
-
-    Таким образом, рекомендуются следующие варианты настроек:
-    1. All-flash, 1 ГБ памяти на 1 ТБ данных: по умолчанию (csum_block_size=4k)
-    2. All-flash, меньше памяти: csum_block_size=4k + inmemory_metadata=false
-    3. Гибридные HDD+SSD: csum_block_size=4k + inmemory_metadata=false
-    4. Только HDD, быстрее случайное чтение: csum_block_size=32k
-    5. Только HDD, быстрее случайная запись: csum_block_size=4k +
-       inmemory_metadata=false + meta_io=cached
-
-    Смотрите также [meta_io](osd.ru.md#meta_io).

docs/config/src/make.js

@@ -1,126 +0,0 @@
-#!/usr/bin/nodejs
-
-const fs = require('fs');
-const yaml = require('yaml');
-
-const L = {
-    en: {
-        Documentation: 'Documentation',
-        Configuration: 'Configuration',
-        Crossref: 'Read in English',
-        toc_root: '[Documentation](../README.md#documentation)',
-        toc_intro: 'Introduction',
-        toc_installation: 'Installation',
-        toc_config: '[Configuration](../config.en.md)',
-        toc_usage: 'Usage',
-        toc_performance: 'Performance',
-        online: 'Can be changed online: yes',
-    },
-    ru: {
-        Documentation: 'Документация',
-        Configuration: 'Конфигурация',
-        Type: 'Тип',
-        Default: 'Значение по умолчанию',
-        Minimum: 'Минимальное значение',
-        Crossref: 'Читать на русском',
-        toc_root: '[Документация](../README-ru.md#документация)',
-        toc_intro: 'Введение',
-        toc_installation: 'Установка',
-        toc_config: '[Конфигурация](../config.ru.md)',
-        toc_usage: 'Использование',
-        toc_performance: 'Производительность',
-        online: 'Можно менять на лету: да',
-    },
-};
-const types = {
-    en: {
-        string: 'string',
-        bool: 'boolean',
-        int: 'integer',
-        sec: 'seconds',
-        float: 'number',
-        ms: 'milliseconds',
-        us: 'microseconds',
-    },
-    ru: {
-        string: 'строка',
-        bool: 'булево (да/нет)',
-        int: 'целое число',
-        sec: 'секунды',
-        float: 'число',
-        ms: 'миллисекунды',
-        us: 'микросекунды',
-    },
-};
-const params_files = fs.readdirSync(__dirname)
-    .filter(f => f.substr(-4) == '.yml')
-    .map(f => f.substr(0, f.length-4));
-
-for (const file of params_files)
-{
-    const cfg = yaml.parse(fs.readFileSync(__dirname+'/'+file+'.yml', { encoding: 'utf-8' }));
-    for (const lang in types)
-    {
-        let out = '\n';
-        for (const c of cfg)
-        {
-            out += `\n- [${c.name}](#${c.name})`;
-        }
-        for (const c of cfg)
-        {
-            out += `\n\n## ${c.name}\n\n`;
-            out += `- ${L[lang]['Type'] || 'Type'}: ${c["type_"+lang] || types[lang][c.type] || c.type}\n`;
-            if (c.default !== undefined)
-                out += `- ${L[lang]['Default'] || 'Default'}: ${c.default}\n`;
-            if (c.min !== undefined)
-                out += `- ${L[lang]['Minimum'] || 'Minimum'}: ${c.min}\n`;
-            if (c.online)
-                out += `- ${L[lang]['online'] || 'Can be changed online: yes'}\n`;
-            out += `\n`+(c["info_"+lang] || c["info"]).replace(/\s+$/, '');
-        }
-        const head = fs.readFileSync(__dirname+'/'+file+'.'+lang+'.md', { encoding: 'utf-8' });
-        out = head.replace(/\s+$/, '')+out+"\n";
-        fs.writeFileSync(__dirname+'/../'+file+'.'+lang+'.md', out);
-    }
-}
-
-// Add "Read in..." to all other documentation files
-
-for (const file of find_files(__dirname+'/../..', name => name.substr(-3) == '.md' && !/config\/src\//.exec(name)))
-{
-    const m = /^(?:(.*?)\/)?([^\/]+)\.([^\.]+)\.[^\.]+$/.exec(file);
-    if (!m)
-        continue;
-    const [ , subdir, filename, lang ] = m;
-    if (!L[lang])
-        continue;
-    let text = fs.readFileSync(__dirname+'/../../'+file, { encoding: 'utf-8' });
-    const title = /(^|\n)# ([^\n]+)/.exec(text)[2];
-    let read_in = Object.keys(L).filter(other => other != lang)
-        .map(other => `[${L[other].Crossref}](${filename}.${other}.md)`)
-        .join(' ')+'\n\n';
-    read_in = L[lang]['toc_root'].replace(/\.\.\//, subdir ? '../../' : '../')+' → '+
-        (subdir ? L[lang]['toc_'+subdir]+' → ' : '')+
-        title+'\n\n-----\n\n'+
-        read_in;
-    if (text.substr(0, read_in.length) != read_in)
-    {
-        fs.writeFileSync(__dirname+'/../../'+file, read_in + (text[0] == '#' ? text : text.replace(/^([\s\S]*?\n)?#/, '#')));
-    }
-}
-
-function find_files(dir, fn, subdir = '', res = [])
-{
-    for (const ent of fs.readdirSync(dir+'/'+subdir, { withFileTypes: true }))
-    {
-        if (ent.isDirectory())
-        {
-            find_files(dir, fn, subdir ? subdir+'/'+ent.name : ent.name, res);
-        }
-        else if (fn(subdir ? subdir+'/'+ent.name : ent.name, ent))
-        {
-            res.push(subdir ? subdir+'/'+ent.name : ent.name);
-        }
-    }
-    return res;
-}

docs/config/src/monitor.en.md

@@ -1,3 +0,0 @@
-# Monitor Parameters
-
-These parameters only apply to Monitors.

docs/config/src/monitor.ru.md

@@ -1,3 +0,0 @@
-# Параметры мониторов
-
-Данные параметры используются только мониторами Vitastor.

docs/config/src/monitor.yml

@@ -1,174 +0,0 @@
-- name: use_antietcd
-  type: bool
-  default: false
-  info: |
-    Enable experimental built-in etcd replacement (clustered key-value database):
-    [antietcd](https://git.yourcmc.ru/vitalif/antietcd/).
-
-    When set to true, monitor runs internal antietcd automatically if it finds
-    a network interface with an IP address matching one of addresses in the
-    `etcd_address` configuration option (in `/etc/vitastor/vitastor.conf` or in
-    the monitor command line). If there are multiple matching addresses, it also
-    checks `antietcd_port` and antietcd is started for address with matching port.
-    By default, antietcd accepts connection on the selected IP address, but it
-    can also be overridden manually in the `antietcd_ip` option.
-
-    When antietcd is started, monitor stores cluster metadata itself and exposes
-    a etcd-compatible REST API. On disk, these metadata are stored in
-    `/var/lib/vitastor/mon_2379.json.gz` (can be overridden in antietcd_data_file
-    or antietcd_data_dir options). All other antietcd parameters
-    (see [here](https://git.yourcmc.ru/vitalif/antietcd/)) except node_id,
-    cluster, cluster_key, persist_filter, stale_read can also be set in
-    Vitastor configuration with `antietcd_` prefix.
-
-    You can dump/load data to or from antietcd using Antietcd `anticli` tool:
-
-    ```
-    npm exec anticli -e http://etcd:2379/v3 get --prefix '' --no-temp > dump.json
-    npm exec anticli -e http://antietcd:2379/v3 load < dump.json
-    ```
-  info_ru: |
-    Включить экспериментальный встроенный заменитель etcd (кластерную БД ключ-значение):
-    [antietcd](https://git.yourcmc.ru/vitalif/antietcd/).
-
-    Если параметр установлен в true, монитор запускает antietcd автоматически,
-    если обнаруживает сетевой интерфейс с одним из адресов, указанных в опции
-    конфигурации `etcd_address` (в `/etc/vitastor/vitastor.conf` или в опциях
-    командной строки монитора). Если таких адресов несколько, также проверяется
-    опция `antietcd_port` и antietcd запускается для адреса с соответствующим
-    портом. По умолчанию antietcd принимает подключения по выбранному совпадающему
-    IP, но его также можно определить вручную опцией `antietcd_ip`.
-
-    При запуске antietcd монитор сам хранит центральные метаданные кластера и
-    выставляет etcd-совместимое REST API. На диске эти метаданные хранятся в файле
-    `/var/lib/vitastor/mon_2379.json.gz` (можно переопределить параметрами
-    antietcd_data_file или antietcd_data_dir). Все остальные параметры antietcd
-    (смотрите [по ссылке](https://git.yourcmc.ru/vitalif/antietcd/)), за исключением
-    node_id, cluster, cluster_key, persist_filter, stale_read также можно задавать
-    в конфигурации Vitastor с префиксом `antietcd_`.
-
-    Вы можете выгружать/загружать данные в или из antietcd с помощью его инструмента
-    `anticli`:
-
-    ```
-    npm exec anticli -e http://etcd:2379/v3 get --prefix '' --no-temp > dump.json
-    npm exec anticli -e http://antietcd:2379/v3 load < dump.json
-    ```
-- name: enable_prometheus
-  type: bool
-  default: true
-  info: |
-    Enable built-in Prometheus metrics exporter at mon_http_port (8060 by default).
-
-    Note that only the active (master) monitor exposes metrics, others return
-    HTTP 503. So you should add all monitor URLs to your Prometheus job configuration.
-
-    Grafana dashboard suitable for this exporter is here: [Vitastor-Grafana-6+.json](../../mon/scripts/Vitastor-Grafana-6+.json).
-  info_ru: |
-    Включить встроенный Prometheus-экспортер метрик на порту mon_http_port (по умолчанию 8060).
-
-    Обратите внимание, что метрики выставляет только активный (главный) монитор, остальные
-    возвращают статус HTTP 503, поэтому вам следует добавлять адреса всех мониторов
-    в задание по сбору метрик Prometheus.
-
-    Дашборд для Grafana, подходящий для этого экспортера: [Vitastor-Grafana-6+.json](../../mon/scripts/Vitastor-Grafana-6+.json).
-- name: mon_http_port
-  type: int
-  default: 8060
-  info: HTTP port for monitors to listen on (including metrics exporter)
-  info_ru: Порт, на котором мониторы принимают HTTP-соединения (в том числе для отдачи метрик)
-- name: mon_http_ip
-  type: string
-  info: IP address for monitors to listen on (all addresses by default)
-  info_ru: IP-адрес, на котором мониторы принимают HTTP-соединения (по умолчанию все адреса)
-- name: mon_https_cert
-  type: string
-  info: Path to PEM SSL certificate file for monitor to listen using HTTPS
-  info_ru: Путь к PEM-файлу SSL-сертификата для монитора, чтобы принимать соединения через HTTPS
-- name: mon_https_key
-  type: string
-  info: Path to PEM SSL private key file for monitor to listen using HTTPS
-  info_ru: Путь к PEM-файлу секретного SSL-ключа для монитора, чтобы принимать соединения через HTTPS
-- name: mon_https_client_auth
-  type: bool
-  default: false
-  info: Enable HTTPS client certificate-based authorization for monitor connections
-  info_ru: Включить в HTTPS-сервере монитора авторизацию по клиентским сертификатам
-- name: mon_https_ca
-  type: string
-  info: Path to CA certificate for client HTTPS authorization
-  info_ru: Путь к удостоверяющему сертификату для авторизации клиентских HTTPS соединений
-- name: etcd_mon_ttl
-  type: sec
-  min: 5
-  default: 1
-  info: Monitor etcd lease refresh interval in seconds
-  info_ru: Интервал обновления etcd резервации (lease) монитором
-- name: etcd_mon_timeout
-  type: ms
-  default: 1000
-  info: etcd request timeout used by monitor
-  info_ru: Таймаут выполнения запросов к etcd от монитора
-- name: etcd_mon_retries
-  type: int
-  default: 5
-  info: Maximum number of attempts for one monitor etcd request
-  info_ru: Максимальное число попыток выполнения запросов к etcd монитором
-- name: mon_change_timeout
-  type: ms
-  min: 100
-  default: 1000
-  info: Optimistic retry interval for monitor etcd modification requests
-  info_ru: Время повтора при коллизиях при запросах модификации в etcd, производимых монитором
-- name: mon_stats_timeout
-  type: ms
-  min: 100
-  default: 1000
-  info: |
-    Interval for monitor to wait before updating aggregated statistics in
-    etcd after receiving OSD statistics updates
-  info_ru: |
-    Интервал, который монитор ожидает при изменении статистики по отдельным
-    OSD перед обновлением агрегированной статистики в etcd
-- name: osd_out_time
-  type: sec
-  default: 600
-  info: |
-    Time after which a failed OSD is removed from the data distribution.
-    I.e. time which the monitor waits before attempting to restore data
-    redundancy using other OSDs.
-  info_ru: |
-    Время, через которое отключенный OSD исключается из распределения данных.
-    То есть, время, которое монитор ожидает перед попыткой переместить данные
-    на другие OSD и таким образом восстановить избыточность хранения.
-- name: placement_levels
-  type: json
-  default: '`{"host":100,"osd":101}`'
-  info: |
-    Levels for the placement tree. You can define arbitrary tree levels by
-    defining them in this parameter. The configuration parameter value should
-    contain a JSON object with level names as keys and integer priorities as
-    values.  Smaller priority means higher level in tree. For example,
-    "datacenter" should have smaller priority than "osd". "host" and "osd"
-    levels are always predefined and can't be removed. If one of them is not
-    present in the configuration, then it is defined with the default priority
-    (100 for "host", 101 for "osd").
-  info_ru: |
-    Определения уровней для дерева размещения OSD. Вы можете определять
-    произвольные уровни, помещая их в данный параметр конфигурации. Значение
-    параметра должно содержать JSON-объект, ключи которого будут являться
-    названиями уровней, а значения - целочисленными приоритетами. Меньшие
-    приоритеты соответствуют верхним уровням дерева. Например, уровень
-    "датацентр" должен иметь меньший приоритет, чем "OSD". Уровни с названиями
-    "host" и "osd" являются предопределёнными и не могут быть удалены. Если
-    один из них отсутствует в конфигурации, он доопределяется с приоритетом по
-    умолчанию (100 для уровня "host", 101 для "osd").
-- name: use_old_pg_combinator
-  type: bool
-  default: false
-  info: |
-    Use the old PG combination generator which doesn't support [level_placement](pool.en.md#level_placement)
-    and [raw_placement](pool.en.md#raw_placement) for pools which don't use this features.
-  info_ru: |
-    Использовать старый генератор комбинаций PG, не поддерживающий [level_placement](pool.ru.md#level_placement)
-    и [raw_placement](pool.ru.md#raw_placement) для пулов, которые не используют данные функции.

docs/config/src/network.en.md

@@ -1,4 +0,0 @@
-# Network Protocol Parameters
-
-These parameters apply to clients and OSDs and affect network connection logic
-between clients, OSDs and etcd.

docs/config/src/network.ru.md

@@ -1,4 +0,0 @@
-# Параметры сетевого протокола
-
-Данные параметры используются клиентами и OSD и влияют на логику сетевого
-взаимодействия между клиентами, OSD, а также etcd.

docs/config/src/network.yml

@@ -1,291 +0,0 @@
-- name: tcp_header_buffer_size
-  type: int
-  default: 65536
-  info: |
-    Size of the buffer used to read data using an additional copy. Vitastor
-    packet headers are 128 bytes, payload is always at least 4 KB, so it is
-    usually beneficial to try to read multiple packets at once even though
-    it requires to copy the data an additional time. The rest of each packet
-    is received without an additional copy. You can try to play with this
-    parameter and see how it affects random iops and linear bandwidth if you
-    want.
-  info_ru: |
-    Размер буфера для чтения данных с дополнительным копированием. Пакеты
-    Vitastor содержат 128-байтные заголовки, за которыми следуют данные размером
-    от 4 КБ и для мелких операций ввода-вывода обычно выгодно за 1 вызов читать
-    сразу несколько пакетов, даже не смотря на то, что это требует лишний раз
-    скопировать данные. Часть каждого пакета за пределами значения данного
-    параметра читается без дополнительного копирования. Вы можете попробовать
-    поменять этот параметр и посмотреть, как он влияет на производительность
-    случайного и линейного доступа.
-- name: use_sync_send_recv
-  type: bool
-  default: false
-  info: |
-    If true, synchronous send/recv syscalls are used instead of io_uring for
-    socket communication. Useless for OSDs because they require io_uring anyway,
-    but may be required for clients with old kernel versions.
-  info_ru: |
-    Если установлено в истину, то вместо io_uring для передачи данных по сети
-    будут использоваться обычные синхронные системные вызовы send/recv. Для OSD
-    это бессмысленно, так как OSD в любом случае нуждается в io_uring, но, в
-    принципе, это может применяться для клиентов со старыми версиями ядра.
-- name: use_rdma
-  type: bool
-  default: true
-  info: |
-    Try to use RDMA for communication if it's available. Disable if you don't
-    want Vitastor to use RDMA. TCP-only clients can also talk to an RDMA-enabled
-    cluster, so disabling RDMA may be needed if clients have RDMA devices,
-    but they are not connected to the cluster.
-  info_ru: |
-    Пытаться использовать RDMA для связи при наличии доступных устройств.
-    Отключите, если вы не хотите, чтобы Vitastor использовал RDMA.
-    TCP-клиенты также могут работать с RDMA-кластером, так что отключать
-    RDMA может быть нужно только если у клиентов есть RDMA-устройства,
-    но они не имеют соединения с кластером Vitastor.
-- name: rdma_device
-  type: string
-  info: |
-    RDMA device name to use for Vitastor OSD communications (for example,
-    "rocep5s0f0"). Now Vitastor supports all adapters, even ones without
-    ODP support, like Mellanox ConnectX-3 and non-Mellanox cards.
-
-    Versions up to Vitastor 1.2.0 required ODP which is only present in
-    Mellanox ConnectX >= 4. See also [rdma_odp](#rdma_odp).
-
-    Run `ibv_devinfo -v` as root to list available RDMA devices and their
-    features.
-
-    Remember that you also have to configure your network switches if you use
-    RoCE/RoCEv2, otherwise you may experience unstable performance. Refer to
-    the manual of your network vendor for details about setting up the switch
-    for RoCEv2 correctly. Usually it means setting up Lossless Ethernet with
-    PFC (Priority Flow Control) and ECN (Explicit Congestion Notification).
-  info_ru: |
-    Название RDMA-устройства для связи с Vitastor OSD (например, "rocep5s0f0").
-    Сейчас Vitastor поддерживает все модели адаптеров, включая те, у которых
-    нет поддержки ODP, то есть вы можете использовать RDMA с ConnectX-3 и
-    картами производства не Mellanox.
-
-    Версии Vitastor до 1.2.0 включительно требовали ODP, который есть только
-    на Mellanox ConnectX 4 и более новых. См. также [rdma_odp](#rdma_odp).
-
-    Запустите `ibv_devinfo -v` от имени суперпользователя, чтобы посмотреть
-    список доступных RDMA-устройств, их параметры и возможности.
-
-    Обратите внимание, что если вы используете RoCE/RoCEv2, вам также необходимо
-    правильно настроить для него коммутаторы, иначе вы можете столкнуться с
-    нестабильной производительностью. Подробную информацию о настройке
-    коммутатора для RoCEv2 ищите в документации производителя. Обычно это
-    подразумевает настройку сети без потерь на основе PFC (Priority Flow
-    Control) и ECN (Explicit Congestion Notification).
-- name: rdma_port_num
-  type: int
-  default: 1
-  info: |
-    RDMA device port number to use. Only for devices that have more than 1 port.
-    See `phys_port_cnt` in `ibv_devinfo -v` output to determine how many ports
-    your device has.
-  info_ru: |
-    Номер порта RDMA-устройства, который следует использовать. Имеет смысл
-    только для устройств, у которых более 1 порта. Чтобы узнать, сколько портов
-    у вашего адаптера, посмотрите `phys_port_cnt` в выводе команды
-    `ibv_devinfo -v`.
-- name: rdma_gid_index
-  type: int
-  default: 0
-  info: |
-    Global address identifier index of the RDMA device to use. Different GID
-    indexes may correspond to different protocols like RoCEv1, RoCEv2 and iWARP.
-    Search for "GID" in `ibv_devinfo -v` output to determine which GID index
-    you need.
-
-    **IMPORTANT:** If you want to use RoCEv2 (as recommended) then the correct
-    rdma_gid_index is usually 1 (IPv6) or 3 (IPv4).
-  info_ru: |
-    Номер глобального идентификатора адреса RDMA-устройства, который следует
-    использовать. Разным gid_index могут соответствовать разные протоколы связи:
-    RoCEv1, RoCEv2, iWARP. Чтобы понять, какой нужен вам - смотрите строчки со
-    словом "GID" в выводе команды `ibv_devinfo -v`.
-
-    **ВАЖНО:** Если вы хотите использовать RoCEv2 (как мы и рекомендуем), то
-    правильный rdma_gid_index, как правило, 1 (IPv6) или 3 (IPv4).
-- name: rdma_mtu
-  type: int
-  default: 4096
-  info: |
-    RDMA Path MTU to use. Must be 1024, 2048 or 4096. There is usually no
-    sense to change it from the default 4096.
-  info_ru: |
-    Максимальная единица передачи (Path MTU) для RDMA. Должно быть равно 1024,
-    2048 или 4096. Обычно нет смысла менять значение по умолчанию, равное 4096.
-- name: rdma_max_sge
-  type: int
-  default: 128
-  info: |
-    Maximum number of scatter/gather entries to use for RDMA. OSDs negotiate
-    the actual value when establishing connection anyway, so it's usually not
-    required to change this parameter.
-  info_ru: |
-    Максимальное число записей разделения/сборки (scatter/gather) для RDMA.
-    OSD в любом случае согласовывают реальное значение при установке соединения,
-    так что менять этот параметр обычно не нужно.
-- name: rdma_max_msg
-  type: int
-  default: 132096
-  info: Maximum size of a single RDMA send or receive operation in bytes.
-  info_ru: Максимальный размер одной RDMA-операции отправки или приёма.
-- name: rdma_max_recv
-  type: int
-  default: 16
-  info: |
-    Maximum number of RDMA receive buffers per connection (RDMA requires
-    preallocated buffers to receive data). Each buffer is `rdma_max_msg` bytes
-    in size. So this setting directly affects memory usage: a single Vitastor
-    RDMA client uses `rdma_max_recv * rdma_max_msg * OSD_COUNT` bytes of memory.
-    Default is roughly 2 MB * number of OSDs.
-  info_ru: |
-    Максимальное число буферов для RDMA-приёма данных на одно соединение
-    (RDMA требует заранее выделенных буферов для приёма данных). Каждый буфер
-    имеет размер `rdma_max_msg` байт. Таким образом, настройка прямо влияет на
-    потребление памяти - один Vitastor-клиент с RDMA использует
-    `rdma_max_recv * rdma_max_msg * ЧИСЛО_OSD` байт памяти, по умолчанию -
-    примерно 2 МБ * число OSD.
-- name: rdma_max_send
-  type: int
-  default: 8
-  info: |
-    Maximum number of outstanding RDMA send operations per connection. Should be
-    less than `rdma_max_recv` so the receiving side doesn't run out of buffers.
-    Doesn't affect memory usage - additional memory isn't allocated for send
-    operations.
-  info_ru: |
-    Максимальное число RDMA-операций отправки, отправляемых в очередь одного
-    соединения. Желательно, чтобы оно было меньше `rdma_max_recv`, чтобы
-    у принимающей стороны в процессе работы не заканчивались буферы на приём.
-    Не влияет на потребление памяти - дополнительная память на операции отправки
-    не выделяется.
-- name: rdma_odp
-  type: bool
-  default: false
-  online: false
-  info: |
-    Use RDMA with On-Demand Paging. ODP is currently only available on Mellanox
-    ConnectX-4 and newer adapters. ODP allows to not register memory explicitly
-    for RDMA adapter to be able to use it. This, in turn, allows to skip memory
-    copying during sending. One would think this should improve performance, but
-    **in reality** RDMA performance with ODP is **drastically** worse. Example
-    3-node cluster with 8 NVMe in each node and 2*25 GBit/s ConnectX-6 RDMA network
-    without ODP pushes 3950000 read iops, but only 239000 iops with ODP...
-
-    This happens because Mellanox ODP implementation seems to be based on
-    message retransmissions when the adapter doesn't know about the buffer yet -
-    it likely uses standard "RNR retransmissions" (RNR = receiver not ready)
-    which is generally slow in RDMA/RoCE networks. Here's a presentation about
-    it from ISPASS-2021 conference: https://tkygtr6.github.io/pub/ISPASS21_slides.pdf
-
-    ODP support is retained in the code just in case a good ODP implementation
-    appears one day.
-  info_ru: |
-    Использовать RDMA с On-Demand Paging. ODP - функция, доступная пока что
-    исключительно на адаптерах Mellanox ConnectX-4 и более новых. ODP позволяет
-    не регистрировать память для её использования RDMA-картой. Благодаря этому
-    можно не копировать данные при отправке их в сеть и, казалось бы, это должно
-    улучшать производительность - но **по факту** получается так, что
-    производительность только ухудшается, причём сильно. Пример - на 3-узловом
-    кластере с 8 NVMe в каждом узле и сетью 2*25 Гбит/с на чтение с RDMA без ODP
-    удаётся снять 3950000 iops, а с ODP - всего 239000 iops...
-
-    Это происходит из-за того, что реализация ODP у Mellanox неоптимальная и
-    основана на повторной передаче сообщений, когда карте не известен буфер -
-    вероятно, на стандартных "RNR retransmission" (RNR = receiver not ready).
-    А данные повторные передачи в RDMA/RoCE - всегда очень медленная штука.
-    Презентация на эту тему с конференции ISPASS-2021: https://tkygtr6.github.io/pub/ISPASS21_slides.pdf
-
-    Возможность использования ODP сохранена в коде на случай, если вдруг в один
-    прекрасный день появится хорошая реализация ODP.
-- name: peer_connect_interval
-  type: sec
-  min: 1
-  default: 5
-  online: true
-  info: Interval before attempting to reconnect to an unavailable OSD.
-  info_ru: Время ожидания перед повторной попыткой соединиться с недоступным OSD.
-- name: peer_connect_timeout
-  type: sec
-  min: 1
-  default: 5
-  online: true
-  info: Timeout for OSD connection attempts.
-  info_ru: Максимальное время ожидания попытки соединения с OSD.
-- name: osd_idle_timeout
-  type: sec
-  min: 1
-  default: 5
-  online: true
-  info: |
-    OSD connection inactivity time after which clients and other OSDs send
-    keepalive requests to check state of the connection.
-  info_ru: |
-    Время неактивности соединения с OSD, после которого клиенты или другие OSD
-    посылают запрос проверки состояния соединения.
-- name: osd_ping_timeout
-  type: sec
-  min: 1
-  default: 5
-  online: true
-  info: |
-    Maximum time to wait for OSD keepalive responses. If an OSD doesn't respond
-    within this time, the connection to it is dropped and a reconnection attempt
-    is scheduled.
-  info_ru: |
-    Максимальное время ожидания ответа на запрос проверки состояния соединения.
-    Если OSD не отвечает за это время, соединение отключается и производится
-    повторная попытка соединения.
-- name: max_etcd_attempts
-  type: int
-  default: 5
-  online: true
-  info: |
-    Maximum number of attempts for etcd requests which can't be retried
-    indefinitely.
-  info_ru: |
-    Максимальное число попыток выполнения запросов к etcd для тех запросов,
-    которые нельзя повторять бесконечно.
-- name: etcd_quick_timeout
-  type: ms
-  default: 1000
-  online: true
-  info: |
-    Timeout for etcd requests which should complete quickly, like lease refresh.
-  info_ru: |
-    Максимальное время выполнения запросов к etcd, которые должны завершаться
-    быстро, таких, как обновление резервации (lease).
-- name: etcd_slow_timeout
-  type: ms
-  default: 5000
-  online: true
-  info: Timeout for etcd requests which are allowed to wait for some time.
-  info_ru: |
-    Максимальное время выполнения запросов к etcd, для которых не обязательно
-    гарантировать быстрое выполнение.
-- name: etcd_keepalive_timeout
-  type: sec
-  default: max(30, etcd_report_interval*2)
-  online: true
-  info: |
-    Timeout for etcd connection HTTP Keep-Alive. Should be higher than
-    etcd_report_interval to guarantee that keepalive actually works.
-  info_ru: |
-    Таймаут для HTTP Keep-Alive в соединениях к etcd. Должен быть больше, чем
-    etcd_report_interval, чтобы keepalive гарантированно работал.
-- name: etcd_ws_keepalive_interval
-  type: sec
-  default: 5
-  online: true
-  info: |
-    etcd websocket ping interval required to keep the connection alive and
-    detect disconnections quickly.
-  info_ru: |
-    Интервал проверки живости вебсокет-подключений к etcd.

docs/config/src/osd.en.md

@@ -1,5 +0,0 @@
-# Runtime OSD Parameters
-
-These parameters only apply to OSDs, are not fixed at the moment of OSD drive
-initialization and can be changed - either with an OSD restart or, for some of
-them, even without restarting by updating configuration in etcd.

docs/config/src/osd.ru.md

@@ -1,6 +0,0 @@
-# Изменяемые параметры OSD
-
-Данные параметры используются только OSD, но, в отличие от дисковых параметров,
-не фиксируются в момент инициализации дисков OSD и могут быть изменены в любой
-момент с помощью перезапуска OSD, а некоторые и без перезапуска, с помощью
-изменения конфигурации в etcd.