Implement simple "flow control" for RDMA (to check hypothesis about slowdowns)

2023-03-24 01:57:32 +03:00
486 changed files with 9140 additions and 57415 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
@ -2,6 +2,6 @@ cmake_minimum_required(VERSION 2.8.12)

 project(vitastor)

-set(VITASTOR_VERSION "1.9.3")
+set(VERSION "0.8.6")

 add_subdirectory(src)
--- a/README-ru.md
+++ b/README-ru.md
@ -1,4 +1,4 @@
-# Vitastor
+## Vitastor

 [Read English version](README.md)

@ -6,8 +6,8 @@

 Вернём былую скорость кластерному блочному хранилищу!

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

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

-Vitastor нацелен в первую очередь на SSD и SSD+HDD кластеры с как минимум 10 Гбит/с сетью, поддерживает
+Vitastor нацелен на SSD и SSD+HDD кластеры с как минимум 10 Гбит/с сетью, поддерживает
 TCP и RDMA и на хорошем железе может достигать задержки 4 КБ чтения и записи на уровне ~0.1 мс,
 что примерно в 10 раз быстрее, чем Ceph и другие популярные программные СХД.

-Vitastor поддерживает QEMU-драйвер, протоколы NBD и NFS, драйверы OpenStack, OpenNebula, Proxmox, Kubernetes.
+Vitastor поддерживает QEMU-драйвер, протоколы NBD и NFS, драйверы OpenStack, Proxmox, Kubernetes.
 Другие драйверы могут также быть легко реализованы.

-Подробности смотрите в документации по ссылкам. Можете начать отсюда: [Быстрый старт](docs/intro/quickstart.ru.md).
+Подробности смотрите в документации по ссылкам ниже.

 ## Презентации и записи докладов

@ -42,7 +42,6 @@ Vitastor поддерживает QEMU-драйвер, протоколы NBD и
 - Установка
  - [Пакеты](docs/installation/packages.ru.md)
  - [Proxmox](docs/installation/proxmox.ru.md)
-  - [OpenNebula](docs/installation/opennebula.ru.md)
  - [OpenStack](docs/installation/openstack.ru.md)
  - [Kubernetes CSI](docs/installation/kubernetes.ru.md)
  - [Сборка из исходных кодов](docs/installation/source.ru.md)
@ -51,7 +50,6 @@ Vitastor поддерживает QEMU-драйвер, протоколы NBD и
  - Параметры
    - [Общие](docs/config/common.ru.md)
    - [Сетевые](docs/config/network.ru.md)
-    - [Клиентский код](docs/config/client.ru.md)
    - [Глобальные дисковые параметры](docs/config/layout-cluster.ru.md)
    - [Дисковые параметры OSD](docs/config/layout-osd.ru.md)
    - [Прочие параметры OSD](docs/config/osd.ru.md)
@ -64,13 +62,11 @@ Vitastor поддерживает QEMU-драйвер, протоколы NBD и
  - [fio](docs/usage/fio.ru.md) для тестов производительности
  - [NBD](docs/usage/nbd.ru.md) для монтирования ядром
  - [QEMU и qemu-img](docs/usage/qemu.ru.md)
-  - [NFS](docs/usage/nfs.ru.md) кластерная файловая система и псевдо-ФС прокси
-  - [Администрирование](docs/usage/admin.ru.md)
+  - [NFS](docs/usage/nfs.ru.md)-прокси для VMWare и подобных
 - Производительность
  - [Понимание сути производительности](docs/performance/understanding.ru.md)
  - [Теоретический максимум](docs/performance/theoretical.ru.md)
  - [Пример сравнения с Ceph](docs/performance/comparison1.ru.md)
-  - [Более новый тест Vitastor 1.3.1](docs/performance/bench2.ru.md)

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

--- a/README.md
+++ b/README.md
@ -6,23 +6,23 @@

 Make Clustered Block Storage Fast Again.

-Vitastor is a distributed block and file SDS, direct replacement of Ceph RBD and CephFS,
-and also internal SDS's of public clouds. However, in contrast to them, Vitastor is fast
-and simple at the same time. The only thing is it's slightly young :-).
+Vitastor is a distributed block SDS, direct replacement of Ceph RBD and internal SDS's
+of public clouds. However, in contrast to them, Vitastor is fast and simple at the same time.
+The only thing is it's slightly young :-).

 Vitastor is architecturally similar to Ceph which means strong consistency,
 primary-replication, symmetric clustering and automatic data distribution over any
 number of drives of any size with configurable redundancy (replication or erasure codes/XOR).

-Vitastor targets primarily SSD and SSD+HDD clusters with at least 10 Gbit/s network,
-supports TCP and RDMA and may achieve 4 KB read and write latency as low as ~0.1 ms
+Vitastor targets SSD and SSD+HDD clusters with at least 10 Gbit/s network, supports
+TCP and RDMA and may achieve 4 KB read and write latency as low as ~0.1 ms
 with proper hardware which is ~10 times faster than other popular SDS's like Ceph
 or internal systems of public clouds.

-Vitastor supports QEMU, NBD, NFS protocols, OpenStack, OpenNebula, Proxmox, Kubernetes drivers.
+Vitastor supports QEMU, NBD, NFS protocols, OpenStack, Proxmox, Kubernetes drivers.
 More drivers may be created easily.

-Read more details in the documentation. You can start from here: [Quick Start](docs/intro/quickstart.en.md).
+Read more details below in the documentation.

 ## Talks and presentations

@ -42,7 +42,6 @@ Read more details in the documentation. You can start from here: [Quick Start](d
 - Installation
  - [Packages](docs/installation/packages.en.md)
  - [Proxmox](docs/installation/proxmox.en.md)
-  - [OpenNebula](docs/installation/opennebula.en.md)
  - [OpenStack](docs/installation/openstack.en.md)
  - [Kubernetes CSI](docs/installation/kubernetes.en.md)
  - [Building from Source](docs/installation/source.en.md)
@ -51,7 +50,6 @@ Read more details in the documentation. You can start from here: [Quick Start](d
  - Parameter Reference
    - [Common](docs/config/common.en.md)
    - [Network](docs/config/network.en.md)
-    - [Client](docs/config/client.en.md)
    - [Global Disk Layout](docs/config/layout-cluster.en.md)
    - [OSD Disk Layout](docs/config/layout-osd.en.md)
    - [OSD Runtime Parameters](docs/config/osd.en.md)
@ -64,13 +62,11 @@ Read more details in the documentation. You can start from here: [Quick Start](d
  - [fio](docs/usage/fio.en.md) for benchmarks
  - [NBD](docs/usage/nbd.en.md) for kernel mounts
  - [QEMU and qemu-img](docs/usage/qemu.en.md)
-  - [NFS](docs/usage/nfs.en.md) clustered file system and pseudo-FS proxy
-  - [Administration](docs/usage/admin.en.md)
+  - [NFS](docs/usage/nfs.en.md) emulator for VMWare and similar
 - Performance
  - [Understanding storage performance](docs/performance/understanding.en.md)
  - [Theoretical performance](docs/performance/theoretical.en.md)
  - [Example comparison with Ceph](docs/performance/comparison1.en.md)
-  - [Newer benchmark of Vitastor 1.3.1](docs/performance/bench2.en.md)

 ## Author and License

--- 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 45e6d1f13196a0824e2089a586c53b9de0283f17
--- 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'` && \
-    cd /app && \
-    CGO_ENABLED=1 GOOS=linux GOARCH=amd64 go build -o vitastor-csi
+RUN perl -i -e '$/ = undef; while(<>) { s/\n\s*(\{\s*\n)/$1\n/g; s/\}(\s*\n\s*)else\b/$1} else/g; print; }' `find /app -name '*.go'`
+RUN cd /app; CGO_ENABLED=1 GOOS=linux GOARCH=amd64 go build -o vitastor-csi

 # Final stage
-FROM debian:bookworm
+FROM debian:buster

 LABEL maintainers="Vitaliy Filippov <vitalif@yourcmc.ru>"
 LABEL description="Vitastor CSI Driver"
@ -19,30 +18,19 @@ ENV CSI_ENDPOINT=""

 RUN apt-get update && \
    apt-get install -y wget && \
+    (echo deb http://deb.debian.org/debian buster-backports main > /etc/apt/sources.list.d/backports.list) && \
    (echo "APT::Install-Recommends false;" > /etc/apt/apt.conf) && \
    apt-get update && \
-    apt-get install -y e2fsprogs xfsprogs kmod iproute2 \
-        # dependencies of qemu-storage-daemon
-        libnuma1 liburing2 libglib2.0-0 libfuse3-3 libaio1 libzstd1 libnettle8 \
-        libgmp10 libhogweed6 libp11-kit0 libidn2-0 libunistring2 libtasn1-6 libpcre2-8-0 libffi8 && \
+    apt-get install -y e2fsprogs xfsprogs kmod && \
    apt-get clean && \
    (echo options nbd nbds_max=128 > /etc/modprobe.d/nbd.conf)

 COPY --from=build /app/vitastor-csi /bin/

-RUN (echo deb http://vitastor.io/debian bookworm main > /etc/apt/sources.list.d/vitastor.list) && \
-    ((echo 'Package: *'; echo 'Pin: origin "vitastor.io"'; echo 'Pin-Priority: 1000') > /etc/apt/preferences.d/vitastor.pref) && \
+RUN (echo deb http://vitastor.io/debian buster main > /etc/apt/sources.list.d/vitastor.list) && \
    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.8.6

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

 // Config struct fills the parameters of request or user input
--- a/csi/src/controllerserver.go
+++ b/csi/src/controllerserver.go
@ -8,9 +8,11 @@ import (
    "encoding/json"
    "fmt"
    "strings"
+    "bytes"
    "strconv"
    "time"
    "os"
+    "os/exec"
    "io/ioutil"

    "github.com/kubernetes-csi/csi-lib-utils/protosanitizer"
@ -18,7 +20,6 @@ import (

    "google.golang.org/grpc/codes"
    "google.golang.org/grpc/status"
-    "google.golang.org/protobuf/types/known/timestamppb"

    "github.com/container-storage-interface/spec/lib/go/csi"
 )
@ -44,7 +45,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 +60,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 +73,71 @@ func GetConnectionParams(params map[string]string) (map[string]string, error)
        ctxVars["configPath"] = configPath
    }
    config := make(map[string]interface{})
-    configFD, err := os.Open(configPath)
-    if (err != nil)
+    if configFD, err := os.Open(configPath); err == nil
    {
-        return nil, err
-    }
        defer configFD.Close()
        data, _ := ioutil.ReadAll(configFD)
        json.Unmarshal(data, &config)
-    // Check etcd URL in the config, but do not use the explicit etcdUrl
-    // parameter for CLI calls, otherwise users won't be able to later
-    // change them - storage class parameters are saved in volume IDs
+    }
+    // Try to load prefix & etcd URL from the config
    var etcdUrl []string
-    switch config["etcd_address"].(type)
+    if (params["etcdUrl"] != "")
    {
-    case string:
-        url := strings.TrimSpace(config["etcd_address"].(string))
-        if (url != "")
-        {
-            etcdUrl = strings.Split(url, ",")
-        }
-    case []string:
-        etcdUrl = config["etcd_address"].([]string)
-    case []interface{}:
-        for _, url := range config["etcd_address"].([]interface{})
-        {
-            s, ok := url.(string)
-            if (ok)
-            {
-                etcdUrl = append(etcdUrl, s)
-            }
-        }
+        ctxVars["etcdUrl"] = params["etcdUrl"]
+        etcdUrl = strings.Split(params["etcdUrl"], ",")
    }
    if (len(etcdUrl) == 0)
    {
-        return nil, status.Error(codes.InvalidArgument, "etcd_address is missing in "+configPath)
+        switch config["etcd_address"].(type)
+        {
+        case string:
+            etcdUrl = strings.Split(config["etcd_address"].(string), ",")
+        case []string:
+            etcdUrl = config["etcd_address"].([]string)
        }
-    return ctxVars, nil
+    }
+    etcdPrefix := params["etcdPrefix"]
+    if (etcdPrefix == "")
+    {
+        etcdPrefix, _ = config["etcd_prefix"].(string)
+        if (etcdPrefix == "")
+        {
+            etcdPrefix = "/vitastor"
+        }
+    }
+    else
+    {
+        ctxVars["etcdPrefix"] = etcdPrefix
+    }
+    return ctxVars, etcdUrl, etcdPrefix
 }

 func invokeCLI(ctxVars map[string]string, args []string) ([]byte, error)
 {
+    if (ctxVars["etcdUrl"] != "")
+    {
+        args = append(args, "--etcd_address", ctxVars["etcdUrl"])
+    }
+    if (ctxVars["etcdPrefix"] != "")
+    {
+        args = append(args, "--etcd_prefix", ctxVars["etcdPrefix"])
+    }
    if (ctxVars["configPath"] != "")
    {
        args = append(args, "--config_path", ctxVars["configPath"])
    }
-    stdout, _, err := system("/usr/bin/vitastor-cli", args...)
-    return stdout, err
+    c := exec.Command("/usr/bin/vitastor-cli", args...)
+    var stdout, stderr bytes.Buffer
+    c.Stdout = &stdout
+    c.Stderr = &stderr
+    err := c.Run()
+    stderrStr := string(stderr.Bytes())
+    if (err != nil)
+    {
+        klog.Errorf("vitastor-cli %s failed: %s, status %s\n", strings.Join(args, " "), stderrStr, err)
+        return nil, status.Error(codes.Internal, stderrStr+" (status "+err.Error()+")")
+    }
+    return stdout.Bytes(), nil
 }

 // Create the volume
@ -140,12 +158,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,49 +172,33 @@ func (cs *ControllerServer) CreateVolume(ctx context.Context, req *csi.CreateVol
        volSize = ((capRange.GetRequiredBytes() + MB - 1) / MB) * MB
    }

-    ctxVars, err := GetConnectionParams(req.Parameters)
-    if (err != nil)
+    ctxVars, etcdUrl, _ := GetConnectionParams(req.Parameters)
+    if (len(etcdUrl) == 0)
    {
-        return nil, err
-    }
-
-    args := []string{ "create", volName, "-s", fmt.Sprintf("%v", volSize), "--pool", fmt.Sprintf("%v", poolId) }
-
-    // Support creation from snapshot
-    var src *csi.VolumeContentSource
-    if (req.VolumeContentSource.GetSnapshot() != nil)
-    {
-        snapId := req.VolumeContentSource.GetSnapshot().GetSnapshotId()
-        if (snapId != "")
-        {
-            snapVars := make(map[string]string)
-            err := json.Unmarshal([]byte(snapId), &snapVars)
-            if (err != nil)
-            {
-                return nil, status.Error(codes.Internal, "volume ID not in JSON format")
-            }
-            args = append(args, "--parent", snapVars["name"]+"@"+snapVars["snapshot"])
-            src = &csi.VolumeContentSource{
-                Type: &csi.VolumeContentSource_Snapshot{
-                    Snapshot: &csi.VolumeContentSource_SnapshotSource{
-                        SnapshotId: snapId,
-                    },
-                },
-            }
-        }
+        return nil, status.Error(codes.InvalidArgument, "no etcdUrl in storage class configuration and no etcd_address in vitastor.conf")
    }

    // Create image using vitastor-cli
-    _, err = invokeCLI(ctxVars, args)
+    _, err := invokeCLI(ctxVars, []string{ "create", volName, "-s", fmt.Sprintf("%v", volSize), "--pool", fmt.Sprintf("%v", poolId) })
    if (err != nil)
    {
        if (strings.Index(err.Error(), "already exists") > 0)
        {
-            inodeCfg, err := invokeList(ctxVars, volName, true)
+            stat, err := invokeCLI(ctxVars, []string{ "ls", "--json", volName })
            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 (len(inodeCfg) == 0)
+            {
+                return nil, status.Error(codes.Internal, "vitastor-cli create said that image already exists, but ls can't find it")
+            }
            if (inodeCfg[0].Size < uint64(volSize))
            {
                return nil, status.Error(codes.Internal, "image "+volName+" is already created, but size is less than expected")
@ -221,7 +217,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,19 +230,15 @@ func (cs *ControllerServer) DeleteVolume(ctx context.Context, req *csi.DeleteVol
        return nil, status.Error(codes.InvalidArgument, "request cannot be empty")
    }

-    volVars := make(map[string]string)
-    err := json.Unmarshal([]byte(req.VolumeId), &volVars)
+    ctxVars := make(map[string]string)
+    err := json.Unmarshal([]byte(req.VolumeId), &ctxVars)
    if (err != nil)
    {
        return nil, status.Error(codes.Internal, "volume ID not in JSON format")
    }
-    volName := volVars["name"]
+    volName := ctxVars["name"]

-    ctxVars, err := GetConnectionParams(volVars)
-    if (err != nil)
-    {
-        return nil, err
-    }
+    ctxVars, _, _ = GetConnectionParams(ctxVars)

    _, err = invokeCLI(ctxVars, []string{ "rm", volName })
    if (err != nil)
@ -289,44 +280,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 +302,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 +344,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 +353,28 @@ func (cs *ControllerServer) ControllerGetCapabilities(ctx context.Context, req *
    }, nil
 }

-func invokeList(ctxVars map[string]string, pattern string, expectExist bool) ([]InodeConfig, error)
-{
-    stat, err := invokeCLI(ctxVars, []string{ "ls", "--json", pattern })
-    if (err != nil)
-    {
-        return nil, err
-    }
-    var inodeCfg []InodeConfig
-    err = json.Unmarshal(stat, &inodeCfg)
-    if (err != nil)
-    {
-        return nil, status.Error(codes.Internal, "Invalid JSON in vitastor-cli ls: "+err.Error())
-    }
-    if (expectExist && len(inodeCfg) == 0)
-    {
-        return nil, status.Error(codes.Internal, "Can't find expected image "+pattern+" via vitastor-cli ls")
-    }
-    return inodeCfg, nil
-}
-
 // CreateSnapshot create snapshot of an existing PV
 func (cs *ControllerServer) CreateSnapshot(ctx context.Context, req *csi.CreateSnapshotRequest) (*csi.CreateSnapshotResponse, error)
 {
-    klog.Infof("received controller create snapshot request %+v", protosanitizer.StripSecrets(req))
-    if (req == nil)
-    {
-        return nil, status.Errorf(codes.InvalidArgument, "request cannot be empty")
-    }
-    if (req.SourceVolumeId == "" || req.Name == "")
-    {
-        return nil, status.Error(codes.InvalidArgument, "source volume ID and snapshot name are required fields")
-    }
-
-    // snapshot name
-    snapName := req.Name
-
-    // req.VolumeId is an ugly json string in our case :)
-    ctxVars := make(map[string]string)
-    err := json.Unmarshal([]byte(req.SourceVolumeId), &ctxVars)
-    if (err != nil)
-    {
-        return nil, status.Error(codes.Internal, "volume ID not in JSON format")
-    }
-    volName := ctxVars["name"]
-
-    // Create image using vitastor-cli
-    _, err = invokeCLI(ctxVars, []string{ "create", "--snapshot", snapName, volName })
-    if (err != nil && strings.Index(err.Error(), "already exists") <= 0)
-    {
-        return nil, err
-    }
-
-    // Check created snapshot
-    inodeCfg, err := invokeList(ctxVars, volName+"@"+snapName, true)
-    if (err != nil)
-    {
-        return nil, err
-    }
-
-    // Use ugly JSON snapshot ID again, DeleteSnapshot doesn't have context :-(
-    ctxVars["snapshot"] = snapName
-    snapIdJson, _ := json.Marshal(ctxVars)
-    return &csi.CreateSnapshotResponse{
-        Snapshot: &csi.Snapshot{
-            SizeBytes: int64(inodeCfg[0].Size),
-            SnapshotId: string(snapIdJson),
-            SourceVolumeId: req.SourceVolumeId,
-            CreationTime: &timestamppb.Timestamp{ Seconds: int64(inodeCfg[0].CreateTs) },
-            ReadyToUse: true,
-        },
-    }, nil
+    return nil, status.Error(codes.Unimplemented, "")
 }

 // DeleteSnapshot delete provided snapshot of a PV
 func (cs *ControllerServer) DeleteSnapshot(ctx context.Context, req *csi.DeleteSnapshotRequest) (*csi.DeleteSnapshotResponse, error)
 {
-    klog.Infof("received controller delete snapshot request %+v", protosanitizer.StripSecrets(req))
-    if (req == nil)
-    {
-        return nil, status.Errorf(codes.InvalidArgument, "request cannot be empty")
-    }
-    if (req.SnapshotId == "")
-    {
-        return nil, status.Error(codes.InvalidArgument, "snapshot ID is a required field")
-    }
-
-    volVars := make(map[string]string)
-    err := json.Unmarshal([]byte(req.SnapshotId), &volVars)
-    if (err != nil)
-    {
-        return nil, status.Error(codes.Internal, "snapshot ID not in JSON format")
-    }
-    volName := volVars["name"]
-    snapName := volVars["snapshot"]
-
-    ctxVars, err := GetConnectionParams(volVars)
-    if (err != nil)
-    {
-        return nil, err
-    }
-
-    _, err = invokeCLI(ctxVars, []string{ "rm", volName+"@"+snapName })
-    if (err != nil)
-    {
-        return nil, err
-    }
-
-    return &csi.DeleteSnapshotResponse{}, nil
+    return nil, status.Error(codes.Unimplemented, "")
 }

 // ListSnapshots list the snapshots of a PV
 func (cs *ControllerServer) ListSnapshots(ctx context.Context, req *csi.ListSnapshotsRequest) (*csi.ListSnapshotsResponse, error)
 {
-    klog.Infof("received controller list snapshots request %+v", protosanitizer.StripSecrets(req))
-    if (req == nil)
-    {
-        return nil, status.Error(codes.InvalidArgument, "request cannot be empty")
+    return nil, status.Error(codes.Unimplemented, "")
 }

-    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))
-    if (req == nil)
-    {
-        return nil, status.Error(codes.InvalidArgument, "request cannot be empty")
-    }
-    if (req.VolumeId == "" || req.CapacityRange == nil || req.CapacityRange.RequiredBytes == 0)
-    {
-        return nil, status.Error(codes.InvalidArgument, "VolumeId, CapacityRange and RequiredBytes are required fields")
-    }
-
-    volVars := make(map[string]string)
-    err := json.Unmarshal([]byte(req.VolumeId), &volVars)
-    if (err != nil)
-    {
-        return nil, status.Error(codes.Internal, "volume ID not in JSON format")
-    }
-    volName := volVars["name"]
-    ctxVars, err := GetConnectionParams(volVars)
-    if (err != nil)
-    {
-        return nil, err
-    }
-
-    inodeCfg, err := invokeList(ctxVars, volName, true)
-    if (err != nil)
-    {
-        return nil, err
-    }
-
-    if (req.CapacityRange.RequiredBytes > 0 && inodeCfg[0].Size < uint64(req.CapacityRange.RequiredBytes))
-    {
-        sz := ((req.CapacityRange.RequiredBytes+4095)/4096)*4096
-        _, err := invokeCLI(ctxVars, []string{ "modify", "--inc_size", "1", "--resize", fmt.Sprintf("%d", sz), volName })
-        if (err != nil)
-        {
-            return nil, err
-        }
-        inodeCfg, err = invokeList(ctxVars, volName, true)
-        if (err != nil)
-        {
-            return nil, err
-        }
-    }
-
-    return &csi.ControllerExpandVolumeResponse{
-        CapacityBytes: int64(inodeCfg[0].Size),
-        NodeExpansionRequired: false,
-    }, nil
+    return nil, status.Error(codes.Unimplemented, "")
 }

 // ControllerGetVolume get volume info
--- 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"
-    "syscall"
-    "time"
+    "bytes"

    "google.golang.org/grpc/codes"
    "google.golang.org/grpc/status"
@ -29,233 +25,55 @@ import (
 type NodeServer struct
 {
    *Driver
-    useVduse bool
-    stateDir string
    mounter mount.Interface
-    restartInterval time.Duration
-    mu sync.Mutex
-    cond *sync.Cond
-    volumeLocks map[string]bool
-}
-
-type DeviceState struct
-{
-    ConfigPath string `json:"configPath"`
-    VdpaId     string `json:"vdpaId"`
-    Image      string `json:"image"`
-    Blockdev   string `json:"blockdev"`
-    Readonly   bool   `json:"readonly"`
-    PidFile    string `json:"pidFile"`
 }

 // NewNodeServer create new instance node
 func NewNodeServer(driver *Driver) *NodeServer
 {
-    stateDir := os.Getenv("STATE_DIR")
-    if (stateDir == "")
-    {
-        stateDir = "/run/vitastor-csi"
-    }
-    if (stateDir[len(stateDir)-1] != '/')
-    {
-        stateDir += "/"
-    }
-    ns := &NodeServer{
+    return &NodeServer{
        Driver: driver,
-        useVduse: checkVduseSupport(),
-        stateDir: stateDir,
        mounter: mount.New(""),
-        volumeLocks: make(map[string]bool),
-    }
-    ns.cond = sync.NewCond(&ns.mu)
-    if (ns.useVduse)
-    {
-        ns.restoreVduseDaemons()
-        dur, err := time.ParseDuration(os.Getenv("RESTART_INTERVAL"))
-        if (err != nil)
-        {
-            dur = 10 * time.Second
-        }
-        ns.restartInterval = dur
-        if (ns.restartInterval != time.Duration(0))
-        {
-            go ns.restarter()
-        }
-    }
-    return ns
-}
-
-func (ns *NodeServer) lockVolume(lockId string)
-{
-    ns.mu.Lock()
-    defer ns.mu.Unlock()
-    for (ns.volumeLocks[lockId])
-    {
-        ns.cond.Wait()
-    }
-    ns.volumeLocks[lockId] = true
-    ns.cond.Broadcast()
-}
-
-func (ns *NodeServer) unlockVolume(lockId string)
-{
-    ns.mu.Lock()
-    defer ns.mu.Unlock()
-    delete(ns.volumeLocks, lockId)
-    ns.cond.Broadcast()
-}
-
-func (ns *NodeServer) restarter()
-{
-    // Restart dead VDUSE daemons at regular intervals
-    // Otherwise volume I/O may hang in case of a qemu-storage-daemon crash
-    // Moreover, it may lead to a kernel panic of the kernel is configured to
-    // panic on hung tasks
-    ticker := time.NewTicker(ns.restartInterval)
-    defer ticker.Stop()
-    for
-    {
-        <-ticker.C
-        ns.restoreVduseDaemons()
-    }
-}
-
-func (ns *NodeServer) restoreVduseDaemons()
-{
-    pattern := ns.stateDir+"vitastor-vduse-*.json"
-    matches, err := filepath.Glob(pattern)
-    if (err != nil)
-    {
-        klog.Errorf("failed to list %s: %v", pattern, err)
-    }
-    if (len(matches) == 0)
-    {
-        return
-    }
-    devList := make(map[string]interface{})
-    // example output: {"dev":{"test1":{"type":"block","mgmtdev":"vduse","vendor_id":0,"max_vqs":16,"max_vq_size":128}}}
-    devListJSON, _, err := system("/sbin/vdpa", "-j", "dev", "list")
-    if (err != nil)
-    {
-        return
-    }
-    err = json.Unmarshal(devListJSON, &devList)
-    devs, ok := devList["dev"].(map[string]interface{})
-    if (err != nil || !ok)
-    {
-        klog.Errorf("/sbin/vdpa -j dev list returned bad JSON (error %v): %v", err, string(devListJSON))
-        return
-    }
-    for _, stateFile := range matches
-    {
-        vdpaId := filepath.Base(stateFile)
-        vdpaId = vdpaId[0:len(vdpaId)-5]
-        // Check if VDPA device is still added to the bus
-        if (devs[vdpaId] == nil)
-        {
-            // Unused, clean it up
-            unmapVduseById(ns.stateDir, vdpaId)
-            continue
-        }
-
-        stateJSON, err := os.ReadFile(stateFile)
-        if (err != nil)
-        {
-            klog.Warningf("error reading state file %v: %v", stateFile, err)
-            continue
-        }
-        var state DeviceState
-        err = json.Unmarshal(stateJSON, &state)
-        if (err != nil)
-        {
-            klog.Warningf("state file %v contains invalid JSON (error %v): %v", stateFile, err, string(stateJSON))
-            continue
-        }
-
-        ns.lockVolume(state.ConfigPath+":"+state.Image)
-
-        // Recheck state file after locking
-        _, err = os.ReadFile(stateFile)
-        if (err != nil)
-        {
-            klog.Warningf("state file %v disappeared, skipping volume", stateFile)
-            ns.unlockVolume(state.ConfigPath+":"+state.Image)
-            continue
-        }
-
-        // Check if the storage daemon is still active
-        pidFile := ns.stateDir + vdpaId + ".pid"
-        exists := false
-        proc, err := findByPidFile(pidFile)
-        if (err == nil)
-        {
-            exists = proc.Signal(syscall.Signal(0)) == nil
-        }
-        if (!exists)
-        {
-            // Restart daemon
-            klog.Warningf("restarting storage daemon for volume %v (VDPA ID %v)", state.Image, vdpaId)
-            _ = startStorageDaemon(vdpaId, state.Image, pidFile, state.ConfigPath, state.Readonly)
-        }
-
-        ns.unlockVolume(state.ConfigPath+":"+state.Image)
    }
 }

 // NodeStageVolume mounts the volume to a staging path on the node.
 func (ns *NodeServer) NodeStageVolume(ctx context.Context, req *csi.NodeStageVolumeRequest) (*csi.NodeStageVolumeResponse, error)
 {
-    klog.Infof("received node stage volume request %+v", protosanitizer.StripSecrets(req))
-
-    ctxVars := make(map[string]string)
-    err := json.Unmarshal([]byte(req.VolumeId), &ctxVars)
-    if (err != nil)
-    {
-        return nil, status.Error(codes.Internal, "volume ID not in JSON format")
+    return &csi.NodeStageVolumeResponse{}, nil
 }
-    _, err = GetConnectionParams(ctxVars)
-    if (err != nil)
+
+// NodeUnstageVolume unstages the volume from the staging path
+func (ns *NodeServer) NodeUnstageVolume(ctx context.Context, req *csi.NodeUnstageVolumeRequest) (*csi.NodeUnstageVolumeResponse, error)
 {
-        return nil, err
+    return &csi.NodeUnstageVolumeResponse{}, nil
 }
-    volName := ctxVars["name"]

-    ns.lockVolume(ctxVars["configPath"]+":"+volName)
-    defer ns.unlockVolume(ctxVars["configPath"]+":"+volName)
+func Contains(list []string, s string) bool
+{
+    for i := 0; i < len(list); i++
+    {
+        if (list[i] == s)
+        {
+            return true
+        }
+    }
+    return false
+}

-    targetPath := req.GetStagingTargetPath()
+// 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()
    isBlock := req.GetVolumeCapability().GetBlock() != nil

    // Check that it's not already mounted
-    notmnt, err := mount.IsNotMountPoint(ns.mounter, targetPath)
-    if (err == nil)
+    _, error := mount.IsNotMountPoint(ns.mounter, targetPath)
+    if (error != nil)
    {
-        if (!notmnt)
-        {
-            klog.Errorf("target path %s is already mounted", targetPath)
-            return nil, fmt.Errorf("target path %s is already mounted", targetPath)
-        }
-        var finfo os.FileInfo
-        finfo, err = os.Stat(targetPath)
-        if (err != nil)
-        {
-            klog.Errorf("failed to stat %s: %v", targetPath, err)
-            return nil, err
-        }
-        if (finfo.IsDir() != (!isBlock))
-        {
-            err = os.Remove(targetPath)
-            if (err != nil)
-            {
-                klog.Errorf("failed to remove %s (to recreate it with correct type): %v", targetPath, err)
-                return nil, err
-            }
-            err = os.ErrNotExist
-        }
-    }
-    if (err != nil)
-    {
-        if (os.IsNotExist(err))
+        if (os.IsNotExist(error))
        {
            if (isBlock)
            {
@ -263,13 +81,13 @@ func (ns *NodeServer) NodeStageVolume(ctx context.Context, req *csi.NodeStageVol
                if (err != nil)
                {
                    klog.Errorf("failed to create block device mount target %s with error: %v", targetPath, err)
-                    return nil, err
+                    return nil, status.Error(codes.Internal, err.Error())
                }
                err = pathFile.Close()
                if (err != nil)
                {
                    klog.Errorf("failed to close %s with error: %v", targetPath, err)
-                    return nil, err
+                    return nil, status.Error(codes.Internal, err.Error())
                }
            }
            else
@ -278,44 +96,70 @@ func (ns *NodeServer) NodeStageVolume(ctx context.Context, req *csi.NodeStageVol
                if (err != nil)
                {
                    klog.Errorf("failed to create fs mount target %s with error: %v", targetPath, err)
-                    return nil, err
+                    return nil, status.Error(codes.Internal, err.Error())
                }
            }
        }
        else
        {
-            return nil, err
+            return nil, status.Error(codes.Internal, error.Error())
        }
    }

-    var devicePath, vdpaId string
-    if (!ns.useVduse)
-    {
-        devicePath, err = mapNbd(volName, ctxVars, false)
-    }
-    else
-    {
-        devicePath, vdpaId, err = mapVduse(ns.stateDir, volName, ctxVars, false)
-    }
+    ctxVars := make(map[string]string)
+    err := json.Unmarshal([]byte(req.VolumeId), &ctxVars)
    if (err != nil)
    {
-        return nil, err
+        return nil, status.Error(codes.Internal, "volume ID not in JSON format")
+    }
+    volName := ctxVars["name"]
+
+    _, etcdUrl, etcdPrefix := GetConnectionParams(ctxVars)
+    if (len(etcdUrl) == 0)
+    {
+        return nil, status.Error(codes.InvalidArgument, "no etcdUrl in storage class configuration and no etcd_address in vitastor.conf")
    }

-    diskMounter := &mount.SafeFormatAndMount{Interface: ns.mounter, Exec: utilexec.New()}
-    if (isBlock)
+    // Map NBD device
+    // FIXME: Check if already mapped
+    args := []string{
+        "map", "--etcd_address", strings.Join(etcdUrl, ","),
+        "--etcd_prefix", etcdPrefix,
+        "--image", volName,
+    };
+    if (ctxVars["configPath"] != "")
    {
-        klog.Infof("bind-mounting %s to %s", devicePath, targetPath)
-        err = diskMounter.Mount(devicePath, targetPath, "", []string{"bind"})
+        args = append(args, "--config_path", ctxVars["configPath"])
    }
-    else
+    if (req.GetReadonly())
    {
+        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)
+    {
+        klog.Errorf("vitastor-nbd map failed: %s, status %s\n", stdoutStr+stderrStr, err)
+        return nil, status.Error(codes.Internal, stdoutStr+stderrStr+" (status "+err.Error()+")")
+    }
+    devicePath := strings.TrimSpace(stdoutStr)
+
    // Check existing format
+    diskMounter := &mount.SafeFormatAndMount{Interface: ns.mounter, Exec: utilexec.New()}
    existingFormat, err := diskMounter.GetDiskFormat(devicePath)
    if (err != nil)
    {
        klog.Errorf("failed to get disk format for path %s, error: %v", err)
-            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)
@ -335,43 +179,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}
-                    _, err = systemCombined("mkfs.ext4", args...)
+                args = []string{"-m0", "-Enodiscard,lazy_itable_init=1,lazy_journal_init=1", devicePath}
            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 +218,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
-    }
-    return &csi.NodeStageVolumeResponse{}, nil
-
-unmap:
-    if (!ns.useVduse || len(devicePath) >= 8 && devicePath[0:8] == "/dev/nbd")
+        // unmap NBD device
+        unmapOut, unmapErr := exec.Command("/usr/bin/vitastor-nbd", "unmap", devicePath).CombinedOutput()
+        if (unmapErr != nil)
        {
-        unmapNbd(devicePath)
+            klog.Errorf("failed to unmap NBD device %s: %s, error: %v", devicePath, unmapOut, unmapErr)
        }
-    else
-    {
-        unmapVduseById(ns.stateDir, vdpaId)
+        return nil, status.Error(codes.Internal, err.Error())
    }
-    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 +233,35 @@ func (ns *NodeServer) NodePublishVolume(ctx context.Context, req *csi.NodePublis
 func (ns *NodeServer) NodeUnpublishVolume(ctx context.Context, req *csi.NodeUnpublishVolumeRequest) (*csi.NodeUnpublishVolumeResponse, error)
 {
    klog.Infof("received node unpublish volume request %+v", protosanitizer.StripSecrets(req))
-
-    ctxVars := make(map[string]string)
-    err := json.Unmarshal([]byte(req.VolumeId), &ctxVars)
-    if (err != nil)
-    {
-        return nil, status.Error(codes.Internal, "volume ID not in JSON format")
-    }
-    volName := ctxVars["name"]
-
-    ns.lockVolume(ctxVars["configPath"]+":"+volName)
-    defer ns.unlockVolume(ctxVars["configPath"]+":"+volName)
-
    targetPath := req.GetTargetPath()
-    devicePath, _, err := mount.GetDeviceNameFromMount(ns.mounter, targetPath)
+    devicePath, refCount, err := mount.GetDeviceNameFromMount(ns.mounter, targetPath)
    if (err != nil)
    {
        if (os.IsNotExist(err))
        {
            return nil, status.Error(codes.NotFound, "Target path not found")
        }
-        return nil, err
+        return nil, status.Error(codes.Internal, err.Error())
    }
    if (devicePath == "")
    {
-        // volume not mounted
-        klog.Warningf("%s is not a mountpoint, deleting", targetPath)
-        os.Remove(targetPath)
-        return &csi.NodeUnpublishVolumeResponse{}, nil
+        return nil, status.Error(codes.NotFound, "Volume not mounted")
    }
-
    // unmount
    err = mount.CleanupMountPoint(targetPath, ns.mounter, false)
    if (err != nil)
    {
-        return nil, err
+        return nil, status.Error(codes.Internal, err.Error())
+    }
+    // unmap NBD device
+    if (refCount == 1)
+    {
+        unmapOut, unmapErr := exec.Command("/usr/bin/vitastor-nbd", "unmap", devicePath).CombinedOutput()
+        if (unmapErr != nil)
+        {
+            klog.Errorf("failed to unmap NBD device %s: %s, error: %v", devicePath, unmapOut, unmapErr)
+        }
    }
-
    return &csi.NodeUnpublishVolumeResponse{}, nil
 }

@ -618,17 +280,7 @@ func (ns *NodeServer) NodeExpandVolume(ctx context.Context, req *csi.NodeExpandV
 // NodeGetCapabilities returns the supported capabilities of the node server
 func (ns *NodeServer) NodeGetCapabilities(ctx context.Context, req *csi.NodeGetCapabilitiesRequest) (*csi.NodeGetCapabilitiesResponse, error)
 {
-    return &csi.NodeGetCapabilitiesResponse{
-        Capabilities: []*csi.NodeServiceCapability{
-            &csi.NodeServiceCapability{
-                Type: &csi.NodeServiceCapability_Rpc{
-                    Rpc: &csi.NodeServiceCapability_RPC{
-                        Type: csi.NodeServiceCapability_RPC_STAGE_UNSTAGE_VOLUME,
-                    },
-                },
-            },
-        },
-    }, nil
+    return &csi.NodeGetCapabilitiesResponse{}, nil
 }

 // NodeGetInfo returns NodeGetInfoResponse for CO.
--- 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,10 +1,10 @@
-vitastor (1.9.3-1) unstable; urgency=medium
+vitastor (0.8.6-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
+vitastor (0.8.6-1) unstable; urgency=medium

  * Implement NFS proxy
  * Add documentation
--- 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, libisal-dev
 Standards-Version: 4.5.0
 Homepage: https://vitastor.io/
 Rules-Requires-Root: no
@ -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/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 src/client/qemu_driver.c /root/qemu_driver.c
-
-#RUN set -e; \
-#    apt-get install -y wget; \
-#    wget -q -O /etc/apt/trusted.gpg.d/vitastor.gpg https://vitastor.io/debian/pubkey.gpg; \
-#    (echo deb http://vitastor.io/debian $REL main > /etc/apt/sources.list.d/vitastor.list); \
-#    (echo "APT::Install-Recommends false;" > /etc/apt/apt.conf) && \
-#    apt-get update; \
-#    apt-get install -y vitastor-client vitastor-client-dev quilt
-
+ADD patches/qemu-5.0-vitastor.patch patches/qemu-5.1-vitastor.patch patches/qemu-6.1-vitastor.patch src/qemu_driver.c /root/vitastor/patches/
 RUN set -e; \
-    dpkg -i /root/packages/vitastor-$REL/vitastor-client_*.deb /root/packages/vitastor-$REL/vitastor-client-dev_*.deb; \
+    apt-get install -y wget; \
+    wget -q -O /etc/apt/trusted.gpg.d/vitastor.gpg https://vitastor.io/debian/pubkey.gpg; \
+    (echo deb http://vitastor.io/debian $REL main > /etc/apt/sources.list.d/vitastor.list); \
+    (echo "APT::Install-Recommends false;" > /etc/apt/apt.conf) && \
    apt-get update; \
-    apt-get install -y quilt; \
+    apt-get install -y vitastor-client vitastor-client-dev quilt; \
    mkdir -p /root/packages/qemu-$REL; \
    rm -rf /root/packages/qemu-$REL/*; \
    cd /root/packages/qemu-$REL; \
    dpkg-source -x /root/qemu*.dsc; \
-    QEMU_VER=$(ls -d qemu*/ | perl -pe 's!^.*?(\d+\.\d+).*!$1!'); \
-    D=$(ls -d qemu*/); \
-    cp /root/vitastor/patches/qemu-$QEMU_VER-vitastor.patch ./qemu-*/debian/patches; \
-    echo qemu-$QEMU_VER-vitastor.patch >> $D/debian/patches/series; \
+    if ls -d /root/packages/qemu-$REL/qemu-5.0*; then \
+        D=$(ls -d /root/packages/qemu-$REL/qemu-5.0*); \
+        cp /root/vitastor/patches/qemu-5.0-vitastor.patch $D/debian/patches; \
+        echo qemu-5.0-vitastor.patch >> $D/debian/patches/series; \
+    elif ls /root/packages/qemu-$REL/qemu-6.1*; then \
+        D=$(ls -d /root/packages/qemu-$REL/qemu-6.1*); \
+        cp /root/vitastor/patches/qemu-6.1-vitastor.patch $D/debian/patches; \
+        echo qemu-6.1-vitastor.patch >> $D/debian/patches/series; \
+    else \
+        cp /root/vitastor/patches/qemu-5.1-vitastor.patch /root/packages/qemu-$REL/qemu-*/debian/patches; \
+        P=`ls -d /root/packages/qemu-$REL/qemu-*/debian/patches`; \
+        echo qemu-5.1-vitastor.patch >> $P/series; \
+    fi; \
    cd /root/packages/qemu-$REL/qemu-*/; \
    quilt push -a; \
    quilt add block/vitastor.c; \
-    cp /root/qemu_driver.c block/vitastor.c; \
+    cp /root/vitastor/patches/qemu_driver.c block/vitastor.c; \
    quilt refresh; \
-    V=$(head -n1 debian/changelog | perl -pe 's/5\.2\+dfsg-9/5.2+dfsg-11/; s/^.*\((.*?)(~bpo[\d\+]*)?\).*$/$1/')+vitastor4; \
-    if [ "$REL" = bullseye ]; then V=${V}bullseye; fi; \
+    V=$(head -n1 debian/changelog | perl -pe 's/^.*\((.*?)(~bpo[\d\+]*)?\).*$/$1/')+vitastor1; \
    DEBEMAIL="Vitaliy Filippov <vitalif@yourcmc.ru>" dch -D $REL -v $V 'Plug Vitastor block driver'; \
    DEB_BUILD_OPTIONS=nocheck dpkg-buildpackage --jobs=auto -sa; \
    rm -rf /root/packages/qemu-$REL/qemu-*/
--- a/debian/vitastor-client.install
+++ b/debian/vitastor-client.install
@ -3,6 +3,4 @@ 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*
--- a/debian/vitastor-mon.install
+++ b/debian/vitastor-mon.install
@ -1,3 +1,2 @@
-mon usr/lib/vitastor/
-mon/scripts/make-etcd usr/lib/vitastor/mon
-mon/scripts/vitastor-mon.service /lib/systemd/system
+mon usr/lib/vitastor
+mon/vitastor-mon.service /lib/systemd/system
--- a/debian/vitastor-mon.postinst
+++ b/debian/vitastor-mon.postinst
@ -6,6 +6,4 @@ 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,6 @@
 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
+mon/vitastor-osd@.service /lib/systemd/system
+mon/vitastor.target /lib/systemd/system
+mon/90-vitastor.rules /lib/udev/rules.d
--- a/debian/vitastor.Dockerfile
+++ b/debian/vitastor.Dockerfile
@ -1,30 +1,28 @@
-# Build Vitastor packages for Debian inside a container
-# cd ..; podman build --build-arg DISTRO=debian --build-arg REL=bullseye -v `pwd`/packages:/root/packages -f debian/vitastor.Dockerfile .
+# Build Vitastor packages for Debian Buster or Bullseye/Sid inside a container
+# cd ..; podman build --build-arg REL=bullseye -v `pwd`/packages:/root/packages -f debian/vitastor.Dockerfile .

-ARG DISTRO=debian
 ARG REL=
-FROM $DISTRO:$REL
-ARG DISTRO=debian
+FROM debian:$REL
 ARG REL=

 WORKDIR /root

-RUN set -e -x; \
-    if [ "$REL" = "buster" ]; then \
-        apt-get update; \
-        apt-get -y install wget; \
-        wget https://vitastor.io/debian/pubkey.gpg -O /etc/apt/trusted.gpg.d/vitastor.gpg; \
-        echo "deb https://vitastor.io/debian $REL main" >> /etc/apt/sources.list; \
+RUN if [ "$REL" = "buster" -o "$REL" = "bullseye" ]; then \
+        echo "deb http://deb.debian.org/debian $REL-backports main" >> /etc/apt/sources.list; \
+        echo >> /etc/apt/preferences; \
+        echo 'Package: *' >> /etc/apt/preferences; \
+        echo "Pin: release a=$REL-backports" >> /etc/apt/preferences; \
+        echo 'Pin-Priority: 500' >> /etc/apt/preferences; \
    fi; \
    grep '^deb ' /etc/apt/sources.list | perl -pe 's/^deb/deb-src/' >> /etc/apt/sources.list; \
-    perl -i -pe 's/Types: deb$/Types: deb deb-src/' /etc/apt/sources.list.d/debian.sources || true; \
    echo 'APT::Install-Recommends false;' >> /etc/apt/apt.conf; \
    echo 'APT::Install-Suggests false;' >> /etc/apt/apt.conf

 RUN apt-get update
-RUN apt-get -y install fio liburing-dev libgoogle-perftools-dev devscripts libjerasure-dev cmake libibverbs-dev libisal-dev libnl-3-dev libnl-genl-3-dev curl
+RUN apt-get -y install fio liburing1 liburing-dev libgoogle-perftools-dev devscripts
 RUN apt-get -y build-dep fio
 RUN apt-get --download-only source fio
+RUN apt-get update && apt-get -y install libjerasure-dev cmake libibverbs-dev libisal-dev

 ADD . /root/vitastor
 RUN set -e -x; \
@ -36,10 +34,8 @@ RUN set -e -x; \
    mkdir -p /root/packages/vitastor-$REL; \
    rm -rf /root/packages/vitastor-$REL/*; \
    cd /root/packages/vitastor-$REL; \
-    FULLVER=$(head -n1 /root/vitastor/debian/changelog | perl -pe 's/^.*\((.*?)\).*$/$1/'); \
-    VER=${FULLVER%%-*}; \
-    cp -r /root/vitastor vitastor-$VER; \
-    cd vitastor-$VER; \
+    cp -r /root/vitastor vitastor-0.8.6; \
+    cd vitastor-0.8.6; \
    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 +47,10 @@ RUN set -e -x; \
    echo fio-headers.patch >> debian/patches/series; \
    rm -rf a b; \
    echo "dep:fio=$FIO" > debian/fio_version; \
-    cd /root/packages/vitastor-$REL/vitastor-$VER; \
-    mkdir mon/node_modules; \
-    cd mon/node_modules; \
-    curl -s https://git.yourcmc.ru/vitalif/antietcd/archive/master.tar.gz | tar -zx; \
-    curl -s https://git.yourcmc.ru/vitalif/tinyraft/archive/master.tar.gz | tar -zx; \
    cd /root/packages/vitastor-$REL; \
-    tar --sort=name --mtime='2020-01-01' --owner=0 --group=0 --exclude=debian -cJf vitastor_$VER.orig.tar.xz vitastor-$VER; \
-    cd vitastor-$VER; \
-    DEBFULLNAME="Vitaliy Filippov <vitalif@yourcmc.ru>" dch -D $REL -v "$FULLVER""$REL" "Rebuild for $REL"; \
+    tar --sort=name --mtime='2020-01-01' --owner=0 --group=0 --exclude=debian -cJf vitastor_0.8.6.orig.tar.xz vitastor-0.8.6; \
+    cd vitastor-0.8.6; \
+    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
@ -17,23 +17,20 @@ 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.
+- Command line of Vitastor components: OSD, mon, fio and QEMU options,
+  OpenStack/Proxmox/etc configuration. The latter doesn't allow to set all
+  variables directly, but it allows to override the configuration file and
+  set everything you need inside it.

 In the future, additional configuration methods may be added:
+- OSD superblock which will, by design, contain parameters related to the disk
+  layout and to one specific OSD.
 - OSD-specific keys in etcd like `/vitastor/config/osd/<number>`.

 ## Parameter Reference

 - [Common](config/common.en.md)
 - [Network](config/network.en.md)
- [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)
--- a/docs/config.ru.md
+++ b/docs/config.ru.md
@ -19,24 +19,20 @@
 - Ключе в 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.
+- В командной строке компонентов Vitastor: OSD, монитора, опциях fio и QEMU,
+  настроек OpenStack, Proxmox и т.п. Последние, как правило, не включают полный
+  набор параметров напрямую, но разрешают определить путь к файлу конфигурации
+  и задать любые параметры в нём.

 В будущем также могут быть добавлены другие способы конфигурации:
+- Суперблок OSD, в котором будут храниться параметры 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)
--- 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
@ -25,16 +25,11 @@ 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
@ -47,6 +42,5 @@ example, use a single etcd cluster for multiple Vitastor clusters.

 - 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
@ -24,14 +24,10 @@
 ## etcd_address

 - Тип: строка или массив строк
- Можно менять на лету: да

 Адрес(а) подключения к etcd. Несколько адресов могут разделяться запятой
 или указываться в виде JSON-массива `["10.0.115.10:2379/v3","10.0.115.11:2379/v3"]`.

-Адреса подключения к etcd можно поменять на лету, обновив конфигурацию в
-самом etcd - это позволяет переключить кластер на новые etcd без остановки.
-
 ## etcd_prefix

 - Тип: строка
@ -45,6 +41,5 @@

 - Тип: целое число
 - Значение по умолчанию: 0
- Можно менять на лету: да

 Уровень логгирования. Повысьте, если хотите более подробный вывод.
--- a/docs/config/layout-cluster.en.md
+++ b/docs/config/layout-cluster.en.md
@ -33,13 +33,12 @@ Size of objects (data blocks) into which all physical and virtual drives
 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
+Recommended default block size is 128 KB for SSD and 4 MB for HDD. In fact,
+it's possible to use 4 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

@ -56,24 +55,14 @@ Can't be smaller than the OSD data device sector.
 ## immediate_commit

 - Type: string
- Default: all
+- Default: false

-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:
+Another parameter which is really important for performance.

 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.
+if you try to fsync() each write, that is, when you want to guarantee that
+each change gets immediately 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
@ -85,8 +74,8 @@ 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
+This is what this parameter regulates. When it's set to "all" the whole
+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
@ -106,8 +95,11 @@ 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".
+disable_journal_fsync and disable_meta_fsync, setting it to "all" also requires
+enabling disable_data_fsync.
+
+TLDR: For optimal performance, set immediate_commit to "all" if you only use
+SSDs with supercapacitor-based power loss protection (nonvolatile
+write-through cache) for both data and journals in the whole Vitastor
+cluster. Set it to "small" if you only use such SSDs for journals. Leave
+empty if your drives have write-back cache.
--- a/docs/config/layout-cluster.ru.md
+++ b/docs/config/layout-cluster.ru.md
@ -33,14 +33,14 @@ OSD) могут сосуществовать в одном кластере Vita
 настроек, влияет на потребление памяти, объём избыточной записи (write
 amplification) и эффективность распределения нагрузки по OSD.

-Рекомендуемые по умолчанию размеры блока - 128 килобайт для SSD и 1 мегабайт
-для HDD. В принципе, для SSD можно тоже использовать блок размером 1 мегабайт,
+Рекомендуемые по умолчанию размеры блока - 128 килобайт для SSD и 4
+мегабайта для HDD. В принципе, для SSD можно тоже использовать 4 мегабайта,
 это понизит использование памяти, но ухудшит распределение нагрузки и в
 среднем увеличит WA.

 Потребление памяти OSD составляет примерно (РАЗМЕР / БЛОК * 68 байт),
 т.е. примерно 544 МБ памяти на 1 ТБ занятого места на диске при
-стандартном 128 КБ блоке. При 1 МБ блоке памяти нужно в 8 раз меньше.
+стандартном 128 КБ блоке.

 ## bitmap_granularity

@ -57,18 +57,9 @@ amplification) и эффективность распределения нагр
 ## immediate_commit

 - Тип: строка
- Значение по умолчанию: all
+- Значение по умолчанию: false

-Одно из значений "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+ операций в
 секунду) при простой случайной записи без сбросов кэша. Однако они очень
@ -89,7 +80,7 @@ Power Loss Protection" - одинаково быстрые и со сбросо
 эффективно утилизировать настольные SSD.

 Данный параметр влияет как раз на это. Когда он установлен в значение "all",
-кластер Vitastor мгновенно фиксирует каждое изменение на физические
+весь кластер Vitastor мгновенно фиксирует каждое изменение на физические
 носители и клиенты могут просто игнорировать запросы fsync, т.к. они точно
 знают, что fsync-и не нужны. Это уменьшает число необходимых обращений к OSD
 по сети и улучшает производительность. Поэтому даже с Vitastor лучше всегда
@ -112,6 +103,12 @@ HDD-дисках с внутренним 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).
+включения disable_journal_fsync и disable_meta_fsync, значение "all" также
+требует включения disable_data_fsync.
+
+Итого, вкратце: для оптимальной производительности установите
+immediate_commit в значение "all", если вы используете в кластере только SSD
+с суперконденсаторами и для данных, и для журналов. Если вы используете
+такие SSD для всех журналов, но не для данных - можете установить параметр
+в "small". Если и какие-то из дисков журналов имеют волатильный кэш записи -
+оставьте параметр пустым.
--- a/docs/config/layout-osd.en.md
+++ b/docs/config/layout-osd.en.md
@ -24,8 +24,6 @@ initialization and can't be changed after it without losing data.
 - [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

@ -118,13 +116,12 @@ Physical block size of the journal device. Must be a multiple of
 - 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.
+Do not issue fsyncs to the data device, i.e. do not flush its cache.
+Safe ONLY if your data device has write-through cache. If you disable
+the cache yourself using `hdparm` or `scsi_disk/cache_type` then make sure
+that the cache disable command is run every time before starting Vitastor
+OSD, for example, in the systemd unit. See also `immediate_commit` option
+for the instructions to disable cache and how to benefit from it.

 ## disable_meta_fsync

@ -172,47 +169,8 @@ 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...
+and meta_block_size. But the only SSD that may fit into this category is
+Intel Optane (probably, not tested yet).

 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
@ -25,8 +25,6 @@
 - [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

@ -122,14 +120,13 @@ SSD-диске, иначе производительность пострада
 - Тип: булево (да/нет)
 - Значение по умолчанию: false

-Не отправлять fsync-и устройству данных, т.е. не заставлять его сбрасывать кэш.
+Не отправлять fsync-и устройству данных, т.е. не сбрасывать его кэш.
 Безопасно, ТОЛЬКО если ваше устройство данных имеет кэш со сквозной
-записью (write-through) или если кэш с отложенной записью (write-back) отключён.
-Если вы отключаете кэш вручную через `hdparm` или запись в `/sys/.../scsi_disk/cache_type`,
-то удостоверьтесь, что вы делаете это каждый раз перед запуском Vitastor OSD
-(vitastor-disk делает это автоматически). Смотрите также опцию
-[immediate_commit](layout-cluster.ru.md#immediate_commit) для информации о том,
-как извлечь выгоду из отключённого кэша.
+записью (write-through). Если вы отключаете кэш через `hdparm` или
+`scsi_disk/cache_type`, то удостоверьтесь, что команда отключения кэша
+выполняется перед каждым запуском Vitastor OSD, например, в systemd unit-е.
+Смотрите также опцию `immediate_commit` для инструкций по отключению кэша
+и о том, как из этого извлечь выгоду.

 ## disable_meta_fsync

@ -180,52 +177,9 @@ SSD и HDD диски используют 4 КБ физические сект

 Поэтому, на самом деле, может быть выгодно найти SSD, хорошо работающие с
 меньшими, 512-байтными, блоками и использовать 512-байтные disk_alignment,
-journal_block_size и meta_block_size. Однако на данный момент такие SSD
-не известны...
+journal_block_size и meta_block_size. Однако единственные SSD, которые
+теоретически могут попасть в эту категорию - это Intel Optane (но и это
+пока не проверялось автором).

 Клиентам не обязательно знать про 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
@ -8,14 +8,6 @@

 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)
@ -23,94 +15,12 @@ These parameters only apply to Monitors.
 - [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
+- Default: 30
+- Minimum: 10

 Monitor etcd lease refresh interval in seconds

@ -167,11 +77,3 @@ values.  Smaller priority means higher level in tree. For example,
 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
@ -8,14 +8,6 @@

 Данные параметры используются только мониторами 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)
@ -23,96 +15,12 @@
 - [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
+- Значение по умолчанию: 30
+- Минимальное значение: 10

 Интервал обновления etcd резервации (lease) монитором

@ -170,11 +78,3 @@ 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
@ -20,16 +20,17 @@ between clients, OSDs and etcd.
 - [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)
+- [up_wait_retry_interval](#up_wait_retry_interval)
 - [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)
+- [etcd_ws_keepalive_timeout](#etcd_ws_keepalive_timeout)
+- [client_dirty_limit](#client_dirty_limit)

 ## tcp_header_buffer_size

@ -68,20 +69,11 @@ but they are not connected to the cluster.
 - 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.
+"rocep5s0f0"). Please note that Vitastor RDMA requires Implicit On-Demand
+Paging (Implicit ODP) and Scatter/Gather (SG) support from the RDMA device
+to work. For example, Mellanox ConnectX-3 and older adapters don't have
+Implicit ODP, so they're unsupported by Vitastor. 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
@ -101,17 +93,15 @@ your device has.
 ## rdma_gid_index

 - Type: integer
+- Default: 0

 Global address identifier index of the RDMA device to use. Different GID
 indexes may correspond to different protocols like RoCEv1, RoCEv2 and iWARP.
 Search for "GID" in `ibv_devinfo -v` output to determine which GID index
 you need.

-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).
+**IMPORTANT:** If you want to use RoCEv2 (as recommended) then the correct
+rdma_gid_index is usually 1 (IPv6) or 3 (IPv4).

 ## rdma_mtu

@ -158,34 +148,11 @@ 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.

@ -194,7 +161,6 @@ Interval before attempting to reconnect to an unavailable OSD.
 - Type: seconds
 - Default: 5
 - Minimum: 1
- Can be changed online: yes

 Timeout for OSD connection attempts.

@ -203,7 +169,6 @@ Timeout for OSD connection attempts.
 - 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.
@ -213,17 +178,25 @@ keepalive requests to check state of the connection.
 - 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.

+## up_wait_retry_interval
+
+- Type: milliseconds
+- Default: 500
+- Minimum: 50
+
+OSDs respond to clients with a special error code when they receive I/O
+requests for a PG that's not synchronized and started. This parameter sets
+the time for the clients to wait before re-attempting such I/O requests.
+
 ## 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.
@ -232,7 +205,6 @@ indefinitely.

 - Type: milliseconds
 - Default: 1000
- Can be changed online: yes

 Timeout for etcd requests which should complete quickly, like lease refresh.

@ -240,7 +212,6 @@ Timeout for etcd requests which should complete quickly, like lease refresh.

 - Type: milliseconds
 - Default: 5000
- Can be changed online: yes

 Timeout for etcd requests which are allowed to wait for some time.

@ -248,16 +219,27 @@ Timeout for etcd requests which are allowed to wait for some time.

 - 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
+## etcd_ws_keepalive_timeout

 - Type: seconds
- Default: 5
- Can be changed online: yes
+- Default: 30

 etcd websocket ping interval required to keep the connection alive and
 detect disconnections quickly.
+
+## client_dirty_limit
+
+- Type: integer
+- Default: 33554432
+
+Without 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.
+
+This parameter doesn't affect OSDs themselves.
--- a/docs/config/network.ru.md
+++ b/docs/config/network.ru.md
@ -20,16 +20,17 @@
 - [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)
+- [up_wait_retry_interval](#up_wait_retry_interval)
 - [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)
+- [etcd_ws_keepalive_timeout](#etcd_ws_keepalive_timeout)
+- [client_dirty_limit](#client_dirty_limit)

 ## tcp_header_buffer_size

@ -71,20 +72,12 @@ RDMA может быть нужно только если у клиентов е
 - Тип: строка

 Название 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-устройств, их параметры и возможности.
+Имейте в виду, что поддержка RDMA в Vitastor требует функций устройства
+Implicit On-Demand Paging (Implicit ODP) и Scatter/Gather (SG). Например,
+адаптеры Mellanox ConnectX-3 и более старые не поддерживают Implicit ODP и
+потому не поддерживаются в Vitastor. Запустите `ibv_devinfo -v` от имени
+суперпользователя, чтобы посмотреть список доступных RDMA-устройств, их
+параметры и возможности.

 Обратите внимание, что если вы используете RoCE/RoCEv2, вам также необходимо
 правильно настроить для него коммутаторы, иначе вы можете столкнуться с
@ -106,18 +99,15 @@ Control) и ECN (Explicit Congestion Notification).
 ## rdma_gid_index

 - Тип: целое число
+- Значение по умолчанию: 0

 Номер глобального идентификатора адреса 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).
+**ВАЖНО:** Если вы хотите использовать RoCEv2 (как мы и рекомендуем), то
+правильный rdma_gid_index, как правило, 1 (IPv6) или 3 (IPv4).

 ## rdma_mtu

@ -166,35 +156,11 @@ OSD в любом случае согласовывают реальное зн
 Не влияет на потребление памяти - дополнительная память на операции отправки
 не выделяется.

-## 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.

@ -203,7 +169,6 @@ OSD в любом случае согласовывают реальное зн
 - Тип: секунды
 - Значение по умолчанию: 5
 - Минимальное значение: 1
- Можно менять на лету: да

 Максимальное время ожидания попытки соединения с OSD.

@ -212,7 +177,6 @@ OSD в любом случае согласовывают реальное зн
 - Тип: секунды
 - Значение по умолчанию: 5
 - Минимальное значение: 1
- Можно менять на лету: да

 Время неактивности соединения с OSD, после которого клиенты или другие OSD
 посылают запрос проверки состояния соединения.
@ -222,17 +186,27 @@ OSD в любом случае согласовывают реальное зн
 - Тип: секунды
 - Значение по умолчанию: 5
 - Минимальное значение: 1
- Можно менять на лету: да

 Максимальное время ожидания ответа на запрос проверки состояния соединения.
 Если OSD не отвечает за это время, соединение отключается и производится
 повторная попытка соединения.

+## up_wait_retry_interval
+
+- Тип: миллисекунды
+- Значение по умолчанию: 500
+- Минимальное значение: 50
+
+Когда OSD получают от клиентов запросы ввода-вывода, относящиеся к не
+поднятым на данный момент на них PG, либо к PG в процессе синхронизации,
+они отвечают клиентам специальным кодом ошибки, означающим, что клиент
+должен некоторое время подождать перед повторением запроса. Именно это время
+ожидания задаёт данный параметр.
+
 ## max_etcd_attempts

 - Тип: целое число
 - Значение по умолчанию: 5
- Можно менять на лету: да

 Максимальное число попыток выполнения запросов к etcd для тех запросов,
 которые нельзя повторять бесконечно.
@ -241,7 +215,6 @@ OSD в любом случае согласовывают реальное зн

 - Тип: миллисекунды
 - Значение по умолчанию: 1000
- Можно менять на лету: да

 Максимальное время выполнения запросов к etcd, которые должны завершаться
 быстро, таких, как обновление резервации (lease).
@ -250,7 +223,6 @@ OSD в любом случае согласовывают реальное зн

 - Тип: миллисекунды
 - Значение по умолчанию: 5000
- Можно менять на лету: да

 Максимальное время выполнения запросов к etcd, для которых не обязательно
 гарантировать быстрое выполнение.
@ -259,15 +231,26 @@ OSD в любом случае согласовывают реальное зн

 - Тип: секунды
 - Значение по умолчанию: max(30, etcd_report_interval*2)
- Можно менять на лету: да

 Таймаут для HTTP Keep-Alive в соединениях к etcd. Должен быть больше, чем
 etcd_report_interval, чтобы keepalive гарантированно работал.

-## etcd_ws_keepalive_interval
+## etcd_ws_keepalive_timeout

 - Тип: секунды
- Значение по умолчанию: 5
- Можно менять на лету: да
+- Значение по умолчанию: 30

 Интервал проверки живости вебсокет-подключений к etcd.
+
+## client_dirty_limit
+
+- Тип: целое число
+- Значение по умолчанию: 33554432
+
+При работе без immediate_commit=all - это лимит объёма "грязных" (не
+зафиксированных fsync-ом) данных, при достижении которого клиент будет
+принудительно вызывать fsync и фиксировать данные. Также стоит иметь в виду,
+что в этом случае до момента fsync клиент хранит копию незафиксированных
+данных в памяти, то есть, настройка влияет на потребление памяти клиентами.
+
+Параметр не влияет на сами OSD.
--- a/docs/config/osd.en.md
+++ b/docs/config/osd.en.md
@ -7,12 +7,9 @@
 # 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.
+initialization and can be changed with an OSD restart.

- [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)
@ -20,7 +17,6 @@ them, even without restarting by updating configuration in etcd.
 - [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)
@ -34,9 +30,6 @@ them, even without restarting by updating configuration in etcd.
 - [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)
@ -45,55 +38,17 @@ them, even without restarting by updating configuration in etcd.
 - [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
+Interval at which OSDs report their state 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
@ -136,7 +91,6 @@ OSD by hand.

 - 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
@ -149,7 +103,6 @@ issue fsyncs at all.

 - 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.
@ -157,30 +110,16 @@ operations before issuing an fsync operation internally.
 ## recovery_queue_depth

 - Type: integer
- Default: 1
- Can be changed online: yes
+- Default: 4

-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.
+Maximum recovery operations per one primary OSD at any given moment of time.
+Currently it's the only parameter available to tune the speed or recovery
+and rebalancing, but it's planned to implement more.

 ## 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
@ -191,7 +130,6 @@ Degraded PGs are anyway scanned first.

 - Type: integer
 - Default: 16
- Can be changed online: yes

 Maximum number of recovery operations before issuing an additional fsync.

@ -207,7 +145,6 @@ the underlying device. This may be useful for recovery purposes.

 - 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
@ -217,7 +154,6 @@ always made to a full set of at least pg_minsize OSDs.

 - 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.
@ -226,7 +162,6 @@ means that PGs in the `has_misplaced` state will be left in it indefinitely.

 - Type: seconds
 - Default: 3
- Can be changed online: yes

 Time interval at which OSDs print simple human-readable operation
 statistics on stdout.
@ -235,7 +170,6 @@ statistics on stdout.

 - 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
@ -245,7 +179,6 @@ they're any. Also it's the time after which an operation is considered

 - Type: seconds
 - Default: 60
- Can be changed online: yes

 Number of seconds after which a deleted inode is removed from OSD statistics.

@ -253,7 +186,6 @@ Number of seconds after which a deleted inode is removed from OSD statistics.

 - 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
@ -263,7 +195,6 @@ immediately.

 - 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.
@ -273,7 +204,6 @@ Minimum number is set by this parameter.

 - Type: integer
 - Default: 256
- Can be changed online: yes

 Maximum number of journal flushers (see above min_flusher_count).

@ -303,60 +233,6 @@ 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
@ -384,7 +260,6 @@ Most (99%) other SSDs don't need this option.

 - 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
@ -402,7 +277,6 @@ fills up.

 - 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
@ -412,7 +286,6 @@ of full journal. Set it to approximate random write iops of your data devices

 - 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
@ -422,7 +295,6 @@ performance of your data devices (HDDs).

 - 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
@ -432,7 +304,6 @@ devices (1 for HDDs, 4-8 for SSDs).

 - 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.
@ -442,190 +313,4 @@ doesn't need to be changed.
 - 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.
+Lock all OSD memory to prevent it from being unloaded into swap with mlockall(). Requires sufficient ulimit -l (max locked memory).
--- a/docs/config/osd.ru.md
+++ b/docs/config/osd.ru.md
@ -8,12 +8,9 @@

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

- [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)
@ -21,7 +18,6 @@
 - [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)
@ -35,9 +31,6 @@
 - [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)
@ -46,56 +39,17 @@
 - [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 обновляет своё состояние в etcd. Значение параметра
+влияет на время резервации (lease) OSD и поэтому на скорость переключения
 при падении OSD. Время lease равняется значению этого параметра плюс
 max_etcd_attempts * etcd_quick_timeout.

-## etcd_stats_interval
-
- Тип: секунды
- Значение по умолчанию: 30
-
-Интервал, с которым OSD обновляет свою статистику в etcd. Сильно влияет на
-создаваемую нагрузку на etcd, потому что статистика содержит по ключу на
-каждый OSD и на каждую PG. В то же время низкий интервал делает
-статистику, печатаемую `vitastor-cli`, отзывчивей.
-
 ## run_primary

 - Тип: булево (да/нет)
@ -139,7 +93,6 @@ RUNNING), подходящий под заданную маску. Также н

 - Тип: секунды
 - Значение по умолчанию: 5
- Можно менять на лету: да

 Временной интервал отправки автоматических fsync-ов (операций очистки кэша)
 каждым OSD для случая, когда режим immediate_commit отключён. fsync-и нужны
@ -152,7 +105,6 @@ OSD, чтобы успевать очищать журнал - без них OSD

 - Тип: целое число
 - Значение по умолчанию: 128
- Можно менять на лету: да

 Аналогично autosync_interval, но задаёт не временной интервал, а
 максимальное количество незафиксированных операций записи перед
@ -161,31 +113,17 @@ OSD, чтобы успевать очищать журнал - без них OSD
 ## recovery_queue_depth

 - Тип: целое число
- Значение по умолчанию: 1
- Можно менять на лету: да
+- Значение по умолчанию: 4

-Максимальное число параллельных операций восстановления, инициируемых одним
-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.
+Максимальное число операций восстановления на одном первичном OSD в любой
+момент времени. На данный момент единственный параметр, который можно менять
+для ускорения или замедления восстановления и перебалансировки данных, но
+в планах реализация других параметров.

 ## recovery_pg_switch

 - Тип: целое число
 - Значение по умолчанию: 128
- Можно менять на лету: да

 Число операций восстановления перед переключением на восстановление другой PG.
 Идея заключается в том, чтобы восстанавливать все PG одновременно для более
@ -197,7 +135,6 @@ client I/O.

 - Тип: целое число
 - Значение по умолчанию: 16
- Можно менять на лету: да

 Максимальное число операций восстановления перед дополнительным fsync.

@ -213,7 +150,6 @@ client I/O.

 - Тип: булево (да/нет)
 - Значение по умолчанию: false
- Можно менять на лету: да

 Отключить автоматическое фоновое восстановление объектов. Обратите внимание,
 что эта опция не отключает восстановление объектов, происходящее при
@ -224,7 +160,6 @@ OSD.

 - Тип: булево (да/нет)
 - Значение по умолчанию: false
- Можно менять на лету: да

 Отключить фоновое перемещение объектов между разными OSD. Отключение
 означает, что PG, находящиеся в состоянии `has_misplaced`, будут оставлены
@ -234,7 +169,6 @@ OSD.

 - Тип: секунды
 - Значение по умолчанию: 3
- Можно менять на лету: да

 Временной интервал, с которым OSD печатают простую человекочитаемую
 статистику выполнения операций в стандартный вывод.
@ -243,7 +177,6 @@ OSD.

 - Тип: секунды
 - Значение по умолчанию: 10
- Можно менять на лету: да

 Временной интервал, с которым OSD выводят в стандартный вывод список
 медленных или зависших операций, если таковые имеются. Также время, при
@ -253,7 +186,6 @@ OSD.

 - Тип: секунды
 - Значение по умолчанию: 60
- Можно менять на лету: да

 Число секунд, через которое удалённые инод удаляется и из статистики OSD.

@ -261,7 +193,6 @@ OSD.

 - Тип: целое число
 - Значение по умолчанию: 128
- Можно менять на лету: да

 Максимальное число одновременных клиентских операций записи на один OSD.
 Операции, превышающие этот лимит, не исполняются сразу, а сохраняются во
@ -271,7 +202,6 @@ OSD.

 - Тип: целое число
 - Значение по умолчанию: 1
- Можно менять на лету: да

 Flusher - это микро-поток (корутина), которая копирует данные из журнала в
 основную область устройства данных. Их число настраивается динамически между
@ -281,7 +211,6 @@ Flusher - это микро-поток (корутина), которая коп

 - Тип: целое число
 - Значение по умолчанию: 256
- Можно менять на лету: да

 Максимальное число микро-потоков очистки журнала (см. выше min_flusher_count).

@ -312,63 +241,6 @@ Flusher - это микро-поток (корутина), которая коп
 параметра может оказаться полезным для гибридных 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

 - Тип: целое число
@ -398,7 +270,6 @@ fsync небезопасным даже с режимом "directsync".

 - Тип: булево (да/нет)
 - Значение по умолчанию: false
- Можно менять на лету: да

 Разрешить мягкое ограничение скорости журналируемой записи. Полезно для
 гибридных OSD с быстрыми устройствами метаданных и медленными устройствами
@ -417,7 +288,6 @@ fsync небезопасным даже с режимом "directsync".

 - Тип: целое число
 - Значение по умолчанию: 100
- Можно менять на лету: да

 Расчётное максимальное число ограничиваемых операций в секунду при условии
 отсутствия свободного места в журнале. Устанавливайте приблизительно равным
@ -428,7 +298,6 @@ fsync небезопасным даже с режимом "directsync".

 - Тип: целое число
 - Значение по умолчанию: 100
- Можно менять на лету: да

 Расчётный максимальный размер в МБ/с ограничиваемых операций в секунду при
 условии отсутствия свободного места в журнале. Устанавливайте приблизительно
@ -439,7 +308,6 @@ fsync небезопасным даже с режимом "directsync".

 - Тип: целое число
 - Значение по умолчанию: 1
- Можно менять на лету: да

 Расчётный максимальный параллелизм ограничиваемых операций в секунду при
 условии отсутствия свободного места в журнале. Устанавливайте приблизительно
@ -450,7 +318,6 @@ fsync небезопасным даже с режимом "directsync".

 - Тип: микросекунды
 - Значение по умолчанию: 50
- Можно менять на лету: да

 Минимальная применимая к ограничиваемым операциям задержка. Обычно не
 требует изменений.
@ -460,203 +327,4 @@ fsync небезопасным даже с режимом "directsync".
 - Тип: булево (да/нет)
 - Значение по умолчанию: 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.
-Большие значения считаются случайными выбросами и игнорируются в
-усреднении.
+Блокировать всю память OSD с помощью mlockall, чтобы запретить её выгрузку в пространство подкачки. Требует достаточного значения ulimit -l (лимита заблокированной памяти).
--- a/docs/config/pool.en.md
+++ b/docs/config/pool.en.md
@ -32,8 +32,6 @@ Parameters:
 - [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)
@ -42,8 +40,6 @@ Parameters:
 - [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:

@ -55,7 +51,7 @@ Examples:
 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>",
@ -63,7 +59,7 @@ in the following JSON format:
  },
  ...
 }
-```
+`

 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
@ -86,11 +82,7 @@ Parent node reference is required for intermediate tree nodes.
 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)
+As of now, two settings are supported:

 ## reweight

@ -113,14 +105,6 @@ 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
@ -169,26 +153,6 @@ 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.

@ -200,8 +164,8 @@ read-only instead of deactivating them.
 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,
+"Enough" is usually around 64-128 PGs per OSD, i.e. you set pg_count for pool
+to (total OSD count * 100 / 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.

@ -223,69 +187,6 @@ 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
@ -303,8 +204,9 @@ This parameter usually doesn't require to be changed.
 - 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).
+unspecified. If your cluster has OSDs with different block sizes then pool must
+be restricted by [osd_tags](#osd_tags) to only include OSDs with matching block
+size.

 Read more about this parameter in [Cluster-Wide Disk Layout Parameters](layout-cluster.en.md#block_size).

@ -313,9 +215,10 @@ Read more about this parameter in [Cluster-Wide Disk Layout Parameters](layout-c
 - 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.
+"Sector" size of virtual disks in this pool. The value from
+/vitastor/config/global is used when unspecified. Similar to block_size, the
+pool must be restricted by [osd_tags](#osd_tags) to only include OSDs with
+matching bitmap_granularity.

 Read more about this parameter in [Cluster-Wide Disk Layout Parameters](layout-cluster.en.md#bitmap_granularity).

@ -325,11 +228,10 @@ Read more about this parameter in [Cluster-Wide Disk Layout Parameters](layout-c
 - 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".
+is used when unspecified. Similar to block_size, the pool must be restricted by
+[osd_tags](#osd_tags) to only include OSDs with compatible immediate_commit.
+Compatible means that a pool with non-immediate commit will work with OSDs with
+immediate commit enabled, but not vice versa.

 Read more about this parameter in [Cluster-Wide Disk Layout Parameters](layout-cluster.en.md#immediate_commit).

@ -370,32 +272,6 @@ 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
--- a/docs/config/pool.ru.md
+++ b/docs/config/pool.ru.md
@ -31,8 +31,6 @@
 - [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)
@ -41,8 +39,6 @@
 - [root_node](#root_node)
 - [osd_tags](#osd_tags)
 - [primary_affinity_tags](#primary_affinity_tags)
- [scrub_interval](#scrub_interval)
- [used_for_fs](#used_for_fs)

 Примеры:

@ -54,7 +50,7 @@
 Дерево размещения OSD задаётся в отдельном ключе etcd `/vitastor/config/node_placement`
 в следующем JSON-формате:

-```
+`
 {
  "<имя узла или номер OSD>": {
    "level": "<уровень>",
@ -62,7 +58,7 @@
  },
  ...
 }
-```
+`

 Здесь, если название узла - число, считается, что это OSD. Уровень OSD
 всегда равен "osd" и не может быть переопределён. Для OSD вы можете только
@ -85,11 +81,10 @@
 Настройки отдельных OSD задаются в ключах etcd `/vitastor/config/osd/<number>`
 в JSON-формате `{"<key>":<value>}`.

-На данный момент поддерживаются следующие настройки:
+На данный момент поддерживаются две настройки:

 - [reweight](#reweight)
 - [tags](#tags)
- [noout](#noout)

 ## reweight

@ -113,14 +108,6 @@
 всех. Можно, например, пометить SSD OSD тегом "ssd", а HDD тегом "hdd", в
 этом смысле теги работают аналогично классам устройств.

-## noout
-
- Тип: булево (да/нет)
- Значение по умолчанию: false
-
-Если установлено в true, то [osd_out_time](monitor.ru.md#osd_out_time) для этого
-OSD игнорируется и OSD не удаляется из распределения данных монитором.
-
 # Параметры

 ## name
@ -169,26 +156,6 @@ OSD игнорируется и OSD не удаляется из распред
 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 на перевод их в режим только для чтения.

@ -200,8 +167,8 @@ PG на перевод их в режим только для чтения.
 Число PG для данного пула. Число должно быть достаточно большим, чтобы монитор
 мог равномерно распределить по ним данные.

-Обычно это означает примерно 10-100 PG на 1 OSD, т.е. pg_count можно устанавливать
-равным (общему числу OSD * 10 / pg_size). Значение можно округлить до ближайшей
+Обычно это означает примерно 64-128 PG на 1 OSD, т.е. pg_count можно устанавливать
+равным (общему числу OSD * 100 / pg_size). Значение можно округлить до ближайшей
 степени 2, чтобы потом было легче уменьшать или увеличивать число PG, умножая
 или деля его на 2.

@ -222,71 +189,6 @@ PG в Vitastor эферемерны, то есть вы можете менят
 Иными словами, домен отказа - это то, от отказа чего вы защищаете себя избыточным
 хранением.

-## 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

 - Тип: целое число
@ -305,9 +207,8 @@ meow недоступен".

 Размер блока для данного пула. Если не задан, используется значение из
 /vitastor/config/global. Если в вашем кластере есть OSD с разными размерами
-блока, пул будет использовать только OSD с размером блока, равным размеру блока
-пула. Если вы хотите сильнее ограничить набор используемых для пула OSD -
-используйте [osd_tags](#osd_tags).
+блока, пул должен быть ограничен только OSD, блок которых равен блоку пула,
+с помощью [osd_tags](#osd_tags).

 О самом параметре читайте в разделе [Дисковые параметры уровня кластера](layout-cluster.ru.md#block_size).

@ -317,8 +218,9 @@ meow недоступен".
 - По умолчанию: 4096

 Размер "сектора" виртуальных дисков в данном пуле. Если не задан, используется
-значение из /vitastor/config/global. Аналогично block_size, каждый пул будет
-использовать только OSD с совпадающей с пулом настройкой bitmap_granularity.
+значение из /vitastor/config/global. Аналогично block_size, пул должен быть
+ограничен OSD со значением bitmap_granularity, равным значению пула, с помощью
+[osd_tags](#osd_tags).

 О самом параметре читайте в разделе [Дисковые параметры уровня кластера](layout-cluster.ru.md#bitmap_granularity).

@ -328,13 +230,11 @@ meow недоступен".
 - По умолчанию: none

 Настройка мгновенного коммита для данного пула. Если не задана, используется
-значение из /vitastor/config/global. Аналогично block_size, каждый пул будет
-использовать только OSD с *совместимыми* настройками immediate_commit.
-"Совместимыми" означает, что пул с отключенным мгновенным коммитом будет
-использовать OSD с включённым мгновенным коммитом, но не наоборот. То есть,
-пул со значением "none" будет использовать все OSD, пул со "small" будет
-использовать OSD с "all" или "small", а пул с "all" будет использовать только
-OSD с "all".
+значение из /vitastor/config/global. Аналогично block_size, пул должен быть
+ограничен OSD со значением bitmap_granularity, совместимым со значением пула, с
+помощью [osd_tags](#osd_tags). Совместимость означает, что пул с отключенным
+мгновенным коммитом может работать на OSD с включённым мгновенным коммитом, но
+не наоборот.

 О самом параметре читайте в разделе [Дисковые параметры уровня кластера](layout-cluster.ru.md#immediate_commit).

@ -376,34 +276,6 @@ OSD с "all".
 для 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.
-
 # Примеры

 ## Реплицированный пул
--- 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.yml
+++ b/docs/config/src/common.yml
@ -11,21 +11,13 @@
 - 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"
@ -39,6 +31,5 @@
 - 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.yml
+++ b/docs/config/src/layout-cluster.yml
@ -7,27 +7,26 @@
    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
+    Recommended default block size is 128 KB for SSD and 4 MB for HDD. In fact,
+    it's possible to use 4 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 мегабайт,
+    Рекомендуемые по умолчанию размеры блока - 128 килобайт для SSD и 4
+    мегабайта для HDD. В принципе, для SSD можно тоже использовать 4 мегабайта,
    это понизит использование памяти, но ухудшит распределение нагрузки и в
    среднем увеличит WA.

    Потребление памяти OSD составляет примерно (РАЗМЕР / БЛОК * 68 байт),
    т.е. примерно 544 МБ памяти на 1 ТБ занятого места на диске при
-    стандартном 128 КБ блоке. При 1 МБ блоке памяти нужно в 8 раз меньше.
+    стандартном 128 КБ блоке.
 - name: bitmap_granularity
  type: int
  default: 4096
@ -47,24 +46,14 @@
    Не может быть меньше размера сектора дисков данных OSD.
 - name: immediate_commit
  type: string
-  default: all
+  default: false
  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:
+    Another parameter which is really important for performance.

    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.
+    if you try to fsync() each write, that is, when you want to guarantee that
+    each change gets immediately 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
@ -76,8 +65,8 @@
    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
+    This is what this parameter regulates. When it's set to "all" the whole
+    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
@ -97,22 +86,16 @@
    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".
+    disable_journal_fsync and disable_meta_fsync, setting it to "all" also requires
+    enabling disable_data_fsync.
+
+    TLDR: For optimal performance, set immediate_commit to "all" if you only use
+    SSDs with supercapacitor-based power loss protection (nonvolatile
+    write-through cache) for both data and journals in the whole Vitastor
+    cluster. Set it to "small" if you only use such SSDs for journals. Leave
+    empty if your drives have write-back cache.
  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+ операций в
    секунду) при простой случайной записи без сбросов кэша. Однако они очень
@ -133,7 +116,7 @@
    эффективно утилизировать настольные SSD.

    Данный параметр влияет как раз на это. Когда он установлен в значение "all",
-    кластер Vitastor мгновенно фиксирует каждое изменение на физические
+    весь кластер Vitastor мгновенно фиксирует каждое изменение на физические
    носители и клиенты могут просто игнорировать запросы fsync, т.к. они точно
    знают, что fsync-и не нужны. Это уменьшает число необходимых обращений к OSD
    по сети и улучшает производительность. Поэтому даже с Vitastor лучше всегда
@ -156,6 +139,12 @@
    указано в спецификациях).

    Указание "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).
+    включения disable_journal_fsync и disable_meta_fsync, значение "all" также
+    требует включения disable_data_fsync.
+
+    Итого, вкратце: для оптимальной производительности установите
+    immediate_commit в значение "all", если вы используете в кластере только SSD
+    с суперконденсаторами и для данных, и для журналов. Если вы используете
+    такие SSD для всех журналов, но не для данных - можете установить параметр
+    в "small". Если и какие-то из дисков журналов имеют волатильный кэш записи -
+    оставьте параметр пустым.
--- a/docs/config/src/layout-osd.yml
+++ b/docs/config/src/layout-osd.yml
@ -110,22 +110,20 @@
  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.
+    Do not issue fsyncs to the data device, i.e. do not flush its cache.
+    Safe ONLY if your data device has write-through cache. If you disable
+    the cache yourself using `hdparm` or `scsi_disk/cache_type` then make sure
+    that the cache disable command is run every time before starting Vitastor
+    OSD, for example, in the systemd unit. See also `immediate_commit` option
+    for the instructions to disable cache and how to benefit from it.
  info_ru: |
-    Не отправлять fsync-и устройству данных, т.е. не заставлять его сбрасывать кэш.
+    Не отправлять fsync-и устройству данных, т.е. не сбрасывать его кэш.
    Безопасно, ТОЛЬКО если ваше устройство данных имеет кэш со сквозной
-    записью (write-through) или если кэш с отложенной записью (write-back) отключён.
-    Если вы отключаете кэш вручную через `hdparm` или запись в `/sys/.../scsi_disk/cache_type`,
-    то удостоверьтесь, что вы делаете это каждый раз перед запуском Vitastor OSD
-    (vitastor-disk делает это автоматически). Смотрите также опцию
-    [immediate_commit](layout-cluster.ru.md#immediate_commit) для информации о том,
-    как извлечь выгоду из отключённого кэша.
+    записью (write-through). Если вы отключаете кэш через `hdparm` или
+    `scsi_disk/cache_type`, то удостоверьтесь, что команда отключения кэша
+    выполняется перед каждым запуском Vitastor OSD, например, в systemd unit-е.
+    Смотрите также опцию `immediate_commit` для инструкций по отключению кэша
+    и о том, как из этого извлечь выгоду.
 - name: disable_meta_fsync
  type: bool
  default: false
@ -181,7 +179,8 @@

    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...
+    and meta_block_size. But the only SSD that may fit into this category is
+    Intel Optane (probably, not tested yet).

    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.
@ -199,78 +198,9 @@

    Поэтому, на самом деле, может быть выгодно найти SSD, хорошо работающие с
    меньшими, 512-байтными, блоками и использовать 512-байтные disk_alignment,
-    journal_block_size и meta_block_size. Однако на данный момент такие SSD
-    не известны...
+    journal_block_size и meta_block_size. Однако единственные SSD, которые
+    теоретически могут попасть в эту категорию - это Intel Optane (но и это
+    пока не проверялось автором).

    Клиентам не обязательно знать про 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
@ -14,7 +14,6 @@ const L = {
        toc_config: '[Configuration](../config.en.md)',
        toc_usage: 'Usage',
        toc_performance: 'Performance',
-        online: 'Can be changed online: yes',
    },
    ru: {
        Documentation: 'Документация',
@ -29,7 +28,6 @@ const L = {
        toc_config: '[Конфигурация](../config.ru.md)',
        toc_usage: 'Использование',
        toc_performance: 'Производительность',
-        online: 'Можно менять на лету: да',
    },
 };
 const types = {
@ -38,7 +36,6 @@ const types = {
        bool: 'boolean',
        int: 'integer',
        sec: 'seconds',
-        float: 'number',
        ms: 'milliseconds',
        us: 'microseconds',
    },
@ -47,7 +44,6 @@ const types = {
        bool: 'булево (да/нет)',
        int: 'целое число',
        sec: 'секунды',
-        float: 'число',
        ms: 'миллисекунды',
        us: 'микросекунды',
    },
@ -74,8 +70,6 @@ for (const file of params_files)
                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' });
--- a/docs/config/src/monitor.yml
+++ b/docs/config/src/monitor.yml
@ -1,107 +1,7 @@
- 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
+  min: 10
+  default: 30
  info: Monitor etcd lease refresh interval in seconds
  info_ru: Интервал обновления etcd резервации (lease) монитором
 - name: etcd_mon_timeout
@ -163,12 +63,3 @@
    "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.yml
+++ b/docs/config/src/network.yml
@ -48,20 +48,11 @@
  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.
+    "rocep5s0f0"). Please note that Vitastor RDMA requires Implicit On-Demand
+    Paging (Implicit ODP) and Scatter/Gather (SG) support from the RDMA device
+    to work. For example, Mellanox ConnectX-3 and older adapters don't have
+    Implicit ODP, so they're unsupported by Vitastor. 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
@ -70,20 +61,12 @@
    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-устройств, их параметры и возможности.
+    Имейте в виду, что поддержка RDMA в Vitastor требует функций устройства
+    Implicit On-Demand Paging (Implicit ODP) и Scatter/Gather (SG). Например,
+    адаптеры Mellanox ConnectX-3 и более старые не поддерживают Implicit ODP и
+    потому не поддерживаются в Vitastor. Запустите `ibv_devinfo -v` от имени
+    суперпользователя, чтобы посмотреть список доступных RDMA-устройств, их
+    параметры и возможности.

    Обратите внимание, что если вы используете RoCE/RoCEv2, вам также необходимо
    правильно настроить для него коммутаторы, иначе вы можете столкнуться с
@ -105,29 +88,23 @@
    `ibv_devinfo -v`.
 - name: rdma_gid_index
  type: int
+  default: 0
  info: |
    Global address identifier index of the RDMA device to use. Different GID
    indexes may correspond to different protocols like RoCEv1, RoCEv2 and iWARP.
    Search for "GID" in `ibv_devinfo -v` output to determine which GID index
    you need.

-    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).
+    **IMPORTANT:** If you want to use RoCEv2 (as recommended) then the correct
+    rdma_gid_index is usually 1 (IPv6) or 3 (IPv4).
  info_ru: |
    Номер глобального идентификатора адреса RDMA-устройства, который следует
    использовать. Разным gid_index могут соответствовать разные протоколы связи:
    RoCEv1, RoCEv2, iWARP. Чтобы понять, какой нужен вам - смотрите строчки со
    словом "GID" в выводе команды `ibv_devinfo -v`.

-    Если не указан, Vitastor попробует автоматически выбрать сначала GID,
-    соответствующий RoCEv2 IPv4, потом RoCEv2 IPv6, потом RoCEv1 IPv4, потом
-    RoCEv1 IPv6, потом IB. Авто-выбор GID не поддерживается со старыми версиями
-    libibverbs < v32.
-
-    Правильный rdma_gid_index для RoCEv2, как правило, 1 (IPv6) или 3 (IPv4).
+    **ВАЖНО:** Если вы хотите использовать RoCEv2 (как мы и рекомендуем), то
+    правильный rdma_gid_index, как правило, 1 (IPv6) или 3 (IPv4).
 - name: rdma_mtu
  type: int
  default: 4096
@ -183,64 +160,22 @@
    у принимающей стороны в процессе работы не заканчивались буферы на приём.
    Не влияет на потребление памяти - дополнительная память на операции отправки
    не выделяется.
- 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.
@ -251,7 +186,6 @@
  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
@ -260,10 +194,23 @@
    Максимальное время ожидания ответа на запрос проверки состояния соединения.
    Если OSD не отвечает за это время, соединение отключается и производится
    повторная попытка соединения.
+- name: up_wait_retry_interval
+  type: ms
+  min: 50
+  default: 500
+  info: |
+    OSDs respond to clients with a special error code when they receive I/O
+    requests for a PG that's not synchronized and started. This parameter sets
+    the time for the clients to wait before re-attempting such I/O requests.
+  info_ru: |
+    Когда OSD получают от клиентов запросы ввода-вывода, относящиеся к не
+    поднятым на данный момент на них PG, либо к PG в процессе синхронизации,
+    они отвечают клиентам специальным кодом ошибки, означающим, что клиент
+    должен некоторое время подождать перед повторением запроса. Именно это время
+    ожидания задаёт данный параметр.
 - name: max_etcd_attempts
  type: int
  default: 5
-  online: true
  info: |
    Maximum number of attempts for etcd requests which can't be retried
    indefinitely.
@ -273,7 +220,6 @@
 - name: etcd_quick_timeout
  type: ms
  default: 1000
-  online: true
  info: |
    Timeout for etcd requests which should complete quickly, like lease refresh.
  info_ru: |
@ -282,7 +228,6 @@
 - 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, для которых не обязательно
@ -290,19 +235,36 @@
 - 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
+- name: etcd_ws_keepalive_timeout
  type: sec
-  default: 5
-  online: true
+  default: 30
  info: |
    etcd websocket ping interval required to keep the connection alive and
    detect disconnections quickly.
  info_ru: |
    Интервал проверки живости вебсокет-подключений к etcd.
+- name: client_dirty_limit
+  type: int
+  default: 33554432
+  info: |
+    Without 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.
+
+    This parameter doesn't affect OSDs themselves.
+  info_ru: |
+    При работе без immediate_commit=all - это лимит объёма "грязных" (не
+    зафиксированных fsync-ом) данных, при достижении которого клиент будет
+    принудительно вызывать fsync и фиксировать данные. Также стоит иметь в виду,
+    что в этом случае до момента fsync клиент хранит копию незафиксированных
+    данных в памяти, то есть, настройка влияет на потребление памяти клиентами.
+
+    Параметр не влияет на сами OSD.
--- a/docs/config/src/osd.en.md
+++ b/docs/config/src/osd.en.md
@ -1,5 +1,4 @@
 # 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.
+initialization and can be changed with an OSD restart.
--- a/docs/config/src/osd.ru.md
+++ b/docs/config/src/osd.ru.md
@ -2,5 +2,4 @@

 Данные параметры используются только OSD, но, в отличие от дисковых параметров,
 не фиксируются в момент инициализации дисков OSD и могут быть изменены в любой
-момент с помощью перезапуска OSD, а некоторые и без перезапуска, с помощью
-изменения конфигурации в etcd.
+момент с перезапуском OSD.
--- a/docs/config/src/osd.yml
+++ b/docs/config/src/osd.yml
@ -1,47 +1,16 @@
- name: osd_iothread_count
-  type: int
-  default: 0
-  info: |
-    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.
-  info_ru: |
-    Число отдельных потоков для обработки ввода-вывода через TCP-сеть на
-    стороне OSD. Включение опции позволяет каждому отдельному OSD передавать
-    по сети больше данных, но ухудшает задержку из-за накладных расходов
-    переключения потоков. На работу RDMA опция не влияет.
-
-    Из-за задержек вместо включения потоков ввода-вывода OSD рекомендуется
-    просто создавать по несколько OSD на каждом диске, или использовать RDMA.
 - name: etcd_report_interval
  type: sec
  default: 5
  info: |
-    Interval at which OSDs report their liveness to etcd. Affects OSD lease time
+    Interval at which OSDs report their state 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.
  info_ru: |
-    Интервал, с которым OSD сообщает о том, что жив, в etcd. Значение параметра
-    влияет на время резервации (lease) OSD и поэтому - на скорость переключения
+    Интервал, с которым OSD обновляет своё состояние в etcd. Значение параметра
+    влияет на время резервации (lease) OSD и поэтому на скорость переключения
    при падении OSD. Время lease равняется значению этого параметра плюс
    max_etcd_attempts * etcd_quick_timeout.
- name: etcd_stats_interval
-  type: sec
-  default: 30
-  info: |
-    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.
-  info_ru: |
-    Интервал, с которым OSD обновляет свою статистику в etcd. Сильно влияет на
-    создаваемую нагрузку на etcd, потому что статистика содержит по ключу на
-    каждый OSD и на каждую PG. В то же время низкий интервал делает
-    статистику, печатаемую `vitastor-cli`, отзывчивей.
 - name: run_primary
  type: bool
  default: true
@ -97,7 +66,6 @@
 - name: autosync_interval
  type: sec
  default: 5
-  online: true
  info: |
    Time interval at which automatic fsyncs/flushes are issued by each OSD when
    the immediate_commit mode if disabled. fsyncs are required because without
@ -115,7 +83,6 @@
 - name: autosync_writes
  type: int
  default: 128
-  online: true
  info: |
    Same as autosync_interval, but sets the maximum number of uncommitted write
    operations before issuing an fsync operation internally.
@ -125,33 +92,19 @@
    принудительной отправкой fsync-а.
 - name: recovery_queue_depth
  type: int
-  default: 1
-  online: true
+  default: 4
  info: |
-    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.
+    Maximum recovery operations per one primary OSD at any given moment of time.
+    Currently it's the only parameter available to tune the speed or recovery
+    and rebalancing, but it's planned to implement more.
  info_ru: |
-    Максимальное число параллельных операций восстановления, инициируемых одним
-    OSD в любой момент времени. Имейте в виду, что каждый OSD обычно работает с
-    многими другими OSD, так что на практике параллелизм восстановления больше,
-    чем просто recovery_queue_depth. Увеличение значения этого параметра может
-    ускорить восстановление если [автотюнинг скорости](#recovery_tune_interval)
-    разрешает это или если он отключён.
- name: recovery_sleep_us
-  type: us
-  default: 0
-  online: true
-  info: |
-    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.
+    Максимальное число операций восстановления на одном первичном OSD в любой
+    момент времени. На данный момент единственный параметр, который можно менять
+    для ускорения или замедления восстановления и перебалансировки данных, но
+    в планах реализация других параметров.
 - name: recovery_pg_switch
  type: int
  default: 128
-  online: true
  info: |
    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
@ -166,7 +119,6 @@
 - name: recovery_sync_batch
  type: int
  default: 16
-  online: true
  info: Maximum number of recovery operations before issuing an additional fsync.
  info_ru: Максимальное число операций восстановления перед дополнительным fsync.
 - name: readonly
@ -181,7 +133,6 @@
 - name: no_recovery
  type: bool
  default: false
-  online: true
  info: |
    Disable automatic background recovery of objects. Note that it doesn't
    affect implicit recovery of objects happening during writes - a write is
@ -194,7 +145,6 @@
 - name: no_rebalance
  type: bool
  default: false
-  online: true
  info: |
    Disable background movement of data between different OSDs. Disabling it
    means that PGs in the `has_misplaced` state will be left in it indefinitely.
@ -205,7 +155,6 @@
 - name: print_stats_interval
  type: sec
  default: 3
-  online: true
  info: |
    Time interval at which OSDs print simple human-readable operation
    statistics on stdout.
@ -215,7 +164,6 @@
 - name: slow_log_interval
  type: sec
  default: 10
-  online: true
  info: |
    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
@ -227,7 +175,6 @@
 - name: inode_vanish_time
  type: sec
  default: 60
-  online: true
  info: |
    Number of seconds after which a deleted inode is removed from OSD statistics.
  info_ru: |
@ -235,7 +182,6 @@
 - name: max_write_iodepth
  type: int
  default: 128
-  online: true
  info: |
    Parallel client write operation limit per one OSD. Operations that exceed
    this limit are pushed to a temporary queue instead of being executed
@ -247,7 +193,6 @@
 - name: min_flusher_count
  type: int
  default: 1
-  online: true
  info: |
    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.
@ -259,7 +204,6 @@
 - name: max_flusher_count
  type: int
  default: 256
-  online: true
  info: |
    Maximum number of journal flushers (see above min_flusher_count).
  info_ru: |
@ -303,96 +247,6 @@
    достаточно 16- или 32-мегабайтного журнала. Однако в теории отключение
    параметра может оказаться полезным для гибридных OSD (HDD+SSD) с большими
    журналами, расположенными на быстром по сравнению с HDD устройстве.
- name: data_io
-  type: string
-  default: direct
-  info: |
-    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".
-  info_ru: |
-    Режим ввода-вывода для *данных*. Одно из значений "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".
- name: meta_io
-  type: string
-  default: direct
-  info: |
-    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).
-  info_ru: |
-    Режим ввода-вывода для *метаданных*. Одно из значений "direct", "cached" или
-    "directsync".
-
-    "cached" может улучшить скорость чтения, если:
-    1. у вас медленные диски (HDD, SATA SSD)
-    2. контрольные суммы включены
-    3. параметр [inmemory_metadata](#inmemory_metadata) отключён.
-    При этих условиях блоки метаданных читаются с диска при каждом запросе чтения
-    для проверки контрольных сумм и их кэширование может снизить дополнительную
-    нагрузку на диск. Без (3) метаданные никогда не читаются с диска после
-    запуска OSD, а без (2) блоки метаданных читаются только при сбросе журнала.
-
-    Если одно и то же устройство используется для данных и метаданных, режим
-    ввода-вывода метаданных по умолчанию устанавливается равным [data_io](#data_io).
- name: journal_io
-  type: string
-  default: direct
-  info: |
-    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).
-  info_ru: |
-    Режим ввода-вывода для *журнала*. Одно из значений "direct", "cached" или
-    "directsync".
-
-    Здесь "cached" может улучшить скорость чтения только недавно записанных
-    данных и только если параметр [inmemory_journal](#inmemory_journal)
-    отключён.
-
-    Если одно и то же устройство используется для метаданных и журнала,
-    режим ввода-вывода журнала по умолчанию устанавливается равным
-    [meta_io](#meta_io).
 - name: journal_sector_buffer_count
  type: int
  default: 32
@ -430,7 +284,6 @@
 - name: throttle_small_writes
  type: bool
  default: false
-  online: true
  info: |
    Enable soft throttling of small journaled writes. Useful for hybrid OSDs
    with fast journal/metadata devices and slow data devices. The idea is that
@ -459,7 +312,6 @@
 - name: throttle_target_iops
  type: int
  default: 100
-  online: true
  info: |
    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
@ -472,7 +324,6 @@
 - name: throttle_target_mbs
  type: int
  default: 100
-  online: true
  info: |
    Target maximum bandwidth in MB/s of throttled operations per second under
    the condition of full journal. Set it to approximate linear write
@ -485,7 +336,6 @@
 - name: throttle_target_parallelism
  type: int
  default: 1
-  online: true
  info: |
    Target maximum parallelism of throttled operations under the condition of
    full journal. Set it to approximate internal parallelism of your data
@ -498,7 +348,6 @@
 - name: throttle_threshold_us
  type: us
  default: 50
-  online: true
  info: |
    Minimal computed delay to be applied to throttled operations. Usually
    doesn't need to be changed.
@ -508,260 +357,10 @@
 - name: osd_memlock
  type: bool
  default: false
-  info: |
+  info: >
    Lock all OSD memory to prevent it from being unloaded into swap with
    mlockall(). Requires sufficient ulimit -l (max locked memory).
-  info_ru: |
+  info_ru: >
    Блокировать всю память OSD с помощью mlockall, чтобы запретить её выгрузку
    в пространство подкачки. Требует достаточного значения ulimit -l (лимита
    заблокированной памяти).
- name: auto_scrub
-  type: bool
-  default: false
-  online: true
-  info: |
-    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.
-  info_ru: |
-    Скраб - процесс фоновой проверки копий данных, предназначенный, чтобы
-    находить и исправлять повреждённые блоки. По умолчанию эти проверки ещё не
-    запускаются автоматически, так как являются новой функцией. Чтобы включить
-    автоматическое планирование скрабов, установите данный параметр в true.
-
-    Включённый параметр заставляет OSD автоматически планировать фоновую
-    проверку чистых PG раз в `scrub_interval` (см. ниже). Вы также можете
-    запустить или запланировать проверку вручную, установив значение ключа JSON
-    `next_scrub` внутри ключей etcd `/pg/history/...` в UNIX-время следующей
-    желаемой проверки.
- name: no_scrub
-  type: bool
-  default: false
-  online: true
-  info: |
-    Temporarily disable scrubbing and stop running scrubs.
-  info_ru: |
-    Временно отключить и остановить запущенные скрабы.
- name: scrub_interval
-  type: string
-  default: 30d
-  online: true
-  info: |
-    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).
-  info_ru: |
-    Интервал автоматической фоновой проверки по умолчанию для всех пулов.
-    Значения без указанной единицы измерения считаются в секундах, допустимые
-    символы единиц измерения в конце: 's' (секунды),
-    'm' (минуты), 'h' (часы), 'd' (дни), 'M' (месяца) или 'y' (годы).
- name: scrub_queue_depth
-  type: int
-  default: 1
-  online: true
-  info: |
-    Number of parallel scrubbing operations per one OSD.
-  info_ru: |
-    Число параллельных операций фоновой проверки на один OSD.
- name: scrub_sleep
-  type: ms
-  default: 0
-  online: true
-  info: |
-    Additional interval between two consecutive scrubbing operations on one OSD.
-    Can be used to slow down scrubbing if it affects user load too much.
-  info_ru: |
-    Дополнительный интервал ожидания после фоновой проверки каждого объекта на
-    одном OSD. Может использоваться для замедления скраба, если он слишком
-    сильно влияет на пользовательскую нагрузку.
- name: scrub_list_limit
-  type: int
-  default: 1000
-  online: true
-  info: |
-    Number of objects to list in one listing operation during scrub.
-  info_ru: |
-    Размер загружаемых за одну операцию списков объектов в процессе фоновой
-    проверки.
- name: scrub_find_best
-  type: bool
-  default: true
-  online: true
-  info: |
-    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.
-  info_ru: |
-    Находить и автоматически восстанавливать "лучшие версии" объектов с
-    несовпадающими копиями/частями. При использовании репликации "лучшая"
-    версия - версия, доступная в большем числе экземпляров, чем другие. При
-    использовании кодов коррекции ошибок "лучшая" версия - это подмножество
-    частей данных и чётности, полностью соответствующих друг другу.
-
-    Гипотетическая ситуация, в которой вы можете захотеть отключить этот
-    поиск - это если у вас 3 реплики и вы боитесь, что 2 диска из 3 могут
-    незаметно и одинаково повредить данные одного и того же объекта, например,
-    занулив его, и только 1 диск останется неповреждённым. В этой ситуации
-    отключение этого параметра поможет вам восстановить данные! Смотрите также
-    описание следующего параметра - scrub_ec_max_bruteforce.
- name: scrub_ec_max_bruteforce
-  type: int
-  default: 100
-  online: true
-  info: |
-    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.
-  info_ru: |
-    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 копия
-    считается некорректной. Однако, если "лучшую" версию с числом доступных
-    копий большим, чем у всех других версий, найти невозможно, то объект тоже
-    маркируется неконсистентным.
- name: recovery_tune_interval
-  type: sec
-  default: 1
-  online: true
-  info: |
-    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.
-  info_ru: |
-    Интервал, с которым OSD пересматривает клиентскую нагрузку и нагрузку
-    восстановления и автоматически подстраивает [recovery_sleep_us](#recovery_sleep_us).
-    Автотюнинг (автоподстройка) отключается, если recovery_tune_interval
-    устанавливается в значение 0.
-
-    Автотюнинг регулирует утилизацию. Утилизация является мерой нагрузки
-    и равна произведению числа операций в секунду и средней задержки
-    (то есть, она может быть выше 1). Вы задаёте два уровня клиентской
-    утилизации - "низкий" и "высокий" (low и high) и два соответствующих
-    целевых уровня утилизации операциями восстановления. OSD рассчитывает
-    желаемый уровень утилизации восстановления линейной интерполяцией от
-    клиентской утилизации и подстраивает задержку операций восстановления
-    так, чтобы фактическая утилизация восстановления совпадала с желаемой.
-
-    Это позволяет снизить влияние восстановления и ребаланса на клиентские
-    операции. Конечно, невозможно исключить такое влияние полностью, но оно
-    должно становиться адекватнее. В некоторых тестах перебалансировка могла
-    снижать клиентскую скорость записи с 1.5 ГБ/с до 50-100 МБ/с, а теперь, с
-    настройками автотюнинга по умолчанию, она снижается только до ~1 ГБ/с.
- name: recovery_tune_util_low
-  type: float
-  default: 0.1
-  online: true
-  info: |
-    Desired recovery/rebalance utilization when client load is high, i.e. when
-    it is at or above recovery_tune_client_util_high.
-  info_ru: |
-    Желаемая утилизация восстановления в моменты, когда клиентская нагрузка
-    высокая, то есть, находится на уровне или выше recovery_tune_client_util_high.
- name: recovery_tune_util_high
-  type: float
-  default: 1
-  online: true
-  info: |
-    Desired recovery/rebalance utilization when client load is low, i.e. when
-    it is at or below recovery_tune_client_util_low.
-  info_ru: |
-    Желаемая утилизация восстановления в моменты, когда клиентская нагрузка
-    низкая, то есть, находится на уровне или ниже recovery_tune_client_util_low.
- name: recovery_tune_client_util_low
-  type: float
-  default: 0
-  online: true
-  info: Client utilization considered "low".
-  info_ru: Клиентская утилизация, которая считается "низкой".
- name: recovery_tune_client_util_high
-  type: float
-  default: 0.5
-  online: true
-  info: Client utilization considered "high".
-  info_ru: Клиентская утилизация, которая считается "высокой".
- name: recovery_tune_agg_interval
-  type: int
-  default: 10
-  online: true
-  info: |
-    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.
-  info_ru: |
-    Число последних итераций автоподстройки для расчёта задержки как среднего
-    значения. Меньшие значения параметра ускоряют отклик на изменение нагрузки,
-    большие значения делают задержку стабильнее. Значение по умолчанию 10
-    обычно нормальное и не требует изменений.
- name: recovery_tune_sleep_min_us
-  type: us
-  default: 10
-  online: true
-  info: |
-    Minimum possible value for auto-tuned recovery_sleep_us. Lower values
-    are changed to 0.
-  info_ru: |
-    Минимальное возможное значение авто-подстроенного recovery_sleep_us.
-    Меньшие значения заменяются на 0.
- name: recovery_tune_sleep_cutoff_us
-  type: us
-  default: 10000000
-  online: true
-  info: |
-    Maximum possible value for auto-tuned recovery_sleep_us. Higher values
-    are treated as outliers and ignored in aggregation.
-  info_ru: |
-    Максимальное возможное значение авто-подстроенного recovery_sleep_us.
-    Большие значения считаются случайными выбросами и игнорируются в
-    усреднении.
--- a/docs/installation/kubernetes.en.md
+++ b/docs/installation/kubernetes.en.md
@ -17,27 +17,4 @@ 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.
-
-**Important:** For best experience, use Linux kernel at least 5.15 with [VDUSE](../usage/qemu.en.md#vduse)
-kernel modules enabled (vdpa, vduse, virtio-vdpa). If your distribution doesn't
-have them pre-built - build them yourself ([instructions](../usage/qemu.en.md#vduse)),
-I promise it's worth it :-). When VDUSE is unavailable, CSI driver uses [NBD](../usage/nbd.en.md)
-to map Vitastor devices. NBD is slower and prone to timeout issues: if Vitastor
-cluster becomes unresponsible for more than [nbd_timeout](../config/client.en.md#nbd_timeout),
-the NBD device detaches and breaks pods using it.
-
-## Features
-
-Vitastor CSI supports:
- Kubernetes starting with 1.20 (or 1.17 for older vitastor-csi <= 1.1.0)
- Filesystem RWO (ReadWriteOnce) volumes. Example: [PVC](../../csi/deploy/example-pvc.yaml), [pod](../../csi/deploy/example-test-pod.yaml)
- Raw block RWX (ReadWriteMany) volumes. Example: [PVC](../../csi/deploy/example-pvc-block.yaml), [pod](../../csi/deploy/example-test-pod-block.yaml)
- Volume expansion
- Volume snapshots. Example: [snapshot class](../../csi/deploy/example-snapshot-class.yaml), [snapshot](../../csi/deploy/example-snapshot.yaml), [clone](../../csi/deploy/example-snapshot-clone.yaml)
- [VDUSE](../usage/qemu.en.md#vduse) (preferred) and [NBD](../usage/nbd.en.md) device mapping methods
- Upgrades with VDUSE - new handler processes are restarted when CSI pods are restarted themselves
- VDUSE daemon auto-restart - handler processes are automatically restarted if they crash due to a bug in Vitastor client code
- Multiple clusters by using multiple configuration files in ConfigMap.
-
-Remember that to use snapshots with CSI you also have to install [Snapshot Controller and CRDs](https://kubernetes-csi.github.io/docs/snapshot-controller.html#deployment).
+After that you'll be able to create PersistentVolumes. See example in [csi/deploy/example-pvc.yaml](../../csi/deploy/example-pvc.yaml).
--- a/docs/installation/kubernetes.ru.md
+++ b/docs/installation/kubernetes.ru.md
@ -8,36 +8,13 @@

 У Vitastor есть CSI-плагин для Kubernetes, поддерживающий RWO, а также блочные RWX, тома.

-Для установки возьмите манифесты из директории [csi/deploy/](../../csi/deploy/), поместите
-вашу конфигурацию подключения к Vitastor в [csi/deploy/001-csi-config-map.yaml](../../csi/deploy/001-csi-config-map.yaml),
-настройте StorageClass в [csi/deploy/009-storage-class.yaml](../../csi/deploy/009-storage-class.yaml)
+Для установки возьмите манифесты из директории [csi/deploy/](../csi/deploy/), поместите
+вашу конфигурацию подключения к Vitastor в [csi/deploy/001-csi-config-map.yaml](../csi/deploy/001-csi-config-map.yaml),
+настройте StorageClass в [csi/deploy/009-storage-class.yaml](../csi/deploy/009-storage-class.yaml)
 и примените все `NNN-*.yaml` к вашей инсталляции Kubernetes.

 ```
 for i in ./???-*.yaml; do kubectl apply -f $i; done
 ```

-После этого вы сможете создавать PersistentVolume.
-
-**Важно:** Лучше всего использовать ядро Linux версии не менее 5.15 с включёнными модулями
-[VDUSE](../usage/qemu.ru.md#vduse) (vdpa, vduse, virtio-vdpa). Если в вашем дистрибутиве
-они не собраны из коробки - соберите их сами, обещаю, что это стоит того ([инструкция](../usage/qemu.ru.md#vduse)) :-).
-Когда VDUSE недоступно, CSI-плагин использует [NBD](../usage/nbd.ru.md) для подключения
-дисков, а NBD медленнее и имеет проблему таймаута - если кластер остаётся недоступным
-дольше, чем [nbd_timeout](../config/client.ru.md#nbd_timeout), NBD-устройство отключается
-и ломает поды, использующие его.
-
-## Возможности
-
-CSI-плагин Vitastor поддерживает:
- Версии Kubernetes, начиная с 1.20 (или с 1.17 для более старых vitastor-csi <= 1.1.0)
- Файловые RWO (ReadWriteOnce) тома. Пример: [PVC](../../csi/deploy/example-pvc.yaml), [под](../../csi/deploy/example-test-pod.yaml)
- Сырые блочные RWX (ReadWriteMany) тома. Пример: [PVC](../../csi/deploy/example-pvc-block.yaml), [под](../../csi/deploy/example-test-pod-block.yaml)
- Расширение размера томов
- Снимки томов. Пример: [класс снимков](../../csi/deploy/example-snapshot-class.yaml), [снимок](../../csi/deploy/example-snapshot.yaml), [клон снимка](../../csi/deploy/example-snapshot-clone.yaml)
- Способы подключения устройств [VDUSE](../usage/qemu.ru.md#vduse) (предпочитаемый) и [NBD](../usage/nbd.ru.md)
- Обновление при использовании VDUSE - новые процессы-обработчики устройств успешно перезапускаются вместе с самими подами CSI
- Автоперезауск демонов VDUSE - процесс-обработчик автоматически перезапустится, если он внезапно упадёт из-за бага в коде клиента Vitastor
- Несколько кластеров через задание нескольких файлов конфигурации в ConfigMap.
-
-Не забывайте, что для использования снимков нужно сначала установить [контроллер снимков и CRD](https://kubernetes-csi.github.io/docs/snapshot-controller.html#deployment).
+После этого вы сможете создавать PersistentVolume. Пример смотрите в файле [csi/deploy/example-pvc.yaml](../csi/deploy/example-pvc.yaml).
--- a/docs/installation/opennebula.en.md
+++ b/docs/installation/opennebula.en.md
@ -1,186 +0,0 @@
-[Documentation](../../README.md#documentation) → Installation → OpenNebula
-
-----
-
-[Читать на русском](opennebula.ru.md)
-
-# OpenNebula
-
-## Automatic Installation
-
-OpenNebula plugin is packaged as `vitastor-opennebula` Debian and RPM package since Vitastor 1.9.0. So:
-
- Run `apt-get install vitastor-opennebula` or `yum install vitastor-opennebula` after installing OpenNebula on all nodes
- Check that it prints "OK, Vitastor OpenNebula patches successfully applied" or "OK, Vitastor OpenNebula patches are already applied"
- If it does not, refer to [Manual Installation](#manual-installation) and apply configuration file changes manually
- Make sure that Vitastor patched versions of QEMU and libvirt are installed
-  (`dpkg -l qemu-system-x86`, `dpkg -l | grep libvirt`, `rpm -qa | grep qemu`, `rpm -qa | grep qemu`, `rpm -qa | grep libvirt-libs` should show "vitastor" in version names)
- [Block VM access to Vitastor cluster](#block-vm-access-to-vitastor-cluster)
-
-## Manual Installation
-
-Install OpenNebula. Then, on each node:
-
- Copy [opennebula/remotes](../../opennebula/remotes) into `/var/lib/one` recursively: `cp -r opennebula/remotes /var/lib/one/`
- Copy [opennebula/sudoers.d](../../opennebula/sudoers.d) to `/etc`: `cp -r opennebula/sudoers.d /etc/`
- Apply [downloader-vitastor.sh.diff](../../opennebula/remotes/datastore/vitastor/downloader-vitastor.sh.diff) to `/var/lib/one/remotes/datastore/downloader.sh`:
-  `patch /var/lib/one/remotes/datastore/downloader.sh < opennebula/remotes/datastore/vitastor/downloader-vitastor.sh.diff` - or read the patch and apply the same change manually
- Add `kvm-vitastor` to `LIVE_DISK_SNAPSHOTS` in `/etc/one/vmm_exec/vmm_execrc`
- If on Debian or Ubuntu (and AppArmor is used), add Vitastor config file path(s) to `/etc/apparmor.d/local/abstractions/libvirt-qemu`: for example,
-  `echo '  "/etc/vitastor/vitastor.conf" r,' >> /etc/apparmor.d/local/abstractions/libvirt-qemu`
- Apply changes to `/etc/one/oned.conf`
-
-### oned.conf changes
-
-1. Add deploy script override in kvm VM_MAD: add `-l deploy.vitastor` to ARGUMENTS.
-
-```diff
- VM_MAD = [
-     NAME           = "kvm",
-     SUNSTONE_NAME  = "KVM",
-     EXECUTABLE     = "one_vmm_exec",
-    ARGUMENTS      = "-t 15 -r 0 kvm -p",
-+    ARGUMENTS      = "-t 15 -r 0 kvm -p -l deploy=deploy.vitastor",
-     DEFAULT        = "vmm_exec/vmm_exec_kvm.conf",
-     TYPE           = "kvm",
-     KEEP_SNAPSHOTS = "yes",
-     LIVE_RESIZE    = "yes",
-     SUPPORT_SHAREABLE    = "yes",
-     IMPORTED_VMS_ACTIONS = "terminate, terminate-hard, hold, release, suspend,
-         resume, delete, reboot, reboot-hard, resched, unresched, disk-attach,
-         disk-detach, nic-attach, nic-detach, snapshot-create, snapshot-delete,
-         resize, updateconf, update"
- ]
-```
-
-Optional: if you also want to save VM RAM checkpoints to Vitastor, use
-`-l deploy=deploy.vitastor,save=save.vitastor,restore=restore.vitastor`
-instead of just `-l deploy=deploy.vitastor`.
-
-2. Add `vitastor` to TM_MAD.ARGUMENTS and DATASTORE_MAD.ARGUMENTS:
-
-```diff
- TM_MAD = [
-     EXECUTABLE = "one_tm",
-    ARGUMENTS = "-t 15 -d dummy,lvm,shared,fs_lvm,fs_lvm_ssh,qcow2,ssh,ceph,dev,vcenter,iscsi_libvirt"
-+    ARGUMENTS = "-t 15 -d dummy,lvm,shared,fs_lvm,fs_lvm_ssh,qcow2,ssh,ceph,vitastor,dev,vcenter,iscsi_libvirt"
- ]
-
- DATASTORE_MAD = [
-     EXECUTABLE = "one_datastore",
-    ARGUMENTS  = "-t 15 -d dummy,fs,lvm,ceph,dev,iscsi_libvirt,vcenter,restic,rsync -s shared,ssh,ceph,fs_lvm,fs_lvm_ssh,qcow2,vcenter"
-+    ARGUMENTS  = "-t 15 -d dummy,fs,lvm,ceph,vitastor,dev,iscsi_libvirt,vcenter,restic,rsync -s shared,ssh,ceph,vitastor,fs_lvm,fs_lvm_ssh,qcow2,vcenter"
- ]
-```
-
-3. Add INHERIT_DATASTORE_ATTR for two Vitastor attributes:
-
-```
-INHERIT_DATASTORE_ATTR = "VITASTOR_CONF"
-INHERIT_DATASTORE_ATTR = "IMAGE_PREFIX"
-```
-
-4. Add TM_MAD_CONF and DS_MAD_CONF for Vitastor:
-
-```
-TM_MAD_CONF = [
-    NAME = "vitastor", LN_TARGET = "NONE", CLONE_TARGET = "SELF", SHARED = "YES",
-    DS_MIGRATE = "NO", DRIVER = "raw", ALLOW_ORPHANS="format",
-    TM_MAD_SYSTEM = "ssh,shared", LN_TARGET_SSH = "SYSTEM", CLONE_TARGET_SSH = "SYSTEM",
-    DISK_TYPE_SSH = "FILE", LN_TARGET_SHARED = "NONE",
-    CLONE_TARGET_SHARED = "SELF", DISK_TYPE_SHARED = "FILE"
-]
-
-DS_MAD_CONF = [
-    NAME = "vitastor",
-    REQUIRED_ATTRS = "DISK_TYPE,BRIDGE_LIST",
-    PERSISTENT_ONLY = "NO",
-    MARKETPLACE_ACTIONS = "export"
-]
-```
-
-## Create Datastores
-
-Example Image and System Datastore definitions:
-[opennebula/vitastor-imageds.conf](../../opennebula/vitastor-imageds.conf) and
-[opennebula/vitastor-systemds.conf](../../opennebula/vitastor-systemds.conf).
-
-Change parameters to your will:
-
- POOL_NAME is Vitastor pool name to store images.
- IMAGE_PREFIX is a string prepended to all Vitastor image names.
- BRIDGE_LIST is a list of hosts with access to Vitastor cluster, mostly used for image (not system) datastore operations.
- VITASTOR_CONF is the path to cluster configuration. Note that it should be also added to `/etc/apparmor.d/local/abstractions/libvirt-qemu` if you use AppArmor.
- STAGING_DIR is a temporary directory used when importing external images. Should have free space sufficient for downloading external images.
-
-Then create datastores using `onedatastore create vitastor-imageds.conf` and `onedatastore create vitastor-systemds.conf` (or use UI).
-
-## Block VM access to Vitastor cluster
-
-Vitastor doesn't support any authentication yet, so you MUST block VM guest access to the Vitastor cluster at the network level.
-
-If you use VLAN networking for VMs - make sure you use different VLANs for VMs and hypervisor/storage network and
-block access between them using your firewall/switch configuration.
-
-If you use something more stupid like bridged networking, you probably have to use manual firewall/iptables setup
-to only allow access to Vitastor from hypervisor IPs.
-
-Also you need to switch network to "Bridged & Security Groups" and enable IP spoofing filters in OpenNebula.
-Problem is that OpenNebula's IP spoofing filter doesn't affect local interfaces of the hypervisor i.e. when
-it's enabled a VM can't talk to other VMs or to the outer world using a spoofed IP, but it CAN talk to the
-hypervisor if it takes an IP from its subnet. To fix that you also need some more iptables.
-
-So the complete "stupid" bridged network filter setup could look like the following
-(here `10.0.3.0/24` is the VM subnet and `10.0.2.0/24` is the hypervisor subnet):
-
-```
-# Allow incoming traffic from physical device
-iptables -A INPUT -m physdev --physdev-in eth0 -j ACCEPT
-# Do not allow incoming traffic from VMs, but not from VM subnet
-iptables -A INPUT ! -s 10.0.3.0/24 -i onebr0 -j DROP
-# Drop traffic from VMs to hypervisor/storage subnet
-iptables -I FORWARD 1 -s 10.0.3.0/24 -d 10.0.2.0/24 -j DROP
-```
-
-## Testing
-
-The OpenNebula plugin includes quite a bit of bash scripts, so here's their description to get an idea about what they actually do.
-
-| Script                  | Action                                    | How to Test                                                                          |
-| ----------------------- | ----------------------------------------- | ------------------------------------------------------------------------------------ |
-| vmm/kvm/deploy.vitastor | Start a VM                                | Create and start a VM with Vitastor disk(s): persistent / non-persistent / volatile. |
-| vmm/kvm/save.vitastor   | Save VM memory checkpoint                 | Stop a VM using "Stop" command.                                                      |
-| vmm/kvm/restore.vitastor| Restore VM memory checkpoint              | Start a VM back after stopping it.                                                   |
-| datastore/clone         | Copy an image as persistent               | Create a VM template and instantiate it as persistent.                               |
-| datastore/cp            | Import an external image                  | Import a VM template with images from Marketplace.                                   |
-| datastore/export        | Export an image as URL                    | Probably: export a VM template with images to Marketplace.                           |
-| datastore/mkfs          | Create an image with FS                   | Storage → Images → Create → Type: Datablock, Location: Empty disk image, Filesystem: Not empty. |
-| datastore/monitor       | Monitor used space in image datastore     | Check reported used/free space in image datastore list.                              |
-| datastore/rm            | Remove a persistent image                 | Storage → Images → Select an image → Delete.                                         |
-| datastore/snap_delete   | Delete a snapshot of a persistent image   | Storage → Images → Select an image → Select a snapshot → Delete; <br> To create an image with snapshot: attach a persistent image to a VM; create a snapshot; detach the image. |
-| datastore/snap_flatten  | Revert an image to snapshot and delete other snapshots | Storage → Images → Select an image → Select a snapshot → Flatten.       |
-| datastore/snap_revert   | Revert an image to snapshot               | Storage → Images → Select an image → Select a snapshot → Revert.                     |
-| datastore/stat          | Get virtual size of an image in MB        | No idea. Seems to be unused both in Vitastor and Ceph datastores.                    |
-| tm/clone                | Clone a non-persistent image to a VM disk | Attach a non-persistent image to a VM.                                               |
-| tm/context              | Generate a contextualisation VM disk      | Create a VM with enabled contextualisation (default). Common host FS-based version is used in Vitastor and Ceph datastores. |
-| tm/cpds                 | Copy a VM disk / its snapshot to an image | Select a VM → Select a disk → Optionally select a snapshot → Save as.                |
-| tm/delete               | Delete a cloned or volatile VM disk       | Detach a volatile disk or a non-persistent image from a VM.                          |
-| tm/failmigrate          | Handle live migration failure             | No action. Script is empty in Vitastor and Ceph. In other datastores, should roll back actions done by tm/premigrate. |
-| tm/ln                   | Attach a persistent image to a VM         | No action. Script is empty in Vitastor and Ceph.                                     |
-| tm/mkimage              | Create a volatile disk, maybe with FS     | Attach a volatile disk to a VM, with or without file system.                         |
-| tm/mkswap               | Create a volatile swap disk               | Attach a volatile disk to a VM, formatted as swap.                                   |
-| tm/monitor              | Monitor used space in system datastore    | Check reported used/free space in system datastore list.                             |
-| tm/mv                   | Move a migrated VM disk between hosts     | Migrate a VM between hosts. In Vitastor and Ceph datastores, doesn't do any storage action. |
-| tm/mvds                 | Detach a persistent image from a VM       | No action. The opposite of tm/ln. Script is empty in Vitastor and Ceph. In other datastores, script may copy the image from VM host back to the datastore. |
-| tm/postbackup           | Executed after backup                     | Seems that the script just removes temporary files after backup. Perform a VM backup and check that temporary files are cleaned up. |
-| tm/postbackup_live      | Executed after backup of a running VM     | Same as tm/postbackup, but for a running VM.                                         |
-| tm/postmigrate          | Executed after VM live migration          | No action. Only executed for system datastore, so the script tries to call other TMs for other disks. Except that, the script does nothing in Vitastor and Ceph datastores. |
-| tm/prebackup            | Actual backup script: backup VM disks     | Set up "rsync" backup datastore → Backup a VM to it.                                 |
-| tm/prebackup_live       | Backup VM disks of a running VM           | Same as tm/prebackup, but also does fsfreeze/thaw. So perform a live backup, restore it and check that disks are consistent. |
-| tm/premigrate           | Executed before live migration            | No action. Only executed for system datastore, so the script tries to call other TMs for other disks. Except that, the script does nothing in Vitastor and Ceph datastores. |
-| tm/resize               | Resize a VM disk                          | Select a VM → Select a non-persistent disk → Resize.                                 |
-| tm/restore              | Restore VM disks from backup              | Set up "rsync" backup datastore → Backup a VM to it → Restore it back.               |
-| tm/snap_create          | Create a VM disk snapshot                 | Select a VM → Select a disk → Create snapshot.                                       |
-| tm/snap_create_live     | Create a VM disk snapshot for a live VM   | Select a running VM → Select a disk → Create snapshot.                               |
-| tm/snap_delete          | Delete a VM disk snapshot                 | Select a VM → Select a disk → Select a snapshot → Delete.                            |
-| tm/snap_revert          | Revert a VM disk to a snapshot            | Select a VM → Select a disk → Select a snapshot → Revert.                            |
--- a/docs/installation/opennebula.ru.md
+++ b/docs/installation/opennebula.ru.md
@ -1,189 +0,0 @@
-[Документация](../../README-ru.md#документация) → Установка → OpenNebula
-
-----
-
-[Read in English](opennebula.en.md)
-
-# OpenNebula
-
-## Автоматическая установка
-
-Плагин OpenNebula Vitastor распространяется как Debian и RPM пакет `vitastor-opennebula`, начиная с версии Vitastor 1.9.0. Так что:
-
- Запустите `apt-get install vitastor-opennebula` или `yum install vitastor-opennebula` после установки OpenNebula на всех серверах
- Проверьте, что он выводит "OK, Vitastor OpenNebula patches successfully applied" или "OK, Vitastor OpenNebula patches are already applied" в процессе установки
- Если сообщение не выведено, пройдите по шагам инструкцию [Ручная установка](#ручная-установка) и примените правки файлов конфигурации вручную
- Удостоверьтесь, что установлены версии QEMU и libvirt с изменениями Vitastor
-  (`dpkg -l qemu-system-x86`, `dpkg -l | grep libvirt`, `rpm -qa | grep qemu`, `rpm -qa | grep qemu`, `rpm -qa | grep libvirt-libs` должны показывать "vitastor" в номере версии)
- [Заблокируйте доступ виртуальных машин в Vitastor](#блокировка-доступа-вм-в-vitastor)
-
-## Ручная установка
-
-Сначала установите саму OpenNebula. После этого, на каждом сервере:
-
- Скопируйте директорию [opennebula/remotes](../../opennebula/remotes) в `/var/lib/one`: `cp -r opennebula/remotes /var/lib/one/`
- Скопируйте директорию [opennebula/sudoers.d](../../opennebula/sudoers.d) в `/etc`: `cp -r opennebula/sudoers.d /etc/`
- Примените патч [downloader-vitastor.sh.diff](../../opennebula/remotes/datastore/vitastor/downloader-vitastor.sh.diff) к `/var/lib/one/remotes/datastore/downloader.sh`:
-  `patch /var/lib/one/remotes/datastore/downloader.sh < opennebula/remotes/datastore/vitastor/downloader-vitastor.sh.diff` - либо прочитайте патч и примените изменение вручную
- Добавьте `kvm-vitastor` в список `LIVE_DISK_SNAPSHOTS` в файле `/etc/one/vmm_exec/vmm_execrc`
- Если вы используете Debian или Ubuntu (и AppArmor), добавьте пути к файлу(ам) конфигурации Vitastor в файл `/etc/apparmor.d/local/abstractions/libvirt-qemu`: например,
-  `echo '  "/etc/vitastor/vitastor.conf" r,' >> /etc/apparmor.d/local/abstractions/libvirt-qemu`
- Примените изменения `/etc/one/oned.conf`
-
-### Изменения oned.conf
-
-1. Добавьте переопределение скрипта deploy в VM_MAD kvm, добавив `-l deploy.vitastor` в `ARGUMENTS`:
-
-```diff
- VM_MAD = [
-     NAME           = "kvm",
-     SUNSTONE_NAME  = "KVM",
-     EXECUTABLE     = "one_vmm_exec",
-    ARGUMENTS      = "-t 15 -r 0 kvm -p",
-+    ARGUMENTS      = "-t 15 -r 0 kvm -p -l deploy=deploy.vitastor",
-     DEFAULT        = "vmm_exec/vmm_exec_kvm.conf",
-     TYPE           = "kvm",
-     KEEP_SNAPSHOTS = "yes",
-     LIVE_RESIZE    = "yes",
-     SUPPORT_SHAREABLE    = "yes",
-     IMPORTED_VMS_ACTIONS = "terminate, terminate-hard, hold, release, suspend,
-         resume, delete, reboot, reboot-hard, resched, unresched, disk-attach,
-         disk-detach, nic-attach, nic-detach, snapshot-create, snapshot-delete,
-         resize, updateconf, update"
- ]
-```
-
-Опционально: если вы хотите также сохранять снимки памяти ВМ в Vitastor, добавьте
-`-l deploy=deploy.vitastor,save=save.vitastor,restore=restore.vitastor`
-вместо просто `-l deploy=deploy.vitastor`.
-
-2. Добавьте `vitastor` в значения TM_MAD.ARGUMENTS и DATASTORE_MAD.ARGUMENTS:
-
-```diff
- TM_MAD = [
-     EXECUTABLE = "one_tm",
-    ARGUMENTS = "-t 15 -d dummy,lvm,shared,fs_lvm,fs_lvm_ssh,qcow2,ssh,ceph,dev,vcenter,iscsi_libvirt"
-+    ARGUMENTS = "-t 15 -d dummy,lvm,shared,fs_lvm,fs_lvm_ssh,qcow2,ssh,ceph,vitastor,dev,vcenter,iscsi_libvirt"
- ]
-
- DATASTORE_MAD = [
-     EXECUTABLE = "one_datastore",
-    ARGUMENTS  = "-t 15 -d dummy,fs,lvm,ceph,dev,iscsi_libvirt,vcenter,restic,rsync -s shared,ssh,ceph,fs_lvm,fs_lvm_ssh,qcow2,vcenter"
-+    ARGUMENTS  = "-t 15 -d dummy,fs,lvm,ceph,vitastor,dev,iscsi_libvirt,vcenter,restic,rsync -s shared,ssh,ceph,vitastor,fs_lvm,fs_lvm_ssh,qcow2,vcenter"
- ]
-```
-
-3. Добавьте строчки с INHERIT_DATASTORE_ATTR для двух атрибутов Vitastor-хранилищ:
-
-```
-INHERIT_DATASTORE_ATTR = "VITASTOR_CONF"
-INHERIT_DATASTORE_ATTR = "IMAGE_PREFIX"
-```
-
-4. Добавьте TM_MAD_CONF и DS_MAD_CONF для Vitastor:
-
-```
-TM_MAD_CONF = [
-    NAME = "vitastor", LN_TARGET = "NONE", CLONE_TARGET = "SELF", SHARED = "YES",
-    DS_MIGRATE = "NO", DRIVER = "raw", ALLOW_ORPHANS="format",
-    TM_MAD_SYSTEM = "ssh,shared", LN_TARGET_SSH = "SYSTEM", CLONE_TARGET_SSH = "SYSTEM",
-    DISK_TYPE_SSH = "FILE", LN_TARGET_SHARED = "NONE",
-    CLONE_TARGET_SHARED = "SELF", DISK_TYPE_SHARED = "FILE"
-]
-
-DS_MAD_CONF = [
-    NAME = "vitastor",
-    REQUIRED_ATTRS = "DISK_TYPE,BRIDGE_LIST",
-    PERSISTENT_ONLY = "NO",
-    MARKETPLACE_ACTIONS = "export"
-]
-```
-
-## Создайте хранилища
-
-Примеры настроек хранилищ образов (image) и дисков ВМ (system):
-[opennebula/vitastor-imageds.conf](../../opennebula/vitastor-imageds.conf) и
-[opennebula/vitastor-systemds.conf](../../opennebula/vitastor-systemds.conf).
-
-Скопируйте настройки и поменяйте следующие параметры так, как вам необходимо:
-
- POOL_NAME - имя пула Vitastor для сохранения образов дисков.
- IMAGE_PREFIX - строка, добавляемая в начало имён образов дисков.
- BRIDGE_LIST - список серверов с доступом к кластеру Vitastor, используемых для операций с хранилищем образов (image, не system).
- VITASTOR_CONF - путь к конфигурации Vitastor. Имейте в виду, что этот путь также надо добавить в `/etc/apparmor.d/local/abstractions/libvirt-qemu`, если вы используете AppArmor.
- STAGING_DIR - путь к временному каталогу, используемому при импорте внешних образов. Должен иметь достаточно свободного места, чтобы вмещать скачанные образы.
-
-После этого создайте хранилища с помощью команд `onedatastore create vitastor-imageds.conf` и `onedatastore create vitastor-systemds.conf` (либо через UI).
-
-## Блокировка доступа ВМ в Vitastor
-
-Vitastor пока не поддерживает никакую аутентификацию, так что вы ДОЛЖНЫ заблокировать доступ гостевых ВМ
-в кластер Vitastor на сетевом уровне.
-
-Если вы используете VLAN-сети для ВМ - удостоверьтесь, что ВМ и гипервизор/сеть хранения помещены в разные
-изолированные друг от друга VLAN-ы.
-
-Если вы используете что-то более примитивное, например, мосты (bridge), вам, скорее всего, придётся вручную
-настроить iptables / межсетевой экран, чтобы разрешить доступ к Vitastor только с IP гипервизоров.
-
-Также в этом случае нужно будет переключить обычные мосты на "Bridged & Security Groups" и включить фильтр
-спуфинга IP в OpenNebula. Правда, реализация этого фильтра пока не полная, и она не блокирует доступ к
-локальным интерфейсам гипервизора. То есть, включённый фильтр спуфинга IP запрещает ВМ отправлять трафик
-с чужими IP к другим ВМ или во внешний мир, но не запрещает отправлять его напрямую гипервизору. Чтобы
-исправить это, тоже нужны дополнительные правила iptables.
-
-Таким образом, более-менее полная блокировка при использовании простой сети на сетевых мостах может
-выглядеть так (здесь `10.0.3.0/24` - подсеть ВМ, `10.0.2.0/24` - подсеть гипервизора):
-
-```
-# Разрешаем входящий трафик с физического устройства
-iptables -A INPUT -m physdev --physdev-in eth0 -j ACCEPT
-# Запрещаем трафик со всех ВМ, но с IP не из подсети ВМ
-iptables -A INPUT ! -s 10.0.3.0/24 -i onebr0 -j DROP
-# Запрещаем трафик от ВМ к сети гипервизора
-iptables -I FORWARD 1 -s 10.0.3.0/24 -d 10.0.2.0/24 -j DROP
-```
-
-## Тестирование
-
-Плагин OpenNebula по большей части состоит из bash-скриптов, и чтобы было понятнее, что они
-вообще делают - ниже приведены описания процедур, которыми можно протестировать каждый из них.
-
-| Скрипт                  | Описание                                      | Как протестировать                                                                   |
-| ----------------------- | --------------------------------------------- | ------------------------------------------------------------------------------------ |
-| vmm/kvm/deploy.vitastor | Запустить виртуальную машину                  | Создайте и запустите виртуальную машину с дисками Vitastor: постоянным / непостоянным / волатильным (временным). |
-| vmm/kvm/save.vitastor   | Сохранить снимок памяти ВМ                    | Остановите виртуальную машину командой "Остановить".                                 |
-| vmm/kvm/restore.vitastor| Восстановить снимок памяти ВМ                 | Запустите ВМ после остановки обратно.                                                |
-| datastore/clone         | Скопировать образ как "постоянный"            | Создайте шаблон ВМ и создайте из него постоянную ВМ.                                 |
-| datastore/cp            | Импортировать внешний образ                   | Импортируйте шаблон ВМ с образами дисков из Магазина OpenNebula.                     |
-| datastore/export        | Экспортировать образ как URL                  | Вероятно: экспортируйте шаблон ВМ с образами в Магазин.                              |
-| datastore/mkfs          | Создать образ с файловой системой             | Хранилище → Образы → Создать → Тип: базовый блок данных, Расположение: пустой образ диска, Файловая система: любая непустая. |
-| datastore/monitor       | Вывод статистики места в хранилище образов    | Проверьте статистику свободного/занятого места в списке хранилищ образов.            |
-| datastore/rm            | Удалить "постоянный" образ                    | Хранилище → Образы → Выберите образ → Удалить.                                       |
-| datastore/snap_delete   | Удалить снимок "постоянного" образа           | Хранилище → Образы → Выберите образ → Выберите снимок → Удалить; <br> Чтобы создать образ со снимком: подключите постоянный образ к ВМ, создайте снимок, отключите образ. |
-| datastore/snap_flatten  | Откатить образ к снимку, удалив другие снимки | Хранилище → Образы → Выберите образ → Выберите снимок → "Выровнять" (flatten).       |
-| datastore/snap_revert   | Откатить образ к снимку                       | Хранилище → Образы → Выберите образ → Выберите снимок → Откатить.                    |
-| datastore/stat          | Показать виртуальный размер образа в МБ       | Неизвестно. По-видимому, в плагинах Vitastor и Ceph не используется.                 |
-| tm/clone                | Клонировать "непостоянный" образ в диск ВМ    | Подключите "непостоянный" образ к ВМ.                                                |
-| tm/context              | Создать диск контекстуализации ВМ             | Создайте ВМ с контекстуализацией, как обычно. Но тестировать особенно нечего: в плагинах Vitastor и Ceph образ контекста хранится в локальной ФС гипервизора. |
-| tm/cpds                 | Копировать диск ВМ/его снимок в новый образ   | Выберите ВМ → Выберите диск → Опционально выберите снимок → "Сохранить как".         |
-| tm/delete               | Удалить диск-клон или волатильный диск ВМ     | Отключите волатильный или не-постоянный диск от ВМ.                                  |
-| tm/failmigrate          | Обработать неудачную миграцию                 | Тестировать нечего. Скрипт пуст в плагинах Vitastor и Ceph. В других плагинах скрипт должен откатывать действия tm/premigrate. |
-| tm/ln                   | Подключить "постоянный" образ к ВМ            | Тестировать нечего. Скрипт пуст в плагинах Vitastor и Ceph.                          |
-| tm/mkimage              | Создать волатильный диск, без или с ФС        | Подключите волатильный диск к ВМ, с или без файловой системы.                        |
-| tm/mkswap               | Создать волатильный диск подкачки             | Подключите волатильный диск к ВМ, форматированный как диск подкачки (swap).          |
-| tm/monitor              | Вывод статистики места в хранилище дисков ВМ  | Проверьте статистику свободного/занятого места в списке хранилищ дисков ВМ.          |
-| tm/mv                   | Мигрировать диск ВМ между хостами             | Мигрируйте ВМ между серверами. Правда, с точки зрения хранилища в плагинах Vitastor и Ceph этот скрипт ничего не делает. |
-| tm/mvds                 | Отключить "постоянный" образ от ВМ            | Тестировать нечего. Скрипт пуст в плагинах Vitastor и Ceph. В целом же скрипт обратный к tm/ln и в других хранилищах он может, например, копировать образ ВМ с диска гипервизора обратно в хранилище. |
-| tm/postbackup           | Выполняется после бэкапа                      | По-видимому, скрипт просто удаляет временные файлы после резервного копирования. Так что можно провести его и проверить, что на серверах не осталось временных файлов. |
-| tm/postbackup_live      | Выполняется после бэкапа запущенной ВМ        | То же, что tm/postbackup, но для запущенной ВМ.                                      |
-| tm/postmigrate          | Выполняется после миграции ВМ                 | Тестировать нечего. Однако, OpenNebula запускает скрипт только для системного хранилища, поэтому он вызывает аналогичные скрипты для хранилищ других дисков той же ВМ. Помимо этого в плагинах Vitastor и Ceph скрипт ничего не делает. |
-| tm/prebackup            | Выполнить резервное копирование дисков ВМ     | Создайте хранилище резервных копий типа "rsync" → Забэкапьте в него ВМ.              |
-| tm/prebackup_live       | То же самое для запущенной ВМ                 | То же, что tm/prebackup, но запускает fsfreeze/thaw (остановку доступа к дискам). Так что смысл теста - проведите резервное копирование и проверьте, что данные скопировались консистентно. |
-| tm/premigrate           | Выполняется перед миграцией ВМ                | Тестировать нечего. Аналогично tm/postmigrate запускается только для системного хранилища. |
-| tm/resize               | Изменить размер диска ВМ                      | Выберите ВМ → Выберите непостоянный диск → Измените его размер.                      |
-| tm/restore              | Восстановить диски ВМ из бэкапа               | Создайте хранилище резервных копий → Забэкапьте в него ВМ → Восстановите её обратно. |
-| tm/snap_create          | Создать снимок диска ВМ                       | Выберите ВМ → Выберите диск → Создайте снимок.                                       |
-| tm/snap_create_live     | Создать снимок диска запущенной ВМ            | Выберите запущенную ВМ → Выберите диск → Создайте снимок.                            |
-| tm/snap_delete          | Удалить снимок диска ВМ                       | Выберите ВМ → Выберите диск → Выберите снимок → Удалить.                             |
-| tm/snap_revert          | Откатить диск ВМ к снимку                     | Выберите ВМ → Выберите диск → Выберите снимок → Откатить.                            |
--- a/docs/installation/openstack.en.md
+++ b/docs/installation/openstack.en.md
@ -36,5 +36,5 @@ vitastor_pool_id = 1
 image_upload_use_cinder_backend = True
 ```

-To put Glance images in Vitastor, use [volume-backed images](https://docs.openstack.org/cinder/pike/admin/blockstorage-volume-backed-image.html),
+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.
--- a/docs/installation/openstack.ru.md
+++ b/docs/installation/openstack.ru.md
@ -36,5 +36,5 @@ image_upload_use_cinder_backend = True
 ```

 Чтобы помещать в Vitastor Glance-образы, нужно использовать
-[образы на основе томов Cinder](https://docs.openstack.org/cinder/pike/admin/blockstorage-volume-backed-image.html),
+[https://docs.openstack.org/cinder/pike/admin/blockstorage-volume-backed-image.html](образы на основе томов Cinder),
 однако, поддержка этой функции ещё не проверялась.
--- a/docs/installation/packages.en.md
+++ b/docs/installation/packages.en.md
@ -11,28 +11,24 @@
 - Trust Vitastor package signing key:
  `wget https://vitastor.io/debian/pubkey.gpg -O /etc/apt/trusted.gpg.d/vitastor.gpg`
 - Add Vitastor package repository to your /etc/apt/sources.list:
-  - Debian 12 (Bookworm/Sid): `deb https://vitastor.io/debian bookworm main`
-  - Debian 11 (Bullseye): `deb https://vitastor.io/debian bullseye main`
+  - Debian 11 (Bullseye/Sid): `deb https://vitastor.io/debian bullseye main`
  - Debian 10 (Buster): `deb https://vitastor.io/debian buster main`
-  - Add `-oldstable` to bookworm/bullseye/buster in this line to install the last
-    stable version from 0.9.x branch instead of 1.x
- Install packages: `apt update; apt install vitastor lp-solve etcd linux-image-amd64 qemu-system-x86`
+- 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.rpm`
  - CentOS 8: `dnf install https://vitastor.io/rpms/centos/8/vitastor-release.rpm`
-  - AlmaLinux 9 and other RHEL 9 clones (Rocky, Oracle...): `dnf install https://vitastor.io/rpms/centos/9/vitastor-release.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`
-  - RHEL 9 clones: not required
 - 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`
-  - RHEL 9 clones: `dnf install https://www.elrepo.org/elrepo-release-9.el9.elrepo.noarch.rpm`
 - Install packages: `yum/dnf install vitastor lpsolve etcd kernel-ml qemu-kvm`

 ## Installation requirements
@ -46,10 +42,3 @@
 - etcd 3.4.15 or newer. Earlier versions won't work because of various bugs,
  for example [#12402](https://github.com/etcd-io/etcd/pull/12402).
 - node.js 10 or newer
-
-## Version archive
-
-All previous Vitastor and other components (QEMU, etcd...) package builds
-can be found here:
-
-https://vitastor.io/archive/
--- a/docs/installation/packages.ru.md
+++ b/docs/installation/packages.ru.md
@ -11,28 +11,24 @@
 - Добавьте ключ репозитория Vitastor:
  `wget https://vitastor.io/debian/pubkey.gpg -O /etc/apt/trusted.gpg.d/vitastor.gpg`
 - Добавьте репозиторий Vitastor в /etc/apt/sources.list:
-  - Debian 12 (Bookworm/Sid): `deb https://vitastor.io/debian bookworm main`
-  - Debian 11 (Bullseye): `deb https://vitastor.io/debian bullseye main`
+  - Debian 11 (Bullseye/Sid): `deb https://vitastor.io/debian bullseye main`
  - Debian 10 (Buster): `deb https://vitastor.io/debian buster main`
-  - Добавьте `-oldstable` к слову bookworm/bullseye/buster в этой строке, чтобы
-    установить последнюю стабильную версию из ветки 0.9.x вместо 1.x
- Установите пакеты: `apt update; apt install vitastor lp-solve etcd linux-image-amd64 qemu-system-x86`
+- Для 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.rpm`
  - CentOS 8: `dnf install https://vitastor.io/rpms/centos/8/vitastor-release.rpm`
-  - AlmaLinux 9 и другие клоны RHEL 9 (Rocky, Oracle...): `dnf install https://vitastor.io/rpms/centos/9/vitastor-release.rpm`
 - Включите EPEL: `yum/dnf install epel-release`
 - Включите дополнительные репозитории CentOS:
  - CentOS 7: `yum install centos-release-scl`
  - CentOS 8: `dnf install centos-release-advanced-virtualization`
-  - Клоны RHEL 9: не нужно
 - Включите 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`
-  - Клоны RHEL 9: `dnf install https://www.elrepo.org/elrepo-release-9.el9.elrepo.noarch.rpm`
 - Установите пакеты: `yum/dnf install vitastor lpsolve etcd kernel-ml qemu-kvm`

 ## Установочные требования
@ -45,10 +41,3 @@
 - etcd 3.4.15 или новее. Более старые версии не будут работать из-за разных багов,
  например, [#12402](https://github.com/etcd-io/etcd/pull/12402).
 - node.js 10 или новее
-
-## Архив предыдущих версий
-
-Все предыдущие сборки пакетов Vitastor и других компонентов, таких, как QEMU
-и etcd, можно скачать по следующей ссылке:
-
-https://vitastor.io/archive/
--- a/docs/installation/proxmox.en.md
+++ b/docs/installation/proxmox.en.md
@ -6,10 +6,10 @@

 # Proxmox VE

-To enable Vitastor support in Proxmox Virtual Environment (6.4-8.1 are supported):
+To enable Vitastor support in Proxmox Virtual Environment (6.4-7.3 are supported):

 - Add the corresponding Vitastor Debian repository into sources.list on Proxmox hosts:
-  bookworm for 8.1, pve8.0 for 8.0, bullseye for 7.4, pve7.3 for 7.3, pve7.2 for 7.2, pve7.1 for 7.1, buster for 6.4
+  buster for 6.4, bullseye for 7.3, pve7.1 for 7.1, pve7.2 for 7.2
 - 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),
@ -17,15 +17,15 @@ To enable Vitastor support in Proxmox Virtual Environment (6.4-8.1 are supported
 - 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_ssd` is Proxmox storage pool id):
+are listed below with their default values):

 ```
-vitastor: vitastor_ssd
+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), OPTIONAL, required only if missing in the configuration file
+    # 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
@ -35,5 +35,5 @@ vitastor: vitastor_ssd
    vitastor_nbd 0
 ```

-\* Note: you can also manually copy [patches/VitastorPlugin.pm](../../patches/VitastorPlugin.pm) to Proxmox hosts
+\* Note: you can also manually copy [patches/VitastorPlugin.pm](patches/VitastorPlugin.pm) to Proxmox hosts
 as `/usr/share/perl5/PVE/Storage/Custom/VitastorPlugin.pm` instead of installing pve-storage-vitastor.
--- a/docs/installation/proxmox.ru.md
+++ b/docs/installation/proxmox.ru.md
@ -1,30 +1,30 @@
-[Документация](../../README-ru.md#документация) → Установка → Proxmox VE
+[Документация](../../README-ru.md#документация) → Установка → Proxmox

 -----

 [Read in English](proxmox.en.md)

-# Proxmox VE
+# Proxmox

-Чтобы подключить Vitastor к Proxmox Virtual Environment (поддерживаются версии 6.4-8.1):
+Чтобы подключить Vitastor к Proxmox Virtual Environment (поддерживаются версии 6.4-7.3):

 - Добавьте соответствующий Debian-репозиторий Vitastor в sources.list на хостах Proxmox:
-  bookworm для 8.1, pve8.0 для 8.0, bullseye для 7.4, pve7.3 для 7.3, pve7.2 для 7.2, pve7.1 для 7.1, buster для 6.4
+  buster для 6.4, bullseye для 7.3, pve7.1 для 7.1, pve7.2 для 7.2
 - Установите пакеты 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_ssd` - имя хранилища в Proxmox):
+перечислены внизу для понимания значений по умолчанию):

 ```
-vitastor: vitastor_ssd
+vitastor: vitastor
    # Пул, в который будут помещаться образы дисков
    vitastor_pool testpool
    # Путь к файлу конфигурации
    vitastor_config_path /etc/vitastor/vitastor.conf
-    # Адрес(а) etcd, ОПЦИОНАЛЬНЫ, нужны, только если не указаны в vitastor.conf
+    # Адрес(а) etcd, нужны, только если не указаны в vitastor.conf
    vitastor_etcd_address 192.168.7.2:2379/v3
    # Префикс ключей метаданных в etcd
    vitastor_etcd_prefix /vitastor
@ -35,5 +35,5 @@ vitastor: vitastor_ssd
 ```

 \* Примечание: вместо установки пакета pve-storage-vitastor вы можете вручную скопировать файл
-[patches/VitastorPlugin.pm](../../patches/VitastorPlugin.pm) на хосты Proxmox как
+[patches/VitastorPlugin.pm](patches/VitastorPlugin.pm) на хосты Proxmox как
 `/usr/share/perl5/PVE/Storage/Custom/VitastorPlugin.pm`.
--- a/docs/installation/source.en.md
+++ b/docs/installation/source.en.md
@ -21,7 +21,7 @@

 ## Basic instructions

-Download source, for example using git: `git clone --recurse-submodules https://git.yourcmc.ru/vitalif/vitastor/`
+Download source, for example using git: `git clone --recurse-submodules https://yourcmc.ru/git/vitalif/vitastor/`

 Get `fio` source and symlink it into `<vitastor>/fio`. If you don't want to build fio engine,
 you can disable it by passing `-DWITH_FIO=no` to cmake.
@ -41,7 +41,7 @@ It's recommended to build the QEMU driver (qemu_driver.c) in-tree, as a part of
 QEMU build process. To do that:
 - Install vitastor client library headers (from source or from vitastor-client-dev package)
 - Take a corresponding patch from `patches/qemu-*-vitastor.patch` and apply it to QEMU source
- Copy `src/client/qemu_driver.c` to QEMU source directory as `block/vitastor.c`
+- Copy `src/qemu_driver.c` to QEMU source directory as `block/block-vitastor.c`
 - Build QEMU as usual

 But it is also possible to build it out-of-tree. To do that:
--- a/docs/installation/source.ru.md
+++ b/docs/installation/source.ru.md
@ -21,7 +21,7 @@

 ## Базовая инструкция

-Скачайте исходные коды, например, из git: `git clone --recurse-submodules https://git.yourcmc.ru/vitalif/vitastor/`
+Скачайте исходные коды, например, из git: `git clone --recurse-submodules https://yourcmc.ru/git/vitalif/vitastor/`

 Скачайте исходные коды пакета `fio`, распакуйте их и создайте символическую ссылку на них
 в директории исходников Vitastor: `<vitastor>/fio`. Либо, если вы не хотите собирать плагин fio,
@ -41,7 +41,7 @@ cmake .. && make -j8 install
 Драйвер QEMU (qemu_driver.c) рекомендуется собирать вместе с самим QEMU. Для этого:
 - Установите заголовки клиентской библиотеки Vitastor (из исходников или из пакета vitastor-client-dev)
 - Возьмите соответствующий патч из `patches/qemu-*-vitastor.patch` и примените его к исходникам QEMU
- Скопируйте [src/client/qemu_driver.c](../../src/client/qemu_driver.c) в директорию исходников QEMU как `block/vitastor.c`
+- Скопируйте [src/qemu_driver.c](../../src/qemu_driver.c) в директорию исходников QEMU как `block/block-vitastor.c`
 - Соберите QEMU как обычно

 Однако в целях отладки драйвер также можно собирать отдельно от QEMU. Для этого:
@ -60,7 +60,7 @@ cmake .. && make -j8 install
      * Для QEMU 2.0+: `<qemu>/qapi-types.h` &rarr; `<vitastor>/qemu/b/qemu/qapi-types.h`
   - `config-host.h` и `qapi` нужны, т.к. в них содержатся автогенерируемые заголовки
 - Сконфигурируйте cmake Vitastor с `WITH_QEMU=yes` (`cmake .. -DWITH_QEMU=yes`) и, если вы
-  используете RHEL-подобный дистрибутив, также с `QEMU_PLUGINDIR=qemu-kvm`.
+  используете RHEL-подобый дистрибутив, также с `QEMU_PLUGINDIR=qemu-kvm`.
 - После этого в процессе сборки Vitastor также будет собираться подходящий для вашей
  версии QEMU `block-vitastor.so`.
 - Таким образом можно использовать драйвер даже с немодифицированным QEMU, но в этом случае
--- a/docs/intro/architecture.en.md
+++ b/docs/intro/architecture.en.md
@ -6,150 +6,19 @@

 # Architecture

- [Server-side components](#server-side-components)
 - [Basic concepts](#basic-concepts)
- [Client-side components](#client-side-components)
- [Additional utilities](#additional-utilities)
- [Overall read/write process](#overall-read-write-process)
-  - [Nuances of request handling](#nuances-of-request-handling)
 - [Similarities to Ceph](#similarities-to-ceph)
 - [Differences from Ceph](#differences-from-ceph)
 - [Implementation Principles](#implementation-principles)

-## Server-side components
-
- **OSD** (Object Storage Daemon) is a process that directly works with the disk, stores data
-  and serves read/write requests. One OSD serves one disk (or one partition). OSDs talk to etcd
-  and to each other — they receive cluster state from etcd, and send read/write requests for
-  secondary copies of data to other OSDs.
- **etcd** — clustered key/value database, used as a reliable storage for configuration
-  and high-level cluster state. Etcd is the component that prevents splitbrain in the cluster.
-  Data blocks are not stored in etcd, etcd doesn't participate in data write or read path.
- **Монитор** — a separate node.js based daemon which monitors the cluster, calculates
-  required configuration changes and saves them to etcd, thus commanding OSDs to apply these
-  changes. Monitor also aggregates cluster statistics. OSD don't talk to monitor, monitor
-  only sends and receives data from etcd.
-
 ## Basic concepts

- **Pool** is a container for data that has equal redundancy scheme and disk placement rules.
- **PG (Placement Group)** is a "shard" of the cluster, subdivision unit that has its own
-  set of OSDs for data storage.
- **Failure Domain** is a group of OSDs, from the simultaneous failure of which you are
-  protected by Vitastor. Default failure domain is "host" (server), but you choose a
-  larger (for example, a rack of servers) or smaller (a single drive) failure domain
-  for every pool.
- **Placement Tree** (similar to Ceph CRUSH Tree) groups OSDs in a hierarchy to later
-  split them into Failure Domains.
-
-## Client-side components
-
- **Client library** encapsulates client I/O logic. Client library connects to etcd and to all OSDs,
-  receives cluster state from etcd, sends read and write requests directly to all OSDs. Due
-  to the symmetric distributed architecture, all data blocks (each 128 KB by default) are placed
-  to different OSDs, but clients always know where each data block is stored and connect directly
-  to the right OSD.
-
-All other client-side components are based on the client library:
-
- **[vitastor-cli](../usage/cli.en.md)** — command-line utility for cluster management.
-  Allows to view cluster state, manage pools and images, i.e. create, modify and remove
-  virtual disks, their snapshots and clones.
- **[QEMU driver](../usage/qemu.en.md)** — pluggable QEMU module allowing QEMU/KVM virtual
-  machines work with virtual Vitastor disks directly from userspace through the client library,
-  without the need to attach disks as kernel block devices. However, if you want to attach
-  disks, you can also do that with the same driver and [VDUSE](../usage/qemu.en.md#vduse).
- **[vitastor-nbd](../usage/nbd.en.md)** — utility that allows to attach Vitastor disks as
-  kernel block devices using NBD (Network Block Device), which works more like "BUSE"
-  (Block Device In Userspace). Vitastor doesn't have Linux kernel modules for the same task
-  (at least by now). NBD is an older, non-recommended way to attach disks — you should use
-  VDUSE whenever you can.
- **[CSI driver](../installation/kubernetes.en.md)** — driver for attaching Vitastor images
-  as Kubernetes persistent volumes. Works through VDUSE (when available) or NBD — images are
-  attached as kernel block devices and mounted into containers.
- **Drivers for Proxmox, OpenStack and so on** — pluggable modules for corresponding systems,
-  allowing to use Vitastor as storage in them.
- **[vitastor-nfs](../usage/nfs.en.md)** — NFS 3.0 server allowing export of two file system variants:
-  the first is a simplified pseudo-FS for file-based access to Vitastor block images (for non-QEMU
-  hypervisors with NFS support), the second is **VitastorFS**, full-featured clustered POSIX FS.
-  Both variants support parallel access from multiple vitastor-nfs servers. In fact, you are
-  not required to setup separate NFS servers at all and use vitastor-nfs mount command on every
-  client node — it starts the NFS server and mounts the FS locally.
- **[fio driver](../usage/fio.en.md)** — pluggable module for fio disk benchmarking tool for
-  running performance tests on your Vitastor cluster.
- **vitastor-kv** — client for a key-value DB working over shared block volumes (usual
-  vitastor images). VitastorFS metadata is stored in vitastor-kv.
-
-## Additional utilities
-
- **vitastor-disk** — a Vitastor OSD disk management tool. You can create, remove,
-  resize and move OSD partitions with it.
-
-## Overall read/write process
-
- Vitastor stores virtual disks, also named "images" or "inodes".
- Each image is stored in some pool. Pool specifies storage parameters such as redundancy
-  scheme (replication or EC — erasure codes, i.e. error correction codes), failure domain
-  and restrictions on OSD selection for image data placement. See [Pool configuration](../config/pool.en.md) for details.
- Each image is split into objects/blocks of fixed size, equal to [block_size](../config/layout-cluster.en.md#block_size)
-  (128 KB by default), multiplied by data part count for EC or 1 for replicas. That is,
-  if a pool uses EC 4+2 coding scheme (4 data parts + 2 parity parts), then, with the
-  default block_size, images are split into 512 KB objects.
- Client read/write requests are split into parts at object boundaries.
- Each object is mapped to a PG number it belongs to, by simply taking a remainder of
-  division of its offset by PG count of the image's pool.
- Client reads primary OSD for all PGs from etcd. Primary OSD for each PG is assigned
-  by the monitor during cluster operation, along with the full PG OSD set.
- If not already connected, client connects to primary OSDs of all PGs involved in a
-  read/write request and sends parts of the request to them.
- If a primary OSD is unavailable, client retries connection attempts indefinitely
-  either until it becomes available or until the monitor assigns another OSD as primary
-  for that PG.
- Client also retries requests if the primary OSD replies with error code EPIPE, meaning
-  that the PG is inactive at this OSD at the moment - for example, when the primary OSD
-  is switched, or if the primary OSD itself loses connection to replicas during request
-  handling.
- Primary OSD determines where the parts of the object are stored. By default, all objects
-  are assumed to be stored at the target OSD set of a PG, but some of them may be present
-  at a different OSD set if they are degraded or moved, or if the data rebalancing process
-  is active. OSDs doesn't do any network requests, if calculates locations of all objects
-  during PG activation and stores it in memory.
- Primary OSD handles the request locally when it can - for example, when it's a read
-  from a replicated pool or when it's a read from a EC pool involving only one data part
-  stored on the OSD's local disk.
- When a request requires reads or writes to additional OSDs, primary OSD uses already
-  established connections to secondary OSDs of the PG to execute these requests. This happens
-  in parallel to local disk operations. All such connections are guaranteed to be already
-  established when the PG is active, and if any of them is dropped, PG is restarted and
-  all current read/write operations to it fail with EPIPE error and are retried by clients.
- After completing all secondary read/write requests, primary OSD sends the response to
-  the client.
-
-### Nuances of request handling
-
- If a pool uses erasure codes and some of the OSDs are unavailable, primary OSDs recover
-  data from the remaining parts during read.
- Each object has a version number. During write, primary OSD first determines the current
-  version of the object. As primary OSD usually stores the object or its part itself, most
-  of the time version is read from the memory of the OSD itself. However, if primary OSD
-  doesn't contain parts of the object, it requests the version number from a secondary OSD
-  which has that part. Such request still doesn't involve reading from the disk though,
-  because object metadata, including version number, is always stored in OSD memory.
- If a pool uses erasure codes, partial writes of an object require reading other parts of
-  it from secondary OSDs or from the local disk of the primary OSD itself. This is called
-  "read-modify-write" process.
- If a pool uses erasure codes, two-phase write process is used to get rid of the Write Hole
-  problem: first a new version of object parts is written to all secondary OSDs without
-  removing the previous version, and then, after receiving successful write confirmations
-  from all OSDs, new version is committed and the old one is allowed to be removed.
- In a pool doesn't use immediate_commit mode, then write requests sent by clients aren't
-  treated as committed to physical media instantly. Clients have to send separate type of
-  requests (SYNC) to commit changes, and before it isn't sent, new versions of data are
-  allowed to be lost if some OSDs die. Thus, when immediate_commit is disabled, clients
-  store copies of all write requests in memory and repeat them from there when the
-  connection to primary OSD is lost. This in-memory copy is removed after a successful
-  SYNC, and to prevent excessive memory usage, clients also do an automatic SYNC
-  every [client_dirty_limit](../config/network.en.md#client_dirty_limit) written bytes.
+- OSD (Object Storage Daemon) is a process that stores data and serves read/write requests.
+- PG (Placement Group) is a "shard" of the cluster, group of data stored on one set of replicas.
+- Pool is a container for data that has equal redundancy scheme and placement rules.
+- Monitor is a separate daemon that watches cluster state and handles failures.
+- Failure Domain is a group of OSDs that you allow to fail. It's "host" by default.
+- Placement Tree groups OSDs in a hierarchy to later split them into Failure Domains.

 ## Similarities to Ceph

@ -175,7 +44,7 @@ All other client-side components are based on the client library:
  depends linearly on drive capacity and data store block size which is 128 KB by default.
  With 128 KB blocks metadata takes around 512 MB per 1 TB (which is still less than Ceph wants).
  Journal is also kept in memory by default, but in SSD-only clusters it's only 32 MB, and in SSD+HDD
-  clusters, where it's beneficial to increase it, [inmemory_journal](../config/osd.en.md#inmemory_journal) can be disabled.
+  clusters, where it's beneficial to increase it, [inmemory_journal](docs/config/osd.en.md#inmemory_journal) can be disabled.
 - Vitastor storage layer doesn't have internal copy-on-write or redirect-write. I know that maybe
  it's possible to create a good copy-on-write storage, but it's much harder and makes performance
  less deterministic, so CoW isn't used in Vitastor.
--- a/docs/intro/architecture.ru.md
+++ b/docs/intro/architecture.ru.md
@ -11,7 +11,6 @@
 - [Серверные компоненты](#серверные-компоненты)
 - [Базовые понятия](#базовые-понятия)
 - [Клиентские компоненты](#клиентские-компоненты)
- [Дополнительные утилиты](#дополнительные-утилиты)
 - [Общий процесс записи и чтения](#общий-процесс-записи-и-чтения)
  - [Особенности обработки запросов](#особенности-обработки-запросов)
 - [Схожесть с Ceph](#схожесть-с-ceph)
@ -35,9 +34,8 @@
 - **Пул (Pool)** — контейнер для данных, имеющих одну и ту же схему избыточности и правила распределения по OSD.
 - **PG (Placement Group)** — "шард", единица деления пулов в кластере, которой назначается свой набор
  OSD для хранения данных (копий или частей объектов).
- **Домен отказа (Failure Domain)** — группа OSD, от одновременного падения которых должен защищать
-  Vitastor. По умолчанию домен отказа — "host" (сервер), но вы можете установить для пула как больший
-  домен отказа (например, стойку серверов), так и меньший (например, отдельный диск).
+- **Домен отказа (Failure Domain)** — группа OSD, одновременное падение которых рассматривается
+  как вероятное. По умолчанию это "host" (сервер).
 - **Дерево распределения** (Placement Tree, в Ceph CRUSH Tree) — иерархическая группировка OSD
  в узлы, которые далее можно использовать как домены отказа.

@ -51,39 +49,24 @@

 На базе клиентской библиотеки реализованы все остальные клиенты:

- **[vitastor-cli](../usage/cli.ru.md)** — утилита командной строки для управления кластером.
-  Позволяет просматривать общее состояние кластера, управлять пулами и образами — то есть
-  создавать, менять и удалять виртуальные диски, их снимки и клоны.
- **[Драйвер QEMU](../usage/qemu.ru.md)** — подключаемый модуль QEMU, позволяющий QEMU/KVM
-  виртуальным машинам работать с виртуальными дисками Vitastor напрямую из пространства пользователя
-  с помощью клиентской библиотеки, без необходимости подключения дисков в виде блочных устройств
-  Linux. Если, однако, вы хотите подключать диски в виде блочных устройств, то вы тоже можете
-  сделать это с помощью того же самого драйвера и [VDUSE](../usage/qemu.ru.md#vduse).
- **[vitastor-nbd](../usage/nbd.ru.md)** — утилита, позволяющая монтировать образы Vitastor
-  в виде блочных устройств с помощью NBD (Network Block Device), на самом деле скорее работающего
-  как "BUSE" (Block Device In Userspace). Модуля ядра Linux для выполнения той же задачи в
-  Vitastor нет (по крайней мере, пока). NBD — более старый и нерекомендуемый способ подключения
-  дисков — вам следует использовать VDUSE всегда, когда это возможно.
- **[CSI драйвер](../installation/kubernetes.ru.md)** — драйвер для подключения Vitastor-образов
-  в виде персистентных томов (PV) Kubernetes. Работает через VDUSE (если доступно) или через
-  NBD — образы отражаются в виде блочных устройств и монтируются в контейнеры.
+- **vitastor-cli** — утилита командной строки для управления кластером. В данный момент позволяет
+  просматривать общее состояние кластера и управлять образами — т.е. создавать, менять и удалять
+  виртуальные диски, их снимки и клоны.
+- **Драйвер QEMU** — подключаемый модуль QEMU, позволяющий QEMU/KVM виртуальным машинам работать
+  с виртуальными дисками Vitastor напрямую из пространства пользователя с помощью клиентской
+  библиотеки, без необходимости отображения дисков в виде блочных устройств.
+- **vitastor-nbd** — утилита, позволяющая монтировать образы Vitastor в виде блочных устройств
+  с помощью NBD (Network Block Device), на самом деле скорее работающего как "BUSE"
+  (Block Device In Userspace). Модуля ядра Linux для выполнения той же задачи в Vitastor нет
+  (по крайней мере, пока).
+- **CSI драйвер** — драйвер для подключения Vitastor-образов в виде персистентных томов (PV) Kubernetes.
+  Работает через vitastor-nbd — образы отражаются в виде блочных устройств и монтируются
+  в контейнеры.
 - **Драйвера Proxmox, OpenStack и т.п.** — подключаемые модули для соответствующих систем,
  позволяющие использовать Vitastor как хранилище в оных.
- **[vitastor-nfs](../usage/nfs.ru.md)** — NFS 3.0 сервер, предоставляющий два варианта файловой системы:
-  первая — упрощённая для файлового доступа к блочным образам (для не-QEMU гипервизоров, поддерживающих NFS),
-  вторая — VitastorFS, полноценная кластерная POSIX ФС. Оба варианта поддерживают параллельный
-  доступ с нескольких vitastor-nfs серверов. На самом деле можно вообще не выделять
-  отдельные NFS-серверы, а вместо этого использовать команду vitastor-nfs mount, запускающую
-  NFS-сервер прямо на клиентской машине и монтирующую ФС локально.
- **[Драйвер fio](../usage/fio.ru.md)** — подключаемый модуль для утилиты тестирования
-  производительности дисков fio, позволяющий тестировать Vitastor-кластеры.
- **vitastor-kv** — клиент для key-value базы данных, работающей поверх разделяемого блочного
-  образа (обычного блочного образа vitastor). Метаданные VitastorFS хранятся именно в vitastor-kv.
-
-## Дополнительные утилиты
-
- **vitastor-disk** — утилита для разметки дисков под Vitastor OSD. С её помощью можно
-  создавать, удалять, менять размеры или перемещать разделы OSD.
+- **vitastor-nfs** — утилита, предоставляющая файловый доступ к образам в кластере Vitastor
+  по протоколу NFS 3.0. Предназначена для гипервизоров, не основанных на QEMU и Linux, но при
+  этом поддерживающих NFS.

 ## Общий процесс записи и чтения

@ -114,22 +97,16 @@
  находиться на других OSD, если эти объекты деградированы или перемещены, или идёт процесс
  ребаланса. Запросы для проверки по сети не отправляются, информация о местоположении всех
  объектов рассчитывается первичным OSD при активации PG и хранится в памяти.
- Когда это возможно, первичный OSD обрабатывает запрос локально. Например, так происходит
-  при чтениях объектов из пулов с репликацией или при чтении из EC пула, затрагивающего
-  только часть, хранимую на диске самого первичного OSD.
- Когда запрос требует записи или чтения с вторичных OSD, первичный OSD использует заранее
-  установленные соединения с ними для выполнения этих запросов. Это происходит параллельно
-  локальным операциям чтения/записи с диска самого OSD. Так как соединения к вторичным OSD PG
-  устанавливаются при её запуске, то они уже гарантированно установлены, когда PG активна,
-  и если любое из этих соединений отключается, PG перезапускается, а все текущие запросы чтения
-  и записи в неё завершаются с ошибкой EPIPE, после чего повторяются клиентами.
+- Первичный OSD соединяется (если ещё не соединён) с вторичными OSD, на которых располагаются
+  части объекта, и отправляет им запросы чтения/записи, а также читает/пишет из/в своё локальное
+  хранилище, если сам входит в набор.
 - После завершения всех вторичных операций чтения/записи первичный OSD отправляет ответ клиенту.

 ### Особенности обработки запросов

 - Если в пуле используются коды коррекции ошибок и при этом часть OSD недоступна, первичный
  OSD при чтении восстанавливает данные из оставшихся частей.
- Каждый объект имеет номер версии. При записи объекта первичный OSD сначала получает номер
+- Каждый объект имеет номер версии. При записи объекта первичный OSD сначала читает из номер
  версии объекта. Так как первичный OSD обычно сам хранит копию или часть объекта, номер
  версии обычно читается из памяти самого OSD. Однако, если ни одна часть обновляемого объекта
  не находится на первичном OSD, для получения номера версии он обращается к одному из вторичных
@ -137,20 +114,20 @@
  так как метаданные объектов, включая номер версии, все OSD хранят в памяти.
 - Если в пуле используются коды коррекции ошибок, перед частичной записью объекта для вычисления
  чётности зачастую требуется чтение частей объекта с вторичных OSD или с локального диска
-  самого первичного OSD. Это называется процессом "чтение-модификация-запись" (read-modify-write).
- Если в пуле используются коды коррекции ошибок, для закрытия Write Hole применяется
+  самого первичного OSD.
+- Также, если в пуле используются коды коррекции ошибок, для закрытия Write Hole применяется
  двухфазный алгоритм записи: сначала на все вторичные OSD записывается новая версия частей
  объекта, но при этом старая версия не удаляется, а потом, после получения подтверждения
  успешной записи от всех вторичных OSD, новая версия фиксируется и разрешается удаление старой.
- Если в пуле не включён режим immediate_commit, то запросы записи, отправляемые клиентами,
+- Если в кластере не включён режим immediate_commit, то запросы записи, отправляемые клиентами,
  не считаются зафиксированными на физических накопителях сразу. Для фиксации данных клиенты
  должны отдельно отправлять запросы SYNC (отдельный от чтения и записи вид запроса),
  а пока такой запрос не отправлен, считается, что записанные данные могут исчезнуть,
  если соответствующий OSD упадёт. Поэтому, когда режим immediate_commit отключён, все
  запросы записи клиенты копируют в памяти и при потере соединения и повторном соединении
-  с OSD повторяют из памяти. Скопированные в память данные удаляются при успешном SYNC,
+  с OSD повторяют из памяти. Скопированные в память данные удаляются при успешном fsync,
  а чтобы хранение этих данных не приводило к чрезмерному потреблению памяти, клиенты
-  автоматически выполняют SYNC каждые [client_dirty_limit](../config/network.ru.md#client_dirty_limit)
+  автоматически выполняют fsync каждые [client_dirty_limit](../config/network.ru.md#client_dirty_limit)
  записанных байт.

 ## Схожесть с Ceph
@ -179,7 +156,7 @@
  блока хранилища (block_size, по умолчанию 128 КБ). С 128 КБ блоком потребление памяти
  составляет примерно 512 МБ на 1 ТБ данных. Журналы по умолчанию тоже хранятся в памяти,
  но в SSD-кластерах нужный размер журнала составляет всего 32 МБ, а в гибридных (SSD+HDD)
-  кластерах, в которых есть смысл делать журналы больше, можно отключить [inmemory_journal](../config/osd.ru.md#inmemory_journal).
+  кластерах, в которых есть смысл делать журналы больше, можно отключить [inmemory_journal](../docs/config/osd.ru.md#inmemory_journal).
 - В Vitastor нет внутреннего copy-on-write. Я считаю, что реализация CoW-хранилища гораздо сложнее,
  поэтому сложнее добиться устойчиво хороших результатов. Возможно, в один прекрасный день
  я придумаю красивый алгоритм для CoW-хранилища, но пока нет — внутреннего CoW в Vitastor не будет.
--- a/docs/intro/features.en.md
+++ b/docs/intro/features.en.md
@ -13,7 +13,7 @@
 ## Server-side features

 - Basic part: highly-available block storage with symmetric clustering and no SPOF
- [Performance](../performance/bench2.en.md) ;-D
+- [Performance](../performance/comparison1.en.md) ;-D
 - [Multiple redundancy schemes](../config/pool.en.md#scheme): Replication, XOR n+1, Reed-Solomon erasure codes
  based on jerasure and ISA-L libraries with any number of data and parity drives in a group
 - Configuration via simple JSON data structures in etcd (parameters, pools and images)
@ -29,40 +29,34 @@
 - Snapshots and copy-on-write image clones
 - [Write throttling to smooth random write workloads in SSD+HDD configurations](../config/osd.en.md#throttle_small_writes)
 - [RDMA/RoCEv2 support via libibverbs](../config/network.en.md#rdma_device)
- [Scrubbing](../config/osd.en.md#auto_scrub) (verification of copies)
- [Checksums](../config/layout-osd.en.md#data_csum_type)
- [Client write-back cache](../config/client.en.md#client_enable_writeback)
- [Intelligent recovery auto-tuning](../config/osd.en.md#recovery_tune_interval)
- [Clustered file system](../usage/nfs.en.md#vitastorfs)
- [Experimental internal etcd replacement - antietcd](../config/monitor.en.md#use_antietcd)
- [Built-in Prometheus metric exporter](../config/monitor.en.md#enable_prometheus)

 ## Plugins and tools

- [Proxmox storage plugin and packages](../installation/proxmox.en.md)
- [OpenNebula storage plugin](../installation/opennebula.en.md)
- [CSI plugin for Kubernetes](../installation/kubernetes.en.md)
- [OpenStack support: Cinder driver, Nova and libvirt patches](../installation/openstack.en.md)
 - [Debian and CentOS packages](../installation/packages.en.md)
 - [Image management CLI (vitastor-cli)](../usage/cli.en.md)
- [Disk management CLI (vitastor-disk)](../usage/disk.en.md)
+- [Disk management CLI (vitastor-disk)](docs/usage/disk.en.md)
 - Generic user-space client library
 - [Native QEMU driver](../usage/qemu.en.md)
 - [Loadable fio engine for benchmarks](../usage/fio.en.md)
 - [NBD proxy for kernel mounts](../usage/nbd.en.md)
- [Simplified NFS proxy for file-based image access emulation (suitable for VMWare)](../usage/nfs.en.md#pseudo-fs)
+- [CSI plugin for Kubernetes](../installation/kubernetes.en.md)
+- [OpenStack support: Cinder driver, Nova and libvirt patches](../installation/openstack.en.md)
+- [Proxmox storage plugin and packages](../installation/proxmox.en.md)
+- [Simplified NFS proxy for file-based image access emulation (suitable for VMWare)](../usage/nfs.en.md)

 ## Roadmap

 The following features are planned for the future:

- Control plane optimisation
 - Other administrative tools
 - Web GUI
- iSCSI and NVMeoF gateways
+- OpenNebula plugin
+- iSCSI proxy
 - Multi-threaded client
 - Faster failover
- S3
+- Scrubbing without checksums (verification of replicas)
+- Checksums
 - Tiered storage (SSD caching)
 - NVDIMM support
 - Compression (possibly)
+- Read caching using system page cache (possibly)
--- a/docs/intro/features.ru.md
+++ b/docs/intro/features.ru.md
@ -13,7 +13,7 @@
 ## Серверные функции

 - Базовая часть - надёжное кластерное блочное хранилище без единой точки отказа
- [Производительность](../performance/bench2.ru.md) ;-D
+- [Производительность](../comparison1.ru.md) ;-D
 - [Несколько схем отказоустойчивости](../config/pool.ru.md#scheme): репликация, XOR n+1 (1 диск чётности), коды коррекции ошибок
  Рида-Соломона на основе библиотек jerasure и ISA-L с любым числом дисков данных и чётности в группе
 - Конфигурация через простые человекочитаемые JSON-структуры в etcd
@ -31,38 +31,31 @@
 - Снапшоты и copy-on-write клоны
 - [Сглаживание производительности случайной записи в SSD+HDD конфигурациях](../config/osd.ru.md#throttle_small_writes)
 - [Поддержка RDMA/RoCEv2 через libibverbs](../config/network.ru.md#rdma_device)
- [Фоновая проверка целостности](../config/osd.ru.md#auto_scrub) (сверка копий)
- [Контрольные суммы](../config/layout-osd.ru.md#data_csum_type)
- [Буферизация записи на стороне клиента](../config/client.ru.md#client_enable_writeback)
- [Интеллектуальная автоподстройка скорости восстановления](../config/osd.ru.md#recovery_tune_interval)
- [Кластерная файловая система](../usage/nfs.ru.md#vitastorfs)
- [Экспериментальная встроенная замена etcd - antietcd](../config/monitor.ru.md#use_antietcd)
- [Встроенный Prometheus-экспортер метрик](../config/monitor.ru.md#enable_prometheus)

 ## Драйверы и инструменты

- [Плагин для Proxmox](../installation/proxmox.ru.md)
- [Плагин для OpenNebula](../installation/opennebula.ru.md)
- [CSI-плагин для Kubernetes](../installation/kubernetes.ru.md)
- [Базовая поддержка OpenStack: драйвер Cinder, патчи для Nova и libvirt](../installation/openstack.ru.md)
 - [Пакеты для Debian и CentOS](../installation/packages.ru.md)
 - [Консольный интерфейс управления образами (vitastor-cli)](../usage/cli.ru.md)
- [Инструмент управления дисками (vitastor-disk)](../usage/disk.ru.md)
+- [Инструмент управления дисками (vitastor-disk)](docs/usage/disk.ru.md)
 - Общая пользовательская клиентская библиотека для работы с кластером
 - [Драйвер диска для QEMU](../usage/qemu.ru.md)
 - [Драйвер диска для утилиты тестирования производительности fio](../usage/fio.ru.md)
 - [NBD-прокси для монтирования образов ядром](../usage/nbd.ru.md) ("блочное устройство в режиме пользователя")
- [Упрощённая NFS-прокси для эмуляции файлового доступа к образам (подходит для VMWare)](../usage/nfs.ru.md#псевдо-фс)
+- [CSI-плагин для Kubernetes](../installation/kubernetes.ru.md)
+- [Базовая поддержка OpenStack: драйвер Cinder, патчи для Nova и libvirt](../installation/openstack.ru.md)
+- [Плагин для Proxmox](../installation/proxmox.ru.md)
+- [Упрощённая NFS-прокси для эмуляции файлового доступа к образам (подходит для VMWare)](../usage/nfs.ru.md)

 ## Планы развития

- Оптимизация слоя управления
 - Другие инструменты администрирования
 - Web-интерфейс
- iSCSI и NVMeoF прокси
+- Плагин для OpenNebula
+- iSCSI-прокси
 - Многопоточный клиент
 - Более быстрое переключение при отказах
- S3
+- Фоновая проверка целостности без контрольных сумм (сверка реплик)
+- Контрольные суммы
 - Поддержка SSD-кэширования (tiered storage)
 - Поддержка NVDIMM
 - Возможно, сжатие
--- a/docs/intro/quickstart.en.md
+++ b/docs/intro/quickstart.en.md
@ -7,34 +7,22 @@
 # Quick Start

 - [Preparation](#preparation)
- [Recommended drives](#recommended-drives)
 - [Configure monitors](#configure-monitors)
 - [Configure OSDs](#configure-osds)
 - [Create a pool](#create-a-pool)
 - [Check cluster status](#check-cluster-status)
 - [Create an image](#create-an-image)
 - [Install plugins](#install-plugins)
- [Create VitastorFS](#create-vitastorfs)

 ## Preparation

 - 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. Read more about capacitors
  [here](../config/layout-cluster.en.md#immediate_commit).
- If you want to use HDDs, get modern HDDs with Media Cache or SSD Cache: HGST Ultrastar,
-  Toshiba MG, Seagate EXOS or something similar. If your drives don't have such cache then
-  you also need small SSDs for journal and metadata (even 2 GB per 1 TB of HDD space is enough).
 - Get a fast network (at least 10 Gbit/s). Something like Mellanox ConnectX-4 with RoCEv2 is ideal.
 - Disable CPU powersaving: `cpupower idle-set -D 0 && cpupower frequency-set -g performance`.
 - [Install Vitastor packages](../installation/packages.en.md).

-## Recommended drives
-
- SATA SSD: Micron 5100/5200/5300/5400, Samsung PM863/PM883/PM893, Intel D3-S4510/4520/4610/4620, Kingston DC500M
- NVMe: Micron 9100/9200/9300/9400, Micron 7300/7450, Samsung PM983/PM9A3, Samsung PM1723/1735/1743,
-  Intel DC-P3700/P4500/P4600, Intel D5-P4320, Intel D7-P5500/P5600, Intel Optane, Kingston DC1000B/DC1500M
- HDD: HGST Ultrastar, Toshiba MG, Seagate EXOS
-
 ## Configure monitors

 On the monitor hosts:
@ -57,10 +45,7 @@ On the monitor hosts:
  }
  ```
 - Initialize OSDs:
-  - SSD-only or HDD-only: `vitastor-disk prepare /dev/sdXXX [/dev/sdYYY ...]`.
-    Add `--disable_data_fsync off` to leave disk write cache enabled if you use
-    desktop SSDs without capacitors. Do NOT add `--disable_data_fsync off` if you
-    use HDDs or SSD+HDD.
+  - SSD-only: `vitastor-disk prepare /dev/sdXXX [/dev/sdYYY ...]`
  - Hybrid, SSD+HDD: `vitastor-disk prepare --hybrid /dev/sdXXX [/dev/sdYYY ...]`.
    Pass all your devices (HDD and SSD) to this script &mdash; it will partition disks and initialize journals on its own.
    This script skips HDDs which are already partitioned so if you want to use non-empty disks for
@ -68,32 +53,28 @@ On the monitor hosts:
    but some free unpartitioned space must be available because the script creates new partitions for journals.
 - You can change OSD configuration in units or in `vitastor.conf`.
  Check [Configuration Reference](../config.en.md) for parameter descriptions.
+- If all your drives have capacitors, create global configuration in etcd: \
+  `etcdctl --endpoints=... put /vitastor/config/global '{"immediate_commit":"all"}'`
 - Start all OSDs: `systemctl start vitastor.target`

 ## Create a pool

-Create a pool using vitastor-cli:
+Create pool configuration in etcd:

 ```
-vitastor-cli create-pool testpool --pg_size 2 --pg_count 256
+etcdctl --endpoints=... put /vitastor/config/pools '{"1":{"name":"testpool",
+  "scheme":"replicated","pg_size":2,"pg_minsize":1,"pg_count":256,"failure_domain":"host"}}'
 ```

 For EC pools the configuration should look like the following:

 ```
-vitastor-cli create-pool testpool --ec 2+2 --pg_count 256
+etcdctl --endpoints=... put /vitastor/config/pools '{"2":{"name":"ecpool",
+  "scheme":"ec","pg_size":4,"parity_chunks":2,"pg_minsize":2,"pg_count":256,"failure_domain":"host"}'
 ```

-Add `--immediate_commit none` if you added `--disable_data_fsync off` at the OSD
-initialization step, or if `vitastor-disk` complained about impossibility to
-disable drive cache.
-
 After you do this, one of the monitors will configure PGs and OSDs will start them.

-If you use HDDs you should also add `"block_size": 1048576` to pool configuration.
-The other option is to add it into /vitastor/config/global, in this case it will
-apply to all pools by default.
-
 ## Check cluster status

 `vitastor-cli status`
@ -115,9 +96,3 @@ After that, you can [run benchmarks](../usage/fio.en.md) or [start QEMU manually
 - [Proxmox](../installation/proxmox.en.md)
 - [OpenStack](../installation/openstack.en.md)
 - [Kubernetes CSI](../installation/kubernetes.en.md)
-
-## Create VitastorFS
-
-If you want to use clustered file system in addition to VM or container images:
-
- [Follow the instructions here](../usage/nfs.en.md#vitastorfs)
--- a/docs/intro/quickstart.ru.md
+++ b/docs/intro/quickstart.ru.md
@ -7,34 +7,22 @@
 # Быстрый старт

 - [Подготовка](#подготовка)
- [Рекомендуемые диски](#рекомендуемые-диски)
 - [Настройте мониторы](#настройте-мониторы)
 - [Настройте OSD](#настройте-osd)
 - [Создайте пул](#создайте-пул)
 - [Проверьте состояние кластера](#проверьте-состояние-кластера)
 - [Создайте образ](#создайте-образ)
 - [Установите плагины](#установите-плагины)
- [Создайте VitastorFS](#создайте-vitastorfs)

 ## Подготовка

 - Возьмите серверы с SSD (SATA или NVMe), желательно с конденсаторами (серверные SSD). Можно
  использовать и десктопные SSD, включив режим отложенного fsync, но производительность будет хуже.
  О конденсаторах читайте [здесь](../config/layout-cluster.ru.md#immediate_commit).
- Если хотите использовать HDD, берите современные модели с Media или SSD кэшем - HGST Ultrastar,
-  Toshiba MG, Seagate EXOS или что-то похожее. Если такого кэша у ваших дисков нет,
-  обязательно возьмите SSD под метаданные и журнал (маленькие, буквально 2 ГБ на 1 ТБ HDD-места).
 - Возьмите быструю сеть, минимум 10 гбит/с. Идеал - что-то вроде Mellanox ConnectX-4 с RoCEv2.
 - Для лучшей производительности отключите энергосбережение CPU: `cpupower idle-set -D 0 && cpupower frequency-set -g performance`.
 - [Установите пакеты Vitastor](../installation/packages.ru.md).

-## Рекомендуемые диски
-
- SATA SSD: Micron 5100/5200/5300/5400, Samsung PM863/PM883/PM893, Intel D3-S4510/4520/4610/4620, Kingston DC500M
- NVMe: Micron 9100/9200/9300/9400, Micron 7300/7450, Samsung PM983/PM9A3, Samsung PM1723/1735/1743,
-  Intel DC-P3700/P4500/P4600, Intel D5-P4320, Intel D7-P5500/P5600, Intel Optane, Kingston DC1000B/DC1500M
- HDD: HGST Ultrastar, Toshiba MG, Seagate EXOS
-
 ## Настройте мониторы

 На хостах, выделенных под мониторы:
@ -57,10 +45,7 @@
  }
  ```
 - Инициализуйте OSD:
-  - Только SSD или только HDD: `vitastor-disk prepare /dev/sdXXX [/dev/sdYYY ...]`.
-    Если вы используете десктопные SSD без конденсаторов, добавьте опцию `--disable_data_fsync off`,
-    чтобы оставить кэш записи диска включённым. НЕ добавляйте эту опцию, если используете
-    жёсткие диски (HDD).
+  - SSD: `vitastor-disk prepare /dev/sdXXX [/dev/sdYYY ...]`
  - Гибридные, SSD+HDD: `vitastor-disk prepare --hybrid /dev/sdXXX [/dev/sdYYY ...]`.
    Передайте все ваши SSD и HDD скрипту в командной строке подряд, скрипт автоматически выделит
    разделы под журналы на SSD и данные на HDD. Скрипт пропускает HDD, на которых уже есть разделы
@ -69,32 +54,28 @@
    для журналов, на SSD должно быть доступно свободное нераспределённое место.
 - Вы можете менять параметры OSD в юнитах systemd или в `vitastor.conf`. Описания параметров
  смотрите в [справке по конфигурации](../config.ru.md).
+- Если все ваши диски - серверные с конденсаторами, пропишите это в глобальную конфигурацию в etcd: \
+  `etcdctl --endpoints=... put /vitastor/config/global '{"immediate_commit":"all"}'`
 - Запустите все OSD: `systemctl start vitastor.target`

 ## Создайте пул

-Создайте пул с помощью vitastor-cli:
+Создайте конфигурацию пула с помощью etcdctl:

 ```
-vitastor-cli create-pool testpool --pg_size 2 --pg_count 256
+etcdctl --endpoints=... put /vitastor/config/pools '{"1":{"name":"testpool",
+  "scheme":"replicated","pg_size":2,"pg_minsize":1,"pg_count":256,"failure_domain":"host"}}'
 ```

 Для пулов с кодами коррекции ошибок конфигурация должна выглядеть примерно так:

 ```
-vitastor-cli create-pool testpool --ec 2+2 --pg_count 256
+etcdctl --endpoints=... put /vitastor/config/pools '{"2":{"name":"ecpool",
+  "scheme":"ec","pg_size":4,"parity_chunks":2,"pg_minsize":2,"pg_count":256,"failure_domain":"host"}'
 ```

-Добавьте также опцию `--immediate_commit none`, если вы добавляли `--disable_data_fsync off`
-на этапе инициализации OSD, либо если `vitastor-disk` ругался на невозможность отключения
-кэша дисков.
-
 После этого один из мониторов должен сконфигурировать PG, а OSD должны запустить их.

-Если вы используете HDD-диски, то добавьте в конфигурацию пулов опцию `"block_size": 1048576`.
-Также эту опцию можно добавить в /vitastor/config/global, в этом случае она будет
-применяться ко всем пулам по умолчанию.
-
 ## Проверьте состояние кластера

 `vitastor-cli status`
@ -116,10 +97,3 @@ vitastor-cli create -s 10G testimg
 - [Proxmox](../installation/proxmox.ru.md)
 - [OpenStack](../installation/openstack.ru.md)
 - [Kubernetes CSI](../installation/kubernetes.ru.md)
-
-## Создайте VitastorFS
-
-Если вы хотите использовать не только блочные образы виртуальных машин или контейнеров,
-а также кластерную файловую систему, то:
-
- [Следуйте инструкциям](../usage/nfs.ru.md#vitastorfs)
--- a/docs/performance/bench2.en.md
+++ b/docs/performance/bench2.en.md
@ -1,154 +0,0 @@
-[Documentation](../../README.md#documentation) → Performance → Newer benchmark of Vitastor 1.3.1
-
-----
-
-[Читать на русском](bench2.ru.md)
-
-# Newer benchmark of Vitastor 1.3.1
-
- [Test environment](#test-environment)
- [Notes](#notes)
- [Raw drive performance](#raw-drive-performance)
- [2 replicas](#2-replicas)
- [3 replicas](#3-replicas)
- [EC 2+1](#ec-2-1)
-
-## Test environment
-
-Hardware configuration: 3 nodes, each with:
- 8x NVMe Samsung PM9A3 1.92 TB
- 2x Xeon Gold 6342 (24 cores @ 2.8 GHz)
- 256 GB RAM
- Dual-port 25 GbE Mellanox ConnectX-4 LX network card with RoCEv2
- Connected to 2 Mellanox SN2010 switches with MLAG
-
-## Notes
-
-Vitastor version was 1.3.1.
-
-Tests were ran from the storage nodes - 4 fio clients per each of 3 nodes.
-
-The same large 3 TB image was tested from all hosts because Vitastor has no
-performance penalties related to running multiple clients over a single inode.
-
-CPU power saving was disabled. 4 OSDs were created per each NVMe.
-Checksums were not enabled. Tests with checksums will be conducted later,
-along with the newer version of Vitastor, and results will be updated.
-
-CPU configuration was not optimal because of NUMA. It's better to avoid 2-socket
-platforms. It was especially noticeable in RDMA tests - in the form of ksoftirqd
-processes (usually 1 per server) eating 100 % of one CPU core and actual bandwidth
-of one network port reduced to 3-5 Gbit/s instead of 25 Gbit/s - probably because
-of RFS (Receive Flow Steering) misses. Many network configurations were tried during
-tests, but nothing helped to solve this problem, so final tests were conducted with
-the default settings.
-
-# Raw drive performance
-
- Linear write ~1000-2000 MB/s, depending on current state of the drive's garbage collector
- Linear read ~3300 MB/s
- T1Q1 random write ~60000 iops (latency ~0.015ms)
- T1Q1 random read ~14700 iops (latency ~0.066ms)
- T1Q16 random write ~180000 iops
- T1Q16 random read ~120000 iops
- T1Q32 random write ~180000 iops
- T1Q32 random read ~195000 iops
- T1Q128 random write ~180000 iops
- T1Q128 random read ~195000 iops
- T4Q128 random write ~525000 iops
- T4Q128 random read ~750000 iops
-
-These numbers make obvious that results could be much better if a faster network
-was available, because NVMe drives obviously weren't a bottleneck. For example,
-theoretical maximum linear read performance for 24 drives could be 79.2 GByte/s,
-which is 633 Gbit/s. Real Vitastor read speed (both linear and random) was around
-16 Gbyte/s, which is 130 Gbit/s. It's important to note that it was still much
-larger than the network bandwidth of one server (50 Gbit/s). This is also correct
-because tests were conducted from all 3 nodes.
-
-## 2 replicas
-
-|                              | TCP          | RDMA         |
-|------------------------------|--------------|--------------|
-| Linear read (4M T6 Q16)      | 13.13 GB/s   | 16.25 GB/s   |
-| Linear write (4M T6 Q16)     | 8.16 GB/s    | 7.88 GB/s    |
-| Read 4k T1 Q1                | 8745 iops    | 10252 iops   |
-| Write 4k T1 Q1               | 8097 iops    | 11488 iops   |
-| Read 4k T12 Q128             | 1305936 iops | 4265861 iops |
-| Write 4k T12 Q128            | 660490 iops  | 1384033 iops |
-
-CPU consumption OSD per 1 disk:
-
-|                              | TCP     | RDMA    |
-|------------------------------|---------|---------|
-| Linear read (4M T6 Q16)      | 29.7 %  | 29.8 %  |
-| Linear write (4M T6 Q16)     | 84.4 %  | 33.2 %  |
-| Read 4k T12 Q128             | 98.4 %  | 119.1 % |
-| Write 4k T12 Q128            | 173.4 % | 175.9 % |
-
-CPU consumption per 1 client (fio):
-
-|                              | TCP    | RDMA   |
-|------------------------------|--------|--------|
-| Linear read (4M T6 Q16)      | 100 %  | 85.2 % |
-| Linear write (4M T6 Q16)     | 55.8 % | 48.8 % |
-| Read 4k T12 Q128             | 99.9 % | 96 %   |
-| Write 4k T12 Q128            | 71.6 % | 48.5 % |
-
-## 3 replicas
-
-|                              | TCP          | RDMA         |
-|------------------------------|--------------|--------------|
-| Linear read (4M T6 Q16)      | 13.98 GB/s   | 16.54 GB/s   |
-| Linear write (4M T6 Q16)     | 5.38 GB/s    | 5.7 GB/s     |
-| Read 4k T1 Q1                | 8969 iops    | 9980 iops    |
-| Write 4k T1 Q1               | 8126 iops    | 11672 iops   |
-| Read 4k T12 Q128             | 1358818 iops | 4279088 iops |
-| Write 4k T12 Q128            | 433890 iops  | 993506 iops  |
-
-CPU consumption OSD per 1 disk:
-
-|                              | TCP    | RDMA    |
-|------------------------------|--------|---------|
-| Linear read (4M T6 Q16)      | 24.9 % | 25.4 %  |
-| Linear write (4M T6 Q16)     | 99.3 % | 38.4 %  |
-| Read 4k T12 Q128             | 95.3 % | 111.7 % |
-| Write 4k T12 Q128            | 173 %  | 194 %   |
-
-CPU consumption per 1 client (fio):
-
-|                              | TCP    | RDMA   |
-|------------------------------|--------|--------|
-| Linear read (4M T6 Q16)      | 99.9 % | 85.8 % |
-| Linear write (4M T6 Q16)     | 38.9 % | 38.1 % |
-| Read 4k T12 Q128             | 100 %  | 96.1 % |
-| Write 4k T12 Q128            | 51.6 % | 41.9 % |
-
-## EC 2+1
-
-|                              | TCP          | RDMA         |
-|------------------------------|--------------|--------------|
-| Linear read (4M T6 Q16)      | 10.07 GB/s   | 11.43 GB/s   |
-| Linear write (4M T6 Q16)     | 7.74 GB/s    | 8.32 GB/s    |
-| Read 4k T1 Q1                | 7408 iops    | 8891 iops    |
-| Write 4k T1 Q1               | 3525 iops    | 4903 iops    |
-| Read 4k T12 Q128             | 1216496 iops | 2552765 iops |
-| Write 4k T12 Q128            | 278110 iops  | 821261 iops  |
-
-CPU consumption OSD per 1 disk:
-
-|                              | TCP     | RDMA    |
-|------------------------------|---------|---------|
-| Linear read (4M T6 Q16)      | 68.6 %  | 33.6 %  |
-| Linear write (4M T6 Q16)     | 108.3 % | 50.2 %  |
-| Read 4k T12 Q128             | 138.1 % | 97.9 %  |
-| Write 4k T12 Q128            | 168.7 % | 188.5 % |
-
-CPU consumption per 1 client (fio):
-
-|                              | TCP    | RDMA   |
-|------------------------------|--------|--------|
-| Linear read (4M T6 Q16)      | 88.2 % | 52.4 % |
-| Linear write (4M T6 Q16)     | 51.8 % | 46.8 % |
-| Read 4k T12 Q128             | 99.7 % | 61.3 % |
-| Write 4k T12 Q128            | 35.1 % | 31.3 % |
--- a/Show More
+++ b/Show More