WIP Separate data connections

2021-12-30 01:57:13 +03:00
533 changed files with 13601 additions and 87023 deletions
--- a/.gitea/workflows/buildenv.Dockerfile
+++ b/.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
--- a/.gitea/workflows/test.Dockerfile
+++ b/.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
--- a/.gitea/workflows/test.yml
+++ b/.gitea/workflows/test.yml
--- a/.gitea/workflows/tests-to-yaml.pl
+++ b/.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
 ;
    }
 }
--- a/.gitignore
+++ b/.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
--- a/CLA-en.md
+++ b/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.
--- a/CLA-ru.md
+++ b/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. Все споры, возникающие между сторонами в процессе их взаимодействия по настоящему
        договору, решаются путём переговоров. В случае невозможности урегулирования споров
        переговорным порядком стороны разрешают их в Арбитражном суде г.Москвы.
--- a/CMakeLists.txt
+++ b/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.11")
 add_subdirectory(src)
--- a/README-ru.md
+++ b/README-ru.md
@ -1,76 +1,631 @@
-# Vitastor
+## Vitastor
 [Read English version](README.md)
 ## Идея
-Вернём былую скорость кластерному блочному хранилищу!
+Я всего лишь хочу сделать качественную блочную SDS!
-Vitastor - распределённая блочная и файловая SDS (программная СХД), прямой аналог Ceph RBD и CephFS,
+Vitastor - распределённая блочная SDS, прямой аналог Ceph RBD и внутренних СХД популярных
-а также внутренних СХД популярных облачных провайдеров. Однако, в отличие от них, Vitastor
+облачных провайдеров. Однако, в отличие от них, 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)
+Так же, как и в Ceph, в Vitastor:
-  - [Архитектура](docs/intro/architecture.ru.md)
+
-  - [Автор и лицензия](docs/intro/author.ru.md)
+- Есть пулы (pools), PG, OSD, мониторы, домены отказа, дерево распределения (аналог crush-дерева).
- Установка
+- Образы делятся на блоки фиксированного размера (объекты), и эти объекты распределяются по OSD.
-  - [Пакеты](docs/installation/packages.ru.md)
+- У OSD есть журнал и метаданные и они тоже могут размещаться на отдельных быстрых дисках.
-  - [Proxmox](docs/installation/proxmox.ru.md)
+- Все операции записи тоже транзакционны. В Vitastor, правда, есть режим отложенного/ленивого fsync
-  - [OpenNebula](docs/installation/opennebula.ru.md)
+  (коммита), в котором fsync не вызывается на каждую операцию записи, что делает его более
-  - [OpenStack](docs/installation/openstack.ru.md)
+  пригодным для использования на "плохих" (десктопных) SSD. Однако все операции записи
-  - [Kubernetes CSI](docs/installation/kubernetes.ru.md)
+  в любом случае атомарны.
-  - [Сборка из исходных кодов](docs/installation/source.ru.md)
+- Клиентская библиотека тоже старается ждать восстановления после любого отказа кластера, то есть,
- Конфигурация
+  вы тоже можете перезагрузить хоть весь кластер разом, и клиенты только на время зависнут,
-  - [Обзор](docs/config.ru.md)
+  но не отключатся.
-  - Параметры
+
-    - [Общие](docs/config/common.ru.md)
+Некоторые базовые термины для тех, кто не знаком с Ceph:
-    - [Сетевые](docs/config/network.ru.md)
+
-    - [Клиентский код](docs/config/client.ru.md)
+- OSD (Object Storage Daemon) - процесс, который хранит данные на одном диске и обрабатывает
-    - [Глобальные дисковые параметры](docs/config/layout-cluster.ru.md)
+  запросы чтения/записи от клиентов.
-    - [Дисковые параметры OSD](docs/config/layout-osd.ru.md)
+- Пул (Pool) - контейнер для данных, имеющих одну и ту же схему избыточности и правила распределения по OSD.
-    - [Прочие параметры OSD](docs/config/osd.ru.md)
+- PG (Placement Group) - группа объектов, хранимых на одном и том же наборе реплик (OSD).
-    - [Параметры мониторов](docs/config/monitor.ru.md)
+  Несколько PG могут храниться на одном и том же наборе реплик, но объекты одной PG
-  - [Настройки пулов](docs/config/pool.ru.md)
+  в норме не хранятся на разных наборах OSD.
-  - [Метаданные образов в etcd](docs/config/inode.ru.md)
+- Монитор - демон, хранящий состояние кластера.
- Использование
+- Домен отказа (Failure Domain) - группа OSD, которым вы разрешаете "упасть" всем вместе.
-  - [vitastor-cli](docs/usage/cli.ru.md) (консольный интерфейс)
+  Иными словами, это группа OSD, в которые СХД не помещает разные копии одного и того же
-  - [vitastor-disk](docs/usage/disk.ru.md) (управление дисками)
+  блока данных. Например, если домен отказа - сервер, то на двух дисках одного сервера
-  - [fio](docs/usage/fio.ru.md) для тестов производительности
+  никогда не окажется 2 и более копий одного и того же блока данных, а значит, даже
-  - [NBD](docs/usage/nbd.ru.md) для монтирования ядром
+  если в этом сервере откажут все диски, это будет равносильно потере только 1 копии
-  - [QEMU и qemu-img](docs/usage/qemu.ru.md)
+  любого блока данных.
-  - [NFS](docs/usage/nfs.ru.md) кластерная файловая система и псевдо-ФС прокси
+- Дерево распределения (Placement Tree / CRUSH Tree) - иерархическая группировка OSD
-  - [Администрирование](docs/usage/admin.ru.md)
+  в узлы, которые далее можно использовать как домены отказа. То есть, диск (OSD) входит в
- Производительность
+  сервер, сервер входит в стойку, стойка входит в ряд, ряд в датацентр и т.п.
-  - [Понимание сути производительности](docs/performance/understanding.ru.md)
+
-  - [Теоретический максимум](docs/performance/theoretical.ru.md)
+Чем Vitastor отличается от Ceph:
-  - [Пример сравнения с Ceph](docs/performance/comparison1.ru.md)
+
-  - [Более новый тест Vitastor 1.3.1](docs/performance/bench2.ru.md)
+- 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.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).
+а GPL 2.0 в файле [GPL-2.0.txt](GPL-2.0.txt).
--- a/README.md
+++ b/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,
+Vitastor is a small, simple and fast clustered block storage (storage for VM drives),
-and also internal SDS's of public clouds. However, in contrast to them, Vitastor is fast
+architecturally similar to Ceph which means strong consistency, primary-replication, symmetric
-and simple at the same time. The only thing is it's slightly young :-).
+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,
+## Features
 primary-replication, symmetric clustering and automatic data distribution over any
 number of drives of any size with configurable redundancy (replication or erasure codes/XOR).
-Vitastor targets primarily SSD and SSD+HDD clusters with at least 10 Gbit/s network,
+Vitastor is currently a pre-release, a lot of features are missing and you can still expect
-supports TCP and RDMA and may achieve 4 KB read and write latency as low as ~0.1 ms
+breaking changes in the future. However, the following is implemented:
 with proper hardware which is ~10 times faster than other popular SDS's like Ceph
 or internal systems of public clouds.
-Vitastor supports QEMU, NBD, NFS protocols, OpenStack, OpenNebula, Proxmox, Kubernetes drivers.
+- Basic part: highly-available block storage with symmetric clustering and no SPOF
-More drivers may be created easily.
+- 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),
+## Architecture
  [in English](https://vitastor.io/presentation/devopsconf/devopsconf_en.html)),
  [video](https://vitastor.io/presentation/devopsconf/talk.webm)
 - Highload'2022: presentation ([in Russian](https://vitastor.io/presentation/highload/highload.html)),
  [video](https://vitastor.io/presentation/highload/talk.webm)
-## Documentation
+Similarities:
- Introduction
+- Just like Ceph, Vitastor has Pools, PGs, OSDs, Monitors, Failure Domains, Placement Tree.
-  - [Quick Start](docs/intro/quickstart.en.md)
+- Just like Ceph, Vitastor is transactional (even though there's a "lazy fsync mode" which
-  - [Features](docs/intro/features.en.md)
+  doesn't implicitly flush every operation to disks).
-  - [Architecture](docs/intro/architecture.en.md)
+- OSDs also have journal and metadata and they can also be put on separate drives.
-  - [Author and license](docs/intro/author.en.md)
+- Just like in Ceph, client library attempts to recover from any cluster failure so
- Installation
+  you can basically reboot the whole cluster and only pause, but not crash, your clients
-  - [Packages](docs/installation/packages.en.md)
+  (I consider this a bug if the client crashes in that case).
-  - [Proxmox](docs/installation/proxmox.en.md)
+
-  - [OpenNebula](docs/installation/opennebula.en.md)
+Some basic terms for people not familiar with Ceph:
-  - [OpenStack](docs/installation/openstack.en.md)
+
-  - [Kubernetes CSI](docs/installation/kubernetes.en.md)
+- OSD (Object Storage Daemon) is a process that stores data and serves read/write requests.
-  - [Building from Source](docs/installation/source.en.md)
+- PG (Placement Group) is a container for data that (normally) shares the same replicas.
- Configuration
+- Pool is a container for data that has the same redundancy scheme and placement rules.
-  - [Overview](docs/config.en.md)
+- Monitor is a separate daemon that watches cluster state and handles failures.
-  - Parameter Reference
+- Failure Domain is a group of OSDs that you allow to fail. It's "host" by default.
-    - [Common](docs/config/common.en.md)
+- Placement Tree groups OSDs in a hierarchy to later split them into Failure Domains.
-    - [Network](docs/config/network.en.md)
+
-    - [Client](docs/config/client.en.md)
+Architectural differences from Ceph:
-    - [Global Disk Layout](docs/config/layout-cluster.en.md)
+
-    - [OSD Disk Layout](docs/config/layout-osd.en.md)
+- Vitastor's primary focus is on SSDs. Proper SSD+HDD optimizations may be added in the future, though.
-    - [OSD Runtime Parameters](docs/config/osd.en.md)
+- Vitastor OSD is (and will always be) single-threaded. If you want to dedicate more than 1 core
-    - [Monitor](docs/config/monitor.en.md)
+  per drive you should run multiple OSDs each on a different partition of the drive.
-  - [Pool configuration](docs/config/pool.en.md)
+  Vitastor isn't CPU-hungry though (as opposed to Ceph), so 1 core is sufficient in a lot of cases.
-  - [Image metadata in etcd](docs/config/inode.en.md)
+- Metadata and journal are always kept in memory. Metadata size depends linearly on drive capacity
- Usage
+  and data store block size which is 128 KB by default. With 128 KB blocks metadata should occupy
-  - [vitastor-cli](docs/usage/cli.en.md) (command-line interface)
+  around 512 MB per 1 TB (which is still less than Ceph wants). Journal doesn't have to be big,
-  - [vitastor-disk](docs/usage/disk.en.md) (disk management tool)
+  the example test below was conducted with only 16 MB journal. A big journal is probably even
-  - [fio](docs/usage/fio.en.md) for benchmarks
+  harmful as dirty write metadata also take some memory.
-  - [NBD](docs/usage/nbd.en.md) for kernel mounts
+- Vitastor storage layer doesn't have internal copy-on-write or redirect-write. I know that maybe
-  - [QEMU and qemu-img](docs/usage/qemu.en.md)
+  it's possible to create a good copy-on-write storage, but it's much harder and makes performance
-  - [NFS](docs/usage/nfs.en.md) clustered file system and pseudo-FS proxy
+  less deterministic, so CoW isn't used in Vitastor.
-  - [Administration](docs/usage/admin.en.md)
+- The basic layer of Vitastor is block storage with fixed-size blocks, not object storage with
- Performance
+  rich semantics like in Ceph (RADOS).
-  - [Understanding storage performance](docs/performance/understanding.en.md)
+- There's a "lazy fsync" mode which allows to batch writes before flushing them to the disk.
-  - [Theoretical performance](docs/performance/theoretical.en.md)
+  This allows to use Vitastor with desktop SSDs, but still lowers performance due to additional
-  - [Example comparison with Ceph](docs/performance/comparison1.en.md)
+  network roundtrips, so use server SSDs with capacitor-based power loss protection
-  - [Newer benchmark of Vitastor 1.3.1](docs/performance/bench2.en.md)
+  ("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
--- a/VNPL-1.1-RU.txt
+++ b/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 для того, чтобы узнать конкретные требования.
--- a/VNPL-1.1.txt
+++ b/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,
--- a/copy-fio-includes.sh
+++ b/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
--- a/copy-qemu-includes.sh
+++ b/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
--- a/2
+++ b/2
@ -1 +1 @@
-Subproject commit 8de8b467acbca50cfd8835c20e0e379110f3b32b
+Subproject commit 5dc108754ad40d3b1d024f9bd7cca0595ef1a1db
--- a/csi/Dockerfile
+++ b/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'` && \
+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 && \
+RUN cd /app; CGO_ENABLED=1 GOOS=linux GOARCH=amd64 go build -o vitastor-csi
    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 \
+    apt-get install -y e2fsprogs xfsprogs vitastor kmod && \
        # 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 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"]
--- a/csi/Makefile
+++ b/csi/Makefile
@ -1,9 +1,9 @@
-VITASTOR_VERSION ?= v1.9.3
+VERSION ?= v0.6.11
 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)
--- a/csi/deploy/001-csi-config-map.yaml
+++ b/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:
--- a/csi/deploy/004-csi-nodeplugin.yaml
+++ b/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.11
          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
--- a/csi/deploy/005-csi-provisioner-rbac.yaml
+++ b/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"]
+    verbs: ["get", "list"]
  - apiGroups: ["snapshot.storage.k8s.io"]
    resources: ["volumesnapshots/status"]
    verbs: ["get", "list", "patch"]
  - 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"]
--- a/csi/deploy/007-csi-provisioner.yaml
+++ b/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.11
          args:
            - "--node=$(NODE_ID)"
            - "--endpoint=$(CSI_ENDPOINT)"
--- a/csi/deploy/009-storage-class.yaml
+++ b/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"
--- a/csi/deploy/example-pvc-block.yaml
+++ b/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
--- a/csi/deploy/example-snapshot-class.yaml
+++ b/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:
--- a/csi/deploy/example-snapshot-clone.yaml
+++ b/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
--- a/csi/deploy/example-snapshot.yaml
+++ b/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
--- a/csi/deploy/example-test-pod-block.yaml
+++ b/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
--- a/csi/deploy/example-test-pod.yaml
+++ b/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
--- a/csi/go.mod
+++ b/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
+	github.com/soheilhy/cmux v0.1.5 // indirect
-	golang.org/x/xerrors v0.0.0-20200804184101-5ec99f83aff1 // 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
 )
--- a/csi/go.sum
+++ b/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.4.0 h1:ozAshSKxpJnYUfmkpZCTYyF/4MYeYlhdXbAvPvfGmkg=
-github.com/container-storage-interface/spec v1.8.0/go.mod h1:ROLik+GhPslwwWRNFF1KasPzroNARibH2rfz1rkg4H0=
+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-20200822124328-c89045814202/go.mod h1:/O7V0waA8r7cgGh81Ro3o1hOxt32SMVPicZroKQ2sZA=
-golang.org/x/net v0.0.0-20220722155237-a158d28d115b/go.mod h1:XRhObCWvk6IyKnWLug+ECip1KBveYUHfp+8e9klMJ9c=
+golang.org/x/net v0.0.0-20201021035429-f5854403a974/go.mod h1:sp8m0HH+o8qH0wwXwYZr8TS3Oi6o0r6Gce1SSxlDquU=
-golang.org/x/net v0.7.0 h1:rJrUqqhjsgNp7KqAIc25s9pZnjU7TUcSY7HcVZjdn1g=
+golang.org/x/net v0.0.0-20201202161906-c7110b5ffcbb h1:eBmm0M9fYhWpKZLjQUUKka/LtIxf46G4fxeEz5KJr9U=
-golang.org/x/net v0.7.0/go.mod h1:2Tu9+aMcznHK/AK1HMvgo6xiTLG5rD5rZLDS+rp2Bjs=
+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-20200930185726-fdedc70b468f h1:+Nyd8tzPX9R7BWHguqsrbFdRx3WQ/1ib8I44HXV5yTA=
-golang.org/x/sys v0.0.0-20210615035016-665e8c7367d1/go.mod h1:oPkhp1MJrh7nUepCBck5+mAzfO9JrbApNNgaTdGDITg=
+golang.org/x/sys v0.0.0-20200930185726-fdedc70b468f/go.mod h1:h1NjWce9XRLGQEsW7wpKNCjG9DtNlClVuFLEZdDNbEs=
 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/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=
--- a/csi/src/config.go
+++ b/csi/src/config.go
@ -5,7 +5,7 @@ package vitastor
 const (
    vitastorCSIDriverName    = "csi.vitastor.io"
-    vitastorCSIDriverVersion = "1.9.3"
+    vitastorCSIDriverVersion = "0.6.11"
 )
 // Config struct fills the parameters of request or user input
--- a/csi/src/controllerserver.go
+++ b/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 configFD, err := os.Open(configPath); err == nil
    if (err != nil)
    {
        return nil, err
    }
        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
+    // Try to load prefix & etcd URL from the config
    // change them - storage class parameters are saved in volume IDs
    var etcdUrl []string
-    switch config["etcd_address"].(type)
+    if (params["etcdUrl"] != "")
    {
-    case string:
+        ctxVars["etcdUrl"] = params["etcdUrl"]
-        url := strings.TrimSpace(config["etcd_address"].(string))
+        etcdUrl = strings.Split(params["etcdUrl"], ",")
        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)
            }
        }
    }
    if (len(etcdUrl) == 0)
    {
-        return nil, status.Error(codes.InvalidArgument, "etcd_address is missing in "+configPath)
+        switch config["etcd_address"].(type)
    }
    return ctxVars, nil
 }
 func invokeCLI(ctxVars map[string]string, args []string) ([]byte, error)
 {
    if (ctxVars["configPath"] != "")
        {
-        args = append(args, "--config_path", ctxVars["configPath"])
+        case string:
            etcdUrl = strings.Split(config["etcd_address"].(string), ",")
        case []string:
            etcdUrl = config["etcd_address"].([]string)
        }
-    stdout, _, err := system("/usr/bin/vitastor-cli", args...)
+    }
-    return stdout, err
+    etcdPrefix := params["etcdPrefix"]
    if (etcdPrefix == "")
    {
        etcdPrefix, _ = config["etcd_prefix"].(string)
        if (etcdPrefix == "")
        {
            etcdPrefix = "/vitastor"
        }
    }
    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)
+    // FIXME: The following should PROBABLY be implemented externally in a management tool
-    if (err != nil)
+
    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) }
+    // Connect to etcd
    cli, err := clientv3.New(clientv3.Config{
        DialTimeout: ETCD_TIMEOUT,
        Endpoints: etcdUrl,
    })
    if (err != nil)
    {
        return nil, status.Error(codes.Internal, "failed to connect to etcd at "+strings.Join(etcdUrl, ",")+": "+err.Error())
    }
    defer cli.Close()
-    // Support creation from snapshot
+    var imageId uint64 = 0
-    var src *csi.VolumeContentSource
+    for
    if (req.VolumeContentSource.GetSnapshot() != nil)
    {
-        snapId := req.VolumeContentSource.GetSnapshot().GetSnapshotId()
+        // Check if the image exists
-        if (snapId != "")
+        ctx, cancel := context.WithTimeout(context.Background(), ETCD_TIMEOUT)
-        {
+        resp, err := cli.Get(ctx, etcdPrefix+"/index/image/"+volName)
-            snapVars := make(map[string]string)
+        cancel()
            err := json.Unmarshal([]byte(snapId), &snapVars)
        if (err != nil)
        {
-                return nil, status.Error(codes.Internal, "volume ID not in JSON format")
+            return nil, status.Error(codes.Internal, "failed to read key from etcd: "+err.Error())
        }
-            args = append(args, "--parent", snapVars["name"]+"@"+snapVars["snapshot"])
+        if (len(resp.Kvs) > 0)
-            src = &csi.VolumeContentSource{
+        {
-                Type: &csi.VolumeContentSource_Snapshot{
+            kv := resp.Kvs[0]
-                    Snapshot: &csi.VolumeContentSource_SnapshotSource{
+            var v InodeIndex
-                        SnapshotId: snapId,
+            err := json.Unmarshal(kv.Value, &v)
                    },
                },
            }
        }
    }
    // Create image using vitastor-cli
    _, err = invokeCLI(ctxVars, args)
            if (err != nil)
            {
-        if (strings.Index(err.Error(), "already exists") > 0)
+                return nil, status.Error(codes.Internal, "invalid /index/image/"+volName+" key in etcd: "+err.Error())
-        {
+            }
-            inodeCfg, err := invokeList(ctxVars, volName, true)
+            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, err
+                return nil, status.Error(codes.Internal, "failed to read key from etcd: "+err.Error())
            }
-            if (inodeCfg[0].Size < uint64(volSize))
+            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)
+    ctxVars := make(map[string]string)
-    err := json.Unmarshal([]byte(req.VolumeId), &volVars)
+    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)
+    _, etcdUrl, etcdPrefix := GetConnectionParams(ctxVars)
-    if (err != nil)
+    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,
    } {
        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))
+    return nil, status.Error(codes.Unimplemented, "")
    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
 }
 // 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))
+    return nil, status.Error(codes.Unimplemented, "")
    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
 }
 // 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))
+    return nil, status.Error(codes.Unimplemented, "")
    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
 }
-// 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))
+    return nil, status.Error(codes.Unimplemented, "")
    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
 }
 // ControllerGetVolume get volume info
--- a/csi/src/identityserver.go
+++ b/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
 }
--- a/csi/src/nodeserver.go
+++ b/csi/src/nodeserver.go
@ -5,15 +5,11 @@ package vitastor
 import (
    "context"
    "encoding/json"
    "fmt"
    "os"
    "os/exec"
-    "path/filepath"
+    "encoding/json"
    "strings"
-    "sync"
+    "bytes"
    "syscall"
    "time"
    "google.golang.org/grpc/codes"
    "google.golang.org/grpc/status"
@ -29,183 +25,71 @@ 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")
+    return &NodeServer{
    if (stateDir == "")
    {
        stateDir = "/run/vitastor-csi"
    }
    if (stateDir[len(stateDir)-1] != '/')
    {
        stateDir += "/"
    }
    ns := &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))
+    return &csi.NodeStageVolumeResponse{}, nil
 }
 // NodeUnstageVolume unstages the volume from the staging path
 func (ns *NodeServer) NodeUnstageVolume(ctx context.Context, req *csi.NodeUnstageVolumeRequest) (*csi.NodeUnstageVolumeResponse, error)
 {
    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)
@ -213,113 +97,59 @@ func (ns *NodeServer) NodeStageVolume(ctx context.Context, req *csi.NodeStageVol
    {
        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)
+    _, etcdUrl, etcdPrefix := GetConnectionParams(ctxVars)
-    defer ns.unlockVolume(ctxVars["configPath"]+":"+volName)
+    if (len(etcdUrl) == 0)
    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)
+        return nil, status.Error(codes.InvalidArgument, "no etcdUrl in storage class configuration and no etcd_address in vitastor.conf")
        {
            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
+    // Map NBD device
-    if (!ns.useVduse)
+    // FIXME: Check if already mapped
    args := []string{
        "map", "--etcd_address", strings.Join(etcdUrl, ","),
        "--etcd_prefix", etcdPrefix,
        "--image", volName,
    };
    if (ctxVars["configPath"] != "")
    {
-        devicePath, err = mapNbd(volName, ctxVars, false)
+        args = append(args, "--config_path", ctxVars["configPath"])
    }
-    else
+    if (req.GetReadonly())
    {
-        devicePath, vdpaId, err = mapVduse(ns.stateDir, volName, ctxVars, false)
+        args = append(args, "--readonly", "1")
    }
    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, err
+        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)
    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
    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)
-            goto unmap
+        // 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 ||
@ -335,43 +165,38 @@ func (ns *NodeServer) NodeStageVolume(ctx context.Context, req *csi.NodeStageVol
    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}
+                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)
+                args = []string{"-K", devicePath}
        }
-            if (err != nil)
+        if (len(args) > 0)
        {
-                goto unmap
+            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())
            }
        }
-
+    }
-        klog.Infof("formatting and mounting %s to %s with FS %s, options: %v", devicePath, targetPath, fsType, opt)
+    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.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)
    {
@ -379,183 +204,14 @@ func (ns *NodeServer) NodeStageVolume(ctx context.Context, req *csi.NodeStageVol
            "failed to mount device path (%s) to path (%s) for volume (%s) error: %s",
            devicePath, targetPath, volName, err,
        )
-        goto unmap
+        // unmap NBD device
-    }
+        unmapOut, unmapErr := exec.Command("/usr/bin/vitastor-nbd", "unmap", devicePath).CombinedOutput()
-    return &csi.NodeStageVolumeResponse{}, nil
+        if (unmapErr != nil)
 unmap:
    if (!ns.useVduse || len(devicePath) >= 8 && devicePath[0:8] == "/dev/nbd")
        {
-        unmapNbd(devicePath)
+            klog.Errorf("failed to unmap NBD device %s: %s, error: %v", devicePath, unmapOut, unmapErr)
        }
-    else
+        return nil, status.Error(codes.Internal, err.Error())
    {
        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
 }
 // 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))
    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)
    {
        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)
    }
    // Check that targetPath is not already mounted
    notmnt, err = mount.IsNotMountPoint(ns.mounter, targetPath)
    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
        }
    }
    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")
    }
    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()
    if (err != nil)
    {
        return nil, fmt.Errorf("Error running mount %v: %s", strings.Join(execArgs, " "), out)
    }
    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
+        return nil, status.Error(codes.NotFound, "Volume not mounted")
        klog.Warningf("%s is not a mountpoint, deleting", targetPath)
        os.Remove(targetPath)
        return &csi.NodeUnpublishVolumeResponse{}, nil
    }
    // 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{
+    return &csi.NodeGetCapabilitiesResponse{}, nil
        Capabilities: []*csi.NodeServiceCapability{
            &csi.NodeServiceCapability{
                Type: &csi.NodeServiceCapability_Rpc{
                    Rpc: &csi.NodeServiceCapability_RPC{
                        Type: csi.NodeServiceCapability_RPC_STAGE_UNSTAGE_VOLUME,
                    },
                },
            },
        },
    }, nil
 }
 // NodeGetInfo returns NodeGetInfoResponse for CO.
--- a/csi/src/utils.go
+++ b/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
 }
--- a/debian/build-pve-qemu.sh
+++ b/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
--- a/debian/build-vitastor-bookworm.sh
+++ b/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
--- a/debian/build-vitastor-bullseye.sh
+++ b/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
--- a/debian/build-vitastor-buster.sh
+++ b/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
--- a/debian/build-vitastor-ubuntu-jammy.sh
+++ b/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
--- a/debian/changelog
+++ b/debian/changelog
@ -1,18 +1,4 @@
-vitastor (1.9.3-1) unstable; urgency=medium
+vitastor (0.6.11-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
  * RDMA support
  * Bugfixes
--- a/debian/control
+++ b/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.
--- a/debian/libisal.pc
+++ b/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}
--- a/debian/libvirt.Dockerfile
+++ b/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/*; \
--- a/debian/patched-qemu.Dockerfile
+++ b/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 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/
 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
 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!'); \
+    if ls -d /root/packages/qemu-$REL/qemu-5.0*; then \
-    D=$(ls -d qemu*/); \
+        D=$(ls -d /root/packages/qemu-$REL/qemu-5.0*); \
-    cp /root/vitastor/patches/qemu-$QEMU_VER-vitastor.patch ./qemu-*/debian/patches; \
+        cp /root/vitastor/patches/qemu-5.0-vitastor.patch $D/debian/patches; \
-    echo qemu-$QEMU_VER-vitastor.patch >> $D/debian/patches/series; \
+        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; \
+    V=$(head -n1 debian/changelog | perl -pe 's/^.*\((.*?)(~bpo[\d\+]*)?\).*$/$1/')+vitastor1; \
    if [ "$REL" = bullseye ]; then V=${V}bullseye; fi; \
    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-*/
--- a/debian/pve-storage-vitastor.install
+++ b/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
--- a/debian/vitastor-client.install
+++ b/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
--- a/debian/vitastor-mon.install
+++ b/debian/vitastor-mon.install
@ -1,3 +1 @@
-mon usr/lib/vitastor/
+mon usr/lib/vitastor
 mon/scripts/make-etcd usr/lib/vitastor/mon
 mon/scripts/vitastor-mon.service /lib/systemd/system
--- a/debian/vitastor-mon.postinst
+++ b/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
--- a/debian/vitastor-opennebula.install
+++ b/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/
--- a/debian/vitastor-opennebula.postinst
+++ b/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
--- a/debian/vitastor-opennebula.triggers
+++ b/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
--- a/debian/vitastor-osd.install
+++ b/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
--- a/debian/vitastor-osd.postinst
+++ b/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
--- a/debian/vitastor.Dockerfile
+++ b/debian/vitastor.Dockerfile
@ -1,34 +1,31 @@
-# Build Vitastor packages for Debian inside a container
+# Build Vitastor packages 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/vitastor.Dockerfile .
+# cd ..; podman build --build-arg REL=bullseye -v `pwd`/packages:/root/packages -f debian/vitastor.Dockerfile .
 ARG DISTRO=debian
 ARG REL=
-FROM $DISTRO:$REL
+FROM debian:$REL
 ARG DISTRO=debian
 ARG REL=
 WORKDIR /root
-RUN set -e -x; \
+RUN if [ "$REL" = "buster" -o "$REL" = "bullseye" ]; then \
-    if [ "$REL" = "buster" ]; then \
+        echo "deb http://deb.debian.org/debian $REL-backports main" >> /etc/apt/sources.list; \
-        apt-get update; \
+        echo >> /etc/apt/preferences; \
-        apt-get -y install wget; \
+        echo 'Package: *' >> /etc/apt/preferences; \
-        wget https://vitastor.io/debian/pubkey.gpg -O /etc/apt/trusted.gpg.d/vitastor.gpg; \
+        echo "Pin: release a=$REL-backports" >> /etc/apt/preferences; \
-        echo "deb https://vitastor.io/debian $REL main" >> /etc/apt/sources.list; \
+        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/'); \
+    cp -r /root/vitastor vitastor-0.6.11; \
-    VER=${FULLVER%%-*}; \
+    cd vitastor-0.6.11; \
    cp -r /root/vitastor vitastor-$VER; \
    cd vitastor-$VER; \
    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; \
+    tar --sort=name --mtime='2020-01-01' --owner=0 --group=0 --exclude=debian -cJf vitastor_0.6.11.orig.tar.xz vitastor-0.6.11; \
-    cd vitastor-$VER; \
+    cd vitastor-0.6.11; \
-    DEBFULLNAME="Vitaliy Filippov <vitalif@yourcmc.ru>" dch -D $REL -v "$FULLVER""$REL" "Rebuild for $REL"; \
+    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-*/
--- a/docker/vitastor.gpg
+++ b/docker/vitastor.gpg
--- a/docs/config.en.md
+++ b/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)
--- a/docs/config.ru.md
+++ b/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)
--- a/docs/config/client.en.md
+++ b/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.
--- a/docs/config/client.ru.md
+++ b/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.
--- a/docs/config/common.en.md
+++ b/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.
--- a/docs/config/common.ru.md
+++ b/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
 - Можно менять на лету: да
 Уровень логгирования. Повысьте, если хотите более подробный вывод.
--- a/docs/config/inode.en.md
+++ b/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.
--- a/docs/config/inode.ru.md
+++ b/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 новых образов.
--- a/docs/config/layout-cluster.en.md
+++ b/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".
--- a/docs/config/layout-cluster.ru.md
+++ b/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).
--- a/docs/config/layout-osd.en.md
+++ b/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).
--- a/docs/config/layout-osd.ru.md
+++ b/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).
--- a/docs/config/monitor.en.md
+++ b/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.
--- a/docs/config/monitor.ru.md
+++ b/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) для пулов, которые не используют данные функции.
--- a/docs/config/network.en.md
+++ b/docs/config/network.en.md
@ -1,263 +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"). If not specified, Vitastor will try to find an RoCE
 device matching [osd_network](osd.en.md#osd_network), preferring RoCEv2,
 or choose the first available RDMA device if no RoCE devices are
 found or if `osd_network` is not specified. Auto-selection is also
 unsupported with old libibverbs < v32, like in Debian 10 Buster or
 CentOS 7.
 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
 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.
 If not specified, Vitastor will try to auto-select a RoCEv2 IPv4 GID, then
 RoCEv2 IPv6 GID, then RoCEv1 IPv4 GID, then RoCEv1 IPv6 GID, then IB GID.
 GID auto-selection is unsupported with libibverbs < v32.
 A correct rdma_gid_index for RoCEv2 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.
--- a/docs/config/network.ru.md
+++ b/docs/config/network.ru.md
@ -1,273 +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 попробует найти RoCE-устройство, соответствующее
 [osd_network](osd.en.md#osd_network), предпочитая RoCEv2, или выбрать первое
 попавшееся RDMA-устройство, если RoCE-устройств нет или если сеть `osd_network`
 не задана. Также автовыбор не поддерживается со старыми версиями библиотеки
 libibverbs < v32, например в Debian 10 Buster или CentOS 7.
 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
 - Тип: целое число
 Номер глобального идентификатора адреса RDMA-устройства, который следует
 использовать. Разным gid_index могут соответствовать разные протоколы связи:
 RoCEv1, RoCEv2, iWARP. Чтобы понять, какой нужен вам - смотрите строчки со
 словом "GID" в выводе команды `ibv_devinfo -v`.
 Если не указан, Vitastor попробует автоматически выбрать сначала GID,
 соответствующий RoCEv2 IPv4, потом RoCEv2 IPv6, потом RoCEv1 IPv4, потом
 RoCEv1 IPv6, потом IB. Авто-выбор GID не поддерживается со старыми версиями
 libibverbs < v32.
 Правильный rdma_gid_index для RoCEv2, как правило, 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.
--- a/docs/config/osd.en.md
+++ b/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.
--- a/docs/config/osd.ru.md
+++ b/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.
 Большие значения считаются случайными выбросами и игнорируются в
 усреднении.
--- a/docs/config/pool.en.md
+++ b/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"
  }
 }
 ```
--- a/docs/config/pool.ru.md
+++ b/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"
  }
 }
 ```
--- a/docs/config/src/client.en.md
+++ b/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.
--- a/docs/config/src/client.ru.md
+++ b/docs/config/src/client.ru.md
@ -1,4 +0,0 @@
 # Параметры клиентского кода
 Данные параметры применяются только к клиентам Vitastor (QEMU, fio, NBD и т.п.) и
 затрагивают логику их работы с кластером.
--- a/docs/config/src/client.yml
+++ b/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.
--- a/docs/config/src/common.en.md
+++ b/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.
--- a/docs/config/src/common.ru.md
+++ b/docs/config/src/common.ru.md
@ -1,3 +0,0 @@
 # Общие параметры
 Это наиболее общие параметры, используемые всеми компонентами Vitastor.
--- a/docs/config/src/common.yml
+++ b/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: Уровень логгирования. Повысьте, если хотите более подробный вывод.
--- a/docs/config/src/include.js
+++ b/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;
 }
--- a/docs/config/src/included.en.md
+++ b/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}}
--- a/docs/config/src/included.ru.md
+++ b/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}}
--- a/docs/config/src/layout-cluster.en.md
+++ b/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.
--- a/docs/config/src/layout-cluster.ru.md
+++ b/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 данного пула.
--- a/docs/config/src/layout-cluster.yml
+++ b/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).
--- a/docs/config/src/layout-osd.en.md
+++ b/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.
--- a/docs/config/src/layout-osd.ru.md
+++ b/docs/config/src/layout-osd.ru.md
@ -1,5 +0,0 @@
 # Дисковые параметры OSD
 Данные параметры используются только OSD и, также как и общекластерные
 дисковые параметры, задаются в момент инициализации дисков OSD и не могут быть
 изменены после этого без потери данных.
--- a/docs/config/src/layout-osd.yml
+++ b/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).
--- a/docs/config/src/make.js
+++ b/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;
 }
--- a/docs/config/src/monitor.en.md
+++ b/docs/config/src/monitor.en.md
@ -1,3 +0,0 @@
 # Monitor Parameters
 These parameters only apply to Monitors.
--- a/docs/config/src/monitor.ru.md
+++ b/docs/config/src/monitor.ru.md
@ -1,3 +0,0 @@
 # Параметры мониторов
 Данные параметры используются только мониторами Vitastor.
--- a/docs/config/src/monitor.yml
+++ b/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) для пулов, которые не используют данные функции.
--- a/docs/config/src/network.en.md
+++ b/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.
--- a/docs/config/src/network.ru.md
+++ b/docs/config/src/network.ru.md
@ -1,4 +0,0 @@
 # Параметры сетевого протокола
 Данные параметры используются клиентами и OSD и влияют на логику сетевого
 взаимодействия между клиентами, OSD, а также etcd.
--- a/docs/config/src/network.yml
+++ b/docs/config/src/network.yml
@ -1,308 +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"). If not specified, Vitastor will try to find an RoCE
    device matching [osd_network](osd.en.md#osd_network), preferring RoCEv2,
    or choose the first available RDMA device if no RoCE devices are
    found or if `osd_network` is not specified. Auto-selection is also
    unsupported with old libibverbs < v32, like in Debian 10 Buster or
    CentOS 7.
    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 попробует найти RoCE-устройство, соответствующее
    [osd_network](osd.en.md#osd_network), предпочитая RoCEv2, или выбрать первое
    попавшееся RDMA-устройство, если RoCE-устройств нет или если сеть `osd_network`
    не задана. Также автовыбор не поддерживается со старыми версиями библиотеки
    libibverbs < v32, например в Debian 10 Buster или CentOS 7.
    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
  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.
    If not specified, Vitastor will try to auto-select a RoCEv2 IPv4 GID, then
    RoCEv2 IPv6 GID, then RoCEv1 IPv4 GID, then RoCEv1 IPv6 GID, then IB GID.
    GID auto-selection is unsupported with libibverbs < v32.
    A correct rdma_gid_index for RoCEv2 is usually 1 (IPv6) or 3 (IPv4).
  info_ru: |
    Номер глобального идентификатора адреса RDMA-устройства, который следует
    использовать. Разным gid_index могут соответствовать разные протоколы связи:
    RoCEv1, RoCEv2, iWARP. Чтобы понять, какой нужен вам - смотрите строчки со
    словом "GID" в выводе команды `ibv_devinfo -v`.
    Если не указан, Vitastor попробует автоматически выбрать сначала GID,
    соответствующий RoCEv2 IPv4, потом RoCEv2 IPv6, потом RoCEv1 IPv4, потом
    RoCEv1 IPv6, потом IB. Авто-выбор GID не поддерживается со старыми версиями
    libibverbs < v32.
    Правильный rdma_gid_index для RoCEv2, как правило, 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.
--- a/docs/config/src/osd.en.md
+++ b/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.
--- a/docs/config/src/osd.ru.md
+++ b/docs/config/src/osd.ru.md
@ -1,6 +0,0 @@
 # Изменяемые параметры OSD
 Данные параметры используются только OSD, но, в отличие от дисковых параметров,
 не фиксируются в момент инициализации дисков OSD и могут быть изменены в любой
 момент с помощью перезапуска OSD, а некоторые и без перезапуска, с помощью
 изменения конфигурации в etcd.
--- a/Show More
+++ b/Show More
		`@ -1 +1 @@`
			`Subproject commit 8de8b467acbca50cfd8835c20e0e379110f3b32b`				`Subproject commit 5dc108754ad40d3b1d024f9bd7cca0595ef1a1db`
`@ -1 +1 @@`
	`patches/VitastorPlugin.pm usr/share/perl5/PVE/Storage/Custom/`	`patches/PVE_VitastorPlugin.pm usr/share/perl5/PVE/Storage/Custom/VitastorPlugin.pm`
		`@ -1,3 +0,0 @@`
			`# Common Parameters`

			`These are the most common parameters which apply to all components of Vitastor.`
		`@ -1,3 +0,0 @@`
			`# Общие параметры`

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

			`These parameters only apply to Monitors.`
		`@ -1,3 +0,0 @@`
			`# Параметры мониторов`

			`Данные параметры используются только мониторами Vitastor.`