WIP Support "prefetch" in kv_db

This greatly speeds up PG placement and makes it more uniform both because the LP task
becomes simpler and because the distribution of individual OSDs is optimised manually

.gitea/workflows/buildenv.Dockerfile

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

.gitea/workflows/test.Dockerfile

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

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

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

.gitignore

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

CLA-en.md

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

CLA-ru.md

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

CMakeLists.txt

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

README-ru.md

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

README.md

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

VNPL-1.1-RU.txt

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

VNPL-1.1.txt

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

copy-fio-includes.sh

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

copy-qemu-includes.sh

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

csi/.dockerignore

@@ -1,3 +1,2 @@
 vitastor-csi
-go.sum
 Dockerfile

csi/Dockerfile

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

csi/Makefile

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

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

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

csi/deploy/004-csi-nodeplugin.yaml

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

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

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

csi/deploy/007-csi-provisioner.yaml

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

csi/deploy/009-storage-class.yaml

@@ -9,11 +9,17 @@ metadata:
 provisioner: csi.vitastor.io
 volumeBindingMode: Immediate
 parameters:
-  etcdVolumePrefix: ""
-  poolId: "1"
+  # CSI driver can create block-based volumes and VitastorFS-based volumes
+  # only VitastorFS-based volumes and raw block volumes (without FS) support ReadWriteMany mode
+  # set this parameter to VitastorFS metadata volume name to use VitastorFS
+  # if unset, block-based volumes will be created
+  vitastorfs: ""
+  # for block-based storage classes, pool ID may be either a string (name) or a number (ID)
+  # for vitastorFS-based storage classes it must be a string - name of the default pool for FS data
+  poolId: "testpool"
+  # volume name prefix for block-based storage classes or NFS subdirectory (including /) for FS-based volumes
+  volumePrefix: ""
   # 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"
-  # 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"
+allowVolumeExpansion: true

csi/deploy/example-pvc-block.yaml

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

csi/deploy/example-snapshot-class.yaml

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

csi/deploy/example-snapshot-clone.yaml

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

csi/deploy/example-snapshot.yaml

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

csi/deploy/example-storage-class-fs.yaml

@@ -0,0 +1,25 @@
+---
+apiVersion: storage.k8s.io/v1
+kind: StorageClass
+metadata:
+  namespace: vitastor-system
+  name: vitastor
+  annotations:
+    storageclass.kubernetes.io/is-default-class: "true"
+provisioner: csi.vitastor.io
+volumeBindingMode: Immediate
+parameters:
+  # CSI driver can create block-based volumes and VitastorFS-based volumes
+  # only VitastorFS-based volumes and raw block volumes (without FS) support ReadWriteMany mode
+  # set this parameter to VitastorFS metadata volume name to use VitastorFS
+  # if unset, block-based volumes will be created
+  vitastorfs: "testfs"
+  # for block-based storage classes, pool ID may be either a string (name) or a number (ID)
+  # for vitastorFS-based storage classes it must be a string - name of the default pool for FS data
+  poolId: "testpool"
+  # volume name prefix for block-based storage classes or NFS subdirectory (including /) for FS-based volumes
+  volumePrefix: "k8s/"
+  # 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

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

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

csi/deploy/example-test-pod.yaml

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

csi/go.mod

@@ -3,27 +3,13 @@ module vitastor.io/csi
 go 1.15
 
 require (
-	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/container-storage-interface/spec v1.8.0
 	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
-	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
+	golang.org/x/net v0.7.0
+	golang.org/x/xerrors v0.0.0-20200804184101-5ec99f83aff1 // indirect
 	google.golang.org/grpc v1.33.1
+	google.golang.org/protobuf v1.24.0
 	k8s.io/klog v1.0.0
 	k8s.io/utils v0.0.0-20210305010621-2afb4311ab10
 )

csi/go.sum

@@ -0,0 +1,383 @@
+cloud.google.com/go v0.34.0/go.mod h1:aQUYkXzVsufM+DwF1aE+0xfcU+56JwCaLick0ClmMTw=
+cloud.google.com/go v0.38.0/go.mod h1:990N+gfupTy94rShfmMCWGDn0LpTmnzTp2qbd1dvSRU=
+cloud.google.com/go v0.44.1/go.mod h1:iSa0KzasP4Uvy3f1mN/7PiObzGgflwredwwASm/v6AU=
+cloud.google.com/go v0.44.2/go.mod h1:60680Gw3Yr4ikxnPRS/oxxkBccT6SA1yMk63TGekxKY=
+cloud.google.com/go v0.45.1/go.mod h1:RpBamKRgapWJb87xiFSdk4g1CME7QZg3uwTez+TSTjc=
+cloud.google.com/go v0.46.3/go.mod h1:a6bKKbmY7er1mI7TEI4lsAkts/mkhTSZK8w33B4RAg0=
+cloud.google.com/go v0.51.0/go.mod h1:hWtGJ6gnXH+KgDv+V0zFGDvpi07n3z8ZNj3T1RW0Gcw=
+cloud.google.com/go/bigquery v1.0.1/go.mod h1:i/xbL2UlR5RvWAURpBYZTtm/cXjCha9lbfbpx4poX+o=
+cloud.google.com/go/datastore v1.0.0/go.mod h1:LXYbyblFSglQ5pkeyhO+Qmw7ukd3C+pD7TKLgZqpHYE=
+cloud.google.com/go/pubsub v1.0.1/go.mod h1:R0Gpsv3s54REJCy4fxDixWD93lHJMoZTyQ2kNxGRt3I=
+cloud.google.com/go/storage v1.0.0/go.mod h1:IhtSnM/ZTZV8YYJWCY8RULGVqBDmpoyjwiyrjsg+URw=
+dmitri.shuralyov.com/gpu/mtl v0.0.0-20190408044501-666a987793e9/go.mod h1:H6x//7gZCb22OMCxBHrMx7a5I7Hp++hsVxbQ4BYO7hU=
+github.com/Azure/go-ansiterm v0.0.0-20170929234023-d6e3b3328b78/go.mod h1:LmzpDX56iTiv29bbRTIsUNlaFfuhWRQBWjQdVyAevI8=
+github.com/Azure/go-autorest/autorest v0.9.0/go.mod h1:xyHB1BMZT0cuDHU7I0+g046+BFDTQ8rEZB0s4Yfa6bI=
+github.com/Azure/go-autorest/autorest v0.9.6/go.mod h1:/FALq9T/kS7b5J5qsQ+RSTUdAmGFqi0vUdVNNx8q630=
+github.com/Azure/go-autorest/autorest/adal v0.5.0/go.mod h1:8Z9fGy2MpX0PvDjB1pEgQTmVqjGhiHBW7RJJEciWzS0=
+github.com/Azure/go-autorest/autorest/adal v0.8.2/go.mod h1:ZjhuQClTqx435SRJ2iMlOxPYt3d2C/T/7TiQCVZSn3Q=
+github.com/Azure/go-autorest/autorest/date v0.1.0/go.mod h1:plvfp3oPSKwf2DNjlBjWF/7vwR+cUD/ELuzDCXwHUVA=
+github.com/Azure/go-autorest/autorest/date v0.2.0/go.mod h1:vcORJHLJEh643/Ioh9+vPmf1Ij9AEBM5FuBIXLmIy0g=
+github.com/Azure/go-autorest/autorest/mocks v0.1.0/go.mod h1:OTyCOPRA2IgIlWxVYxBee2F5Gr4kF2zd2J5cFRaIDN0=
+github.com/Azure/go-autorest/autorest/mocks v0.2.0/go.mod h1:OTyCOPRA2IgIlWxVYxBee2F5Gr4kF2zd2J5cFRaIDN0=
+github.com/Azure/go-autorest/autorest/mocks v0.3.0/go.mod h1:a8FDP3DYzQ4RYfVAxAN3SVSiiO77gL2j2ronKKP0syM=
+github.com/Azure/go-autorest/logger v0.1.0/go.mod h1:oExouG+K6PryycPJfVSxi/koC6LSNgds39diKLz7Vrc=
+github.com/Azure/go-autorest/tracing v0.5.0/go.mod h1:r/s2XiOKccPW3HrqB+W0TQzfbtp2fGCgRFtBroKn4Dk=
+github.com/BurntSushi/toml v0.3.1/go.mod h1:xHWCNGjB5oqiDr8zfno3MHue2Ht5sIBksp03qcyfWMU=
+github.com/BurntSushi/xgb v0.0.0-20160522181843-27f122750802/go.mod h1:IVnqGOEym/WlBOVXweHU+Q+/VP0lqqI8lqeDx9IjBqo=
+github.com/NYTimes/gziphandler v0.0.0-20170623195520-56545f4a5d46/go.mod h1:3wb06e3pkSAbeQ52E9H9iFoQsEEwGN64994WTCIhntQ=
+github.com/PuerkitoBio/purell v1.0.0/go.mod h1:c11w/QuzBsJSee3cPx9rAFu61PvFxuPbtSwDGJws/X0=
+github.com/PuerkitoBio/urlesc v0.0.0-20160726150825-5bd2802263f2/go.mod h1:uGdkoq3SwY9Y+13GIhn11/XLaGBb4BfwItxLd5jeuXE=
+github.com/alecthomas/template v0.0.0-20160405071501-a0175ee3bccc/go.mod h1:LOuyumcjzFXgccqObfd/Ljyb9UuFJ6TxHnclSeseNhc=
+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/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/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/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/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/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/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=
+github.com/envoyproxy/protoc-gen-validate v0.1.0/go.mod h1:iSmxcyjqTsJpI2R4NaDN7+kN2VEUnK/pcBlmesArF7c=
+github.com/evanphx/json-patch v4.9.0+incompatible/go.mod h1:50XU6AFN0ol/bzJsmQLiYLvXMP4fmwYFNcr97nuDLSk=
+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/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=
+github.com/go-logfmt/logfmt v0.3.0/go.mod h1:Qt1PoO58o5twSAckw1HlFXLmHsOX5/0LbT9GBnD5lWE=
+github.com/go-logfmt/logfmt v0.4.0/go.mod h1:3RMwSq7FuexP4Kalkev3ejPJsZTpXXBr9+V4qmtdjCk=
+github.com/go-logr/logr v0.1.0/go.mod h1:ixOQHD9gLJUVQQ2ZOR7zLEifBX6tGkNJF4QyIY7sIas=
+github.com/go-logr/logr v0.2.0 h1:QvGt2nLcHH0WK9orKa+ppBPAxREcH364nPUedEpK0TY=
+github.com/go-logr/logr v0.2.0/go.mod h1:z6/tIYblkpsD+a4lm/fGIIU9mZ+XfAiaFtq7xTgseGU=
+github.com/go-openapi/jsonpointer v0.0.0-20160704185906-46af16f9f7b1/go.mod h1:+35s3my2LFTysnkMfxsJBAMHj/DoqoB9knIWoYG/Vk0=
+github.com/go-openapi/jsonreference v0.0.0-20160704190145-13c6e3589ad9/go.mod h1:W3Z9FmVs9qj+KR4zFKmDPGiLdk1D9Rlm7cyMvf57TTg=
+github.com/go-openapi/spec v0.0.0-20160808142527-6aced65f8501/go.mod h1:J8+jY1nAiCcj+friV/PDoE1/3eeccG9LYBs0tYvLOWc=
+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/go.mod h1:SlYgWuQ5SjCEi6WLHjHCa1yvBfUnHcTbrrZtXPKa29o=
+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/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=
+github.com/golang/mock v1.3.1/go.mod h1:sBzyDLLjw3U8JLTeZvSv8jJB+tU5PVekmnlKIyFUx0Y=
+github.com/golang/protobuf v1.2.0/go.mod h1:6lQm79b+lXiMfvg/cZm0SGofjICqVBUtrP5yJMmIC1U=
+github.com/golang/protobuf v1.3.1/go.mod h1:6lQm79b+lXiMfvg/cZm0SGofjICqVBUtrP5yJMmIC1U=
+github.com/golang/protobuf v1.3.2/go.mod h1:6lQm79b+lXiMfvg/cZm0SGofjICqVBUtrP5yJMmIC1U=
+github.com/golang/protobuf v1.3.3/go.mod h1:vzj43D7+SQXF/4pzW/hwtAqwc6iTitCiVSaWz5lYuqw=
+github.com/golang/protobuf v1.4.0-rc.1/go.mod h1:ceaxUfeHdC40wWswd/P6IGgMaK3YpKi5j83Wpe3EHw8=
+github.com/golang/protobuf v1.4.0-rc.1.0.20200221234624-67d41d38c208/go.mod h1:xKAWHe0F5eneWXFV3EuXVDTCmh+JuBKY0li0aMyXATA=
+github.com/golang/protobuf v1.4.0-rc.2/go.mod h1:LlEzMj4AhA7rCAGe4KMBDvJI+AwstrUpVNzEA03Pprs=
+github.com/golang/protobuf v1.4.0-rc.4.0.20200313231945-b860323f09d0/go.mod h1:WU3c8KckQ9AFe+yFwt9sWVRKCVIyN9cPHBJSNnbL67w=
+github.com/golang/protobuf v1.4.0/go.mod h1:jodUvKwWbYaEsadDk5Fwe5c77LiNKVO9IDvqG2KuDX0=
+github.com/golang/protobuf v1.4.1/go.mod h1:U8fpvMrcmy5pZrNK1lt4xCsGvpyWQ/VVv6QDs8UjoX8=
+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/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=
+github.com/google/go-cmp v0.3.1/go.mod h1:8QqcDgzrUqlUb/G2PQTWiueGozuR1884gddMywk6iLU=
+github.com/google/go-cmp v0.4.0 h1:xsAVV57WRhGj6kEIi8ReJzQlHHqcBYCElAvkovg3B/4=
+github.com/google/go-cmp v0.4.0/go.mod h1:v8dTdLbMG2kIc/vJvl+f65V22dbkXbowE6jgT/gNBxE=
+github.com/google/gofuzz v1.0.0/go.mod h1:dBl0BpW6vV/+mYPU4Po3pmUjxk6FQPldtuIdl/M65Eg=
+github.com/google/gofuzz v1.1.0/go.mod h1:dBl0BpW6vV/+mYPU4Po3pmUjxk6FQPldtuIdl/M65Eg=
+github.com/google/martian v2.1.0+incompatible/go.mod h1:9I4somxYTbIHy5NJKHRl3wXiIaQGbYVAs8BPL6v8lEs=
+github.com/google/pprof v0.0.0-20181206194817-3ea8567a2e57/go.mod h1:zfwlbNMJ+OItoe0UupaVj+oy1omPYYDuagoSzA8v9mc=
+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/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/gregjones/httpcache v0.0.0-20180305231024-9cad4c3443a7/go.mod h1:FecbI9+v66THATjSRHfNgh1IVFe/9kFxbXtjV0ctIMA=
+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/json-iterator/go v1.1.6/go.mod h1:+SdeFBvtyEkXs7REEP0seUULqWtbJapLOCVDaaPEHmU=
+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/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/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=
+github.com/kr/pretty v0.2.0 h1:s5hAObm+yFO5uHYt5dYjxi2rXrsnmRpJx4OYvIWUaQs=
+github.com/kr/pretty v0.2.0/go.mod h1:ipq/a2n7PKx3OHsz4KJII5eveXtPO4qwEXGdVfWzfnI=
+github.com/kr/pty v1.1.1/go.mod h1:pFQYn66WHrOpPYNljwOMqo10TkYh1fy3cYio2l3bCsQ=
+github.com/kr/text v0.1.0 h1:45sCR5RtlFHMR4UwH9sdQ5TC8v0qDQCHnXt+kaKSTVE=
+github.com/kr/text v0.1.0/go.mod h1:4Jbv+DJW3UT/LiOwJeYQe1efqtUx/iVham/4vfdArNI=
+github.com/kubernetes-csi/csi-lib-utils v0.9.1 h1:sGq6ifVujfMSkfTsMZip44Ttv8SDXvsBlFk9GdYl/b8=
+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/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/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/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=
+github.com/mxk/go-flowrate v0.0.0-20140419014527-cca7078d478f/go.mod h1:ZdcZmHo+o7JKHSa8/e818NopupXU1YMK5fe1lsApnBw=
+github.com/onsi/ginkgo v0.0.0-20170829012221-11459a886d9c/go.mod h1:lLunBs/Ym6LB5Z9jYTR76FiuTmxDTDusOGeTQH+WWjE=
+github.com/onsi/ginkgo v1.6.0/go.mod h1:lLunBs/Ym6LB5Z9jYTR76FiuTmxDTDusOGeTQH+WWjE=
+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/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/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/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/go.mod h1:xMI15A0UPsDsEKsMN9yxemIoYk6Tm2C1GtYGdfGttqA=
+github.com/prometheus/common v0.4.1/go.mod h1:TNfzLD0ON7rHzMJeJkieUDPYmFC7Snx/y86RQel1bk4=
+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/go.mod h1:lV6e/gmhEcM9IjHGsFOCxxuZ+z1YqCvr4OA4YeYWdaU=
+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/go.mod h1:7uNnSEd1DgxDLC74fIahvMZmmYsHGZGEOFrfsX/uA88=
+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=
+github.com/spf13/pflag v1.0.5/go.mod h1:McXfInJRrz4CZXVZOBLb0bTZqETkiAhM9Iw0y3An2Bg=
+github.com/stretchr/objx v0.1.0/go.mod h1:HFkY916IF+rwdDfMAkV7OtwuqBVzrE8GR6GFx+wExME=
+github.com/stretchr/objx v0.1.1/go.mod h1:HFkY916IF+rwdDfMAkV7OtwuqBVzrE8GR6GFx+wExME=
+github.com/stretchr/testify v1.2.2/go.mod h1:a8OnRcib4nhh0OaRAV+Yts87kKdq0PP7pXfy6kDkUVs=
+github.com/stretchr/testify v1.3.0/go.mod h1:M5WIy9Dh21IEIfnGCwXGc5bZfKNJtfHm1UVUgZn+9EI=
+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=
+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/go.mod h1:gD2HeocX3+yG+ygLZcrzQJaqmWj9AIm7n08wl/qW/PE=
+go.uber.org/multierr v1.1.0/go.mod h1:wR5kodmAFQ0UK8QlbwjlSNy0Z68gJhDJUG5sjR94q/0=
+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=
+golang.org/x/crypto v0.0.0-20190510104115-cbcb75029529/go.mod h1:yigFU9vqHzYiE8UmvKecakEJjdnWj3jj499lnFckfCI=
+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/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=
+golang.org/x/exp v0.0.0-20190829153037-c13cbed26979/go.mod h1:86+5VVa7VpoJ4kLfm080zCjGlMRFzhUhsZKEZO7MGek=
+golang.org/x/exp v0.0.0-20191227195350-da58074b4299/go.mod h1:2RIsYlXP63K8oxa1u096TMicItID8zy7Y6sNkU49FU4=
+golang.org/x/image v0.0.0-20190227222117-0694c2d4d067/go.mod h1:kZ7UVZpmo3dzQBMxlp+ypCbDeSB+sBbTgSJuh5dn5js=
+golang.org/x/image v0.0.0-20190802002840-cff245a6509b/go.mod h1:FeLwcggjj3mMvU+oOTbSwawSJRM1uh48EjtB4UJZlP0=
+golang.org/x/lint v0.0.0-20190227174305-5b3e6a55c961/go.mod h1:wehouNa3lNwaWXcvxsM5YxQ5yQlVC4a0KAMCusXpPoU=
+golang.org/x/lint v0.0.0-20190301231843-5614ed5bae6f/go.mod h1:UVdnD1Gm6xHRNCYTkRU2/jEulfH38KcIWyp/GAMgvoE=
+golang.org/x/lint v0.0.0-20190313153728-d0100b6bd8b3/go.mod h1:6SW0HCj/g11FgYtHlgUYUwCkIfeOF89ocIRzGO/8vkc=
+golang.org/x/lint v0.0.0-20190409202823-959b441ac422/go.mod h1:6SW0HCj/g11FgYtHlgUYUwCkIfeOF89ocIRzGO/8vkc=
+golang.org/x/lint v0.0.0-20190909230951-414d861bb4ac/go.mod h1:6SW0HCj/g11FgYtHlgUYUwCkIfeOF89ocIRzGO/8vkc=
+golang.org/x/lint v0.0.0-20191125180803-fdd1cda4f05f/go.mod h1:5qLYkcX4OjUUV8bRuDixDT3tpyyb+LUpUlRWLxfhWrs=
+golang.org/x/mobile v0.0.0-20190312151609-d3739f865fa6/go.mod h1:z+o9i4GpDbdi3rU15maQ/Ox0txvL9dWGYEHz965HBQE=
+golang.org/x/mobile v0.0.0-20190719004257-d2bd2a29d028/go.mod h1:E/iHnbuqvinMTCcRqshq8CkpyQDoeVncDDYHnLhea+o=
+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/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=
+golang.org/x/net v0.0.0-20190108225652-1e06a53dbb7e/go.mod h1:mL1N/T3taQHkDXs73rZJwtUhF3w3ftmwwsq0BUmARs4=
+golang.org/x/net v0.0.0-20190213061140-3a22650c66bd/go.mod h1:mL1N/T3taQHkDXs73rZJwtUhF3w3ftmwwsq0BUmARs4=
+golang.org/x/net v0.0.0-20190311183353-d8887717615a/go.mod h1:t9HGtf8HONx5eT2rtn7q6eTqICYqUVnKs3thJo3Qplg=
+golang.org/x/net v0.0.0-20190404232315-eb5bcb51f2a3/go.mod h1:t9HGtf8HONx5eT2rtn7q6eTqICYqUVnKs3thJo3Qplg=
+golang.org/x/net v0.0.0-20190501004415-9ce7a6920f09/go.mod h1:t9HGtf8HONx5eT2rtn7q6eTqICYqUVnKs3thJo3Qplg=
+golang.org/x/net v0.0.0-20190503192946-f4e77d36d62c/go.mod h1:t9HGtf8HONx5eT2rtn7q6eTqICYqUVnKs3thJo3Qplg=
+golang.org/x/net v0.0.0-20190603091049-60506f45cf65/go.mod h1:HSz+uSET+XFnRR8LxR5pz3Of3rY3CfYBVs4xY44aLks=
+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-20200324143707-d3edc9973b7e/go.mod h1:qpuaurCH72eLCgpAm/N6yyVIVM9cpaDIP3A8BGJEC5A=
+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/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/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/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=
+golang.org/x/sys v0.0.0-20190215142949-d0b11bdaac8a/go.mod h1:STP8DvDyc/dI5b8T5hshtkjS+E42TnysNCUPdjciGhY=
+golang.org/x/sys v0.0.0-20190312061237-fead79001313/go.mod h1:h1NjWce9XRLGQEsW7wpKNCjG9DtNlClVuFLEZdDNbEs=
+golang.org/x/sys v0.0.0-20190412213103-97732733099d/go.mod h1:h1NjWce9XRLGQEsW7wpKNCjG9DtNlClVuFLEZdDNbEs=
+golang.org/x/sys v0.0.0-20190422165155-953cdadca894/go.mod h1:h1NjWce9XRLGQEsW7wpKNCjG9DtNlClVuFLEZdDNbEs=
+golang.org/x/sys v0.0.0-20190502145724-3ef323f4f1fd/go.mod h1:h1NjWce9XRLGQEsW7wpKNCjG9DtNlClVuFLEZdDNbEs=
+golang.org/x/sys v0.0.0-20190507160741-ecd444e8653b/go.mod h1:h1NjWce9XRLGQEsW7wpKNCjG9DtNlClVuFLEZdDNbEs=
+golang.org/x/sys v0.0.0-20190606165138-5da285871e9c/go.mod h1:h1NjWce9XRLGQEsW7wpKNCjG9DtNlClVuFLEZdDNbEs=
+golang.org/x/sys v0.0.0-20190624142023-c5567b49c5d0/go.mod h1:h1NjWce9XRLGQEsW7wpKNCjG9DtNlClVuFLEZdDNbEs=
+golang.org/x/sys v0.0.0-20191005200804-aed5e4c7ecf9/go.mod h1:h1NjWce9XRLGQEsW7wpKNCjG9DtNlClVuFLEZdDNbEs=
+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-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/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/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/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/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=
+golang.org/x/tools v0.0.0-20181030221726-6c7e314b6563/go.mod h1:n7NCudcB/nEzxVGmLbDWY5pfWTLqBcC2KZ6jyYvM4mQ=
+golang.org/x/tools v0.0.0-20190226205152-f727befe758c/go.mod h1:9Yl7xja0Znq3iFh3HoIrodX9oNMXvdceNzlUR8zjMvY=
+golang.org/x/tools v0.0.0-20190311212946-11955173bddd/go.mod h1:LCzVGOaR6xXOjkQ3onu1FJEFr0SW1gC7cKk1uF8kGRs=
+golang.org/x/tools v0.0.0-20190312151545-0bb0c0a6e846/go.mod h1:LCzVGOaR6xXOjkQ3onu1FJEFr0SW1gC7cKk1uF8kGRs=
+golang.org/x/tools v0.0.0-20190312170243-e65039ee4138/go.mod h1:LCzVGOaR6xXOjkQ3onu1FJEFr0SW1gC7cKk1uF8kGRs=
+golang.org/x/tools v0.0.0-20190425150028-36563e24a262/go.mod h1:RgjU9mgBXZiqYHBnxXauZ1Gv1EHHAz9KjViQ78xBX0Q=
+golang.org/x/tools v0.0.0-20190506145303-2d16b83fe98c/go.mod h1:RgjU9mgBXZiqYHBnxXauZ1Gv1EHHAz9KjViQ78xBX0Q=
+golang.org/x/tools v0.0.0-20190524140312-2c0ae7006135/go.mod h1:RgjU9mgBXZiqYHBnxXauZ1Gv1EHHAz9KjViQ78xBX0Q=
+golang.org/x/tools v0.0.0-20190606124116-d0a3d012864b/go.mod h1:/rFqwRUd4F7ZHNgwSSTFct+R/Kf4OFW1sUzUTQQTgfc=
+golang.org/x/tools v0.0.0-20190621195816-6e04913cbbac/go.mod h1:/rFqwRUd4F7ZHNgwSSTFct+R/Kf4OFW1sUzUTQQTgfc=
+golang.org/x/tools v0.0.0-20190624222133-a101b041ded4/go.mod h1:/rFqwRUd4F7ZHNgwSSTFct+R/Kf4OFW1sUzUTQQTgfc=
+golang.org/x/tools v0.0.0-20190628153133-6cdbf07be9d0/go.mod h1:/rFqwRUd4F7ZHNgwSSTFct+R/Kf4OFW1sUzUTQQTgfc=
+golang.org/x/tools v0.0.0-20190816200558-6889da9d5479/go.mod h1:b+2E5dAYhXwXZwtnZ6UAqBI28+e2cm9otk0dWdXHAEo=
+golang.org/x/tools v0.0.0-20190911174233-4f2ddba30aff/go.mod h1:b+2E5dAYhXwXZwtnZ6UAqBI28+e2cm9otk0dWdXHAEo=
+golang.org/x/tools v0.0.0-20191012152004-8de300cfc20a/go.mod h1:b+2E5dAYhXwXZwtnZ6UAqBI28+e2cm9otk0dWdXHAEo=
+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/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/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=
+google.golang.org/api v0.4.0/go.mod h1:8k5glujaEP+g9n7WNsDg8QP6cUVNI86fCNMcbazEtwE=
+google.golang.org/api v0.7.0/go.mod h1:WtwebWUNSVBH/HAw79HIFXZNqEvBhG+Ra+ax0hx3E3M=
+google.golang.org/api v0.8.0/go.mod h1:o4eAsZoiT+ibD93RtjEohWalFOjRDx6CVaqeizhEnKg=
+google.golang.org/api v0.9.0/go.mod h1:o4eAsZoiT+ibD93RtjEohWalFOjRDx6CVaqeizhEnKg=
+google.golang.org/api v0.15.0/go.mod h1:iLdEw5Ide6rF15KTC1Kkl0iskquN2gFfn9o9XIsbkAI=
+google.golang.org/appengine v1.4.0/go.mod h1:xpcJRLb0r/rnEns0DIKYYv+WjYCduHsrkT7/EB5XEv4=
+google.golang.org/appengine v1.5.0/go.mod h1:xpcJRLb0r/rnEns0DIKYYv+WjYCduHsrkT7/EB5XEv4=
+google.golang.org/appengine v1.6.1/go.mod h1:i06prIuMbXzDqacNJfV5OdTW448YApPu5ww/cMBSeb0=
+google.golang.org/appengine v1.6.5/go.mod h1:8WjMMxjGQR8xUklV/ARdw2HLXBOI7O7uCIDZVag1xfc=
+google.golang.org/genproto v0.0.0-20190307195333-5fe7a883aa19/go.mod h1:VzzqZJRnGkLBvHegQrXjBqPurQTc5/KpmUdxsrq26oE=
+google.golang.org/genproto v0.0.0-20190418145605-e7d98fc518a7/go.mod h1:VzzqZJRnGkLBvHegQrXjBqPurQTc5/KpmUdxsrq26oE=
+google.golang.org/genproto v0.0.0-20190425155659-357c62f0e4bb/go.mod h1:VzzqZJRnGkLBvHegQrXjBqPurQTc5/KpmUdxsrq26oE=
+google.golang.org/genproto v0.0.0-20190502173448-54afdca5d873/go.mod h1:VzzqZJRnGkLBvHegQrXjBqPurQTc5/KpmUdxsrq26oE=
+google.golang.org/genproto v0.0.0-20190801165951-fa694d86fc64/go.mod h1:DMBHOl98Agz4BDEuKkezgsaosCRResVns1a3J2ZsMNc=
+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-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=
+google.golang.org/grpc v1.25.1/go.mod h1:c3i+UQWmh7LiEpx4sFZnkU36qjEYZ0imhYfXVyQciAY=
+google.golang.org/protobuf v0.0.0-20200109180630-ec00e32a8dfd/go.mod h1:DFci5gLYBciE7Vtevhsrf46CRTquxDuWsQurQQe4oz8=
+google.golang.org/protobuf v0.0.0-20200221191635-4d8936d0db64/go.mod h1:kwYJMbMJ01Woi6D6+Kah6886xMZcty6N08ah7+eCXa0=
+google.golang.org/protobuf v0.0.0-20200228230310-ab0ca4ff8a60/go.mod h1:cfTl7dwQJ+fmap5saPgwCLgHXTUD7jkjRqWcaiX5VyM=
+google.golang.org/protobuf v1.20.1-0.20200309200217-e05f789c0967/go.mod h1:A+miEFZTKqfCUM6K7xSMQL9OKL/b6hQv+e19PK+JZNE=
+google.golang.org/protobuf v1.21.0/go.mod h1:47Nbq4nVaFHyn7ilMalzfO3qCViNmqZ2kzikPIcrTAo=
+google.golang.org/protobuf v1.22.0/go.mod h1:EGpADcykh3NcUnDUJcl1+ZksZNG86OlYog2l/sGQquU=
+google.golang.org/protobuf v1.23.0/go.mod h1:EGpADcykh3NcUnDUJcl1+ZksZNG86OlYog2l/sGQquU=
+google.golang.org/protobuf v1.23.1-0.20200526195155-81db48ad09cc/go.mod h1:EGpADcykh3NcUnDUJcl1+ZksZNG86OlYog2l/sGQquU=
+google.golang.org/protobuf v1.24.0 h1:UhZDfRO8JRQru4/+LlLE0BRKGF8L+PICnvYZmx/fEGA=
+google.golang.org/protobuf v1.24.0/go.mod h1:r/3tXBNzIEhYS9I1OUVjXDlt8tc493IdKGjtUeSXeh4=
+gopkg.in/alecthomas/kingpin.v2 v2.2.6/go.mod h1:FMv+mEhP44yOT+4EoQTLFTRgOQ1FBLkstjWtayDeSgw=
+gopkg.in/check.v1 v0.0.0-20161208181325-20d25e280405/go.mod h1:Co6ibVJAznAaIkqp8huTwlJQCZ016jof/cbN4VW5Yz0=
+gopkg.in/check.v1 v1.0.0-20180628173108-788fd7840127/go.mod h1:Co6ibVJAznAaIkqp8huTwlJQCZ016jof/cbN4VW5Yz0=
+gopkg.in/check.v1 v1.0.0-20190902080502-41f04d3bba15 h1:YR8cESwS4TdDjEe65xsg0ogRM/Nc3DYOhEAlW+xobZo=
+gopkg.in/check.v1 v1.0.0-20190902080502-41f04d3bba15/go.mod h1:Co6ibVJAznAaIkqp8huTwlJQCZ016jof/cbN4VW5Yz0=
+gopkg.in/errgo.v2 v2.1.0/go.mod h1:hNsd1EY+bozCKY1Ytp96fpM3vjJbqLJn88ws8XvfDNI=
+gopkg.in/fsnotify.v1 v1.4.7/go.mod h1:Tz8NjZHkW78fSQdbUxIjBTcgA1z1m8ZHf0WmKUhAMys=
+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.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=
+gopkg.in/yaml.v2 v2.2.8/go.mod h1:hI93XBmqTisBFMUTm0b8Fm+jr3Dg1NNxqwp+5A1VGuI=
+gotest.tools v2.2.0+incompatible/go.mod h1:DsYFclhRJ6vuDpmuTbkuFWG+y2sxOXAzmJt81HFBacw=
+gotest.tools/v3 v3.0.2/go.mod h1:3SzNCllyD9/Y+b5r9JIKQ474KzkZyqLqEfYqMsX94Bk=
+honnef.co/go/tools v0.0.0-20190102054323-c2f93a96b099/go.mod h1:rf3lG4BRIbNafJWhAfAdb/ePZxsR/4RtNHQocxwk9r4=
+honnef.co/go/tools v0.0.0-20190106161140-3f1c8253044a/go.mod h1:rf3lG4BRIbNafJWhAfAdb/ePZxsR/4RtNHQocxwk9r4=
+honnef.co/go/tools v0.0.0-20190418001031-e561f6794a2a/go.mod h1:rf3lG4BRIbNafJWhAfAdb/ePZxsR/4RtNHQocxwk9r4=
+honnef.co/go/tools v0.0.0-20190523083050-ea95bdfd59fc/go.mod h1:rf3lG4BRIbNafJWhAfAdb/ePZxsR/4RtNHQocxwk9r4=
+honnef.co/go/tools v0.0.1-2019.2.3/go.mod h1:a3bituU0lyd329TUQxRnasdCoJDkEUEAqEt0JzvZhAg=
+k8s.io/api v0.19.0/go.mod h1:I1K45XlvTrDjmj5LoM5LuP/KYrhWbjUKT/SoPG0qTjw=
+k8s.io/apimachinery v0.19.0/go.mod h1:DnPGDnARWFvYa3pMHgSxtbZb7gpzzAZ1pTfaUNDVlmA=
+k8s.io/client-go v0.19.0/go.mod h1:H9E/VT95blcFQnlyShFgnFT9ZnJOAceiUHM3MlRC+mU=
+k8s.io/component-base v0.19.0/go.mod h1:dKsY8BxkA+9dZIAh2aWJLL/UdASFDNtGYTCItL4LM7Y=
+k8s.io/gengo v0.0.0-20200413195148-3a45101e95ac/go.mod h1:ezvh/TsK7cY6rbqRK0oQQ8IAqLxYwwyPxAX1Pzy0ii0=
+k8s.io/klog v1.0.0 h1:Pt+yjF5aB1xDSVbau4VsWe+dQNzA0qv1LlXdC2dF6Q8=
+k8s.io/klog v1.0.0/go.mod h1:4Bi6QPql/J/LkTDqv7R/cd3hPo4k2DG6Ptcz060Ez5I=
+k8s.io/klog/v2 v2.0.0/go.mod h1:PBfzABfn139FHAV07az/IF9Wp1bkk3vpT2XSJ76fSDE=
+k8s.io/klog/v2 v2.2.0 h1:XRvcwJozkgZ1UQJmfMGpvRthQHOvihEhYtDfAaxMz/A=
+k8s.io/klog/v2 v2.2.0/go.mod h1:Od+F08eJP+W3HUb4pSrPpgp9DGU4GzlpG/TmITuYh/Y=
+k8s.io/kube-openapi v0.0.0-20200805222855-6aeccd4b50c6/go.mod h1:UuqjUnNftUyPE5H64/qeyjQoUZhGpeFDVdxjTeEVN2o=
+k8s.io/utils v0.0.0-20200729134348-d5654de09c73/go.mod h1:jPW/WVKK9YHAvNhRxK0md/EJ228hCsBRufyofKtW8HA=
+k8s.io/utils v0.0.0-20210305010621-2afb4311ab10 h1:u5rPykqiCpL+LBfjRkXvnK71gOgIdmq3eHUEkPrbeTI=
+k8s.io/utils v0.0.0-20210305010621-2afb4311ab10/go.mod h1:jPW/WVKK9YHAvNhRxK0md/EJ228hCsBRufyofKtW8HA=
+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/go.mod h1:yfXDCHCao9+ENCvLSE62v9VSji2MKu5jeNfTrofGhJc=

csi/src/config.go

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

csi/src/controllerserver.go

@@ -6,13 +6,10 @@ package vitastor
 import (
     "context"
     "encoding/json"
-    "strings"
-    "bytes"
-    "strconv"
-    "time"
     "fmt"
+    "strings"
+    "time"
     "os"
-    "os/exec"
     "io/ioutil"
 
     "github.com/kubernetes-csi/csi-lib-utils/protosanitizer"
@@ -20,8 +17,7 @@ import (
 
     "google.golang.org/grpc/codes"
     "google.golang.org/grpc/status"
-
-    "go.etcd.io/etcd/clientv3"
+    "google.golang.org/protobuf/types/known/timestamppb"
 
     "github.com/container-storage-interface/spec/lib/go/csi"
 )
@@ -47,6 +43,7 @@ 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
@@ -62,7 +59,7 @@ func NewControllerServer(driver *Driver) *ControllerServer
     }
 }
 
-func GetConnectionParams(params map[string]string) (map[string]string, []string, string)
+func GetConnectionParams(params map[string]string) (map[string]string, error)
 {
     ctxVars := make(map[string]string)
     configPath := params["configPath"]
@@ -70,48 +67,59 @@ func GetConnectionParams(params map[string]string) (map[string]string, []string,
     {
         configPath = "/etc/vitastor/vitastor.conf"
     }
-    else
+    ctxVars["configPath"] = configPath
+    if (params["vitastorfs"] != "")
     {
-        ctxVars["configPath"] = configPath
+        ctxVars["vitastorfs"] = params["vitastorfs"]
     }
     config := make(map[string]interface{})
-    if configFD, err := os.Open(configPath); err == nil
+    configFD, err := os.Open(configPath)
+    if (err != nil)
     {
-        defer configFD.Close()
-        data, _ := ioutil.ReadAll(configFD)
-        json.Unmarshal(data, &config)
+        return nil, err
     }
-    // Try to load prefix & etcd URL from the config
+    defer configFD.Close()
+    data, _ := ioutil.ReadAll(configFD)
+    json.Unmarshal(data, &config)
+    // Check etcd URL in the config, but do not use the explicit etcdUrl
+    // parameter for CLI calls, otherwise users won't be able to later
+    // change them - storage class parameters are saved in volume IDs
     var etcdUrl []string
-    if (params["etcdUrl"] != "")
+    switch config["etcd_address"].(type)
     {
-        ctxVars["etcdUrl"] = params["etcdUrl"]
-        etcdUrl = strings.Split(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)
+            }
+        }
     }
     if (len(etcdUrl) == 0)
     {
-        switch config["etcd_address"].(type)
-        {
-        case string:
-            etcdUrl = strings.Split(config["etcd_address"].(string), ",")
-        case []string:
-            etcdUrl = config["etcd_address"].([]string)
-        }
+        return nil, status.Error(codes.InvalidArgument, "etcd_address is missing in "+configPath)
     }
-    etcdPrefix := params["etcdPrefix"]
-    if (etcdPrefix == "")
+    return ctxVars, nil
+}
+
+func invokeCLI(ctxVars map[string]string, args []string) ([]byte, error)
+{
+    if (ctxVars["configPath"] != "")
     {
-        etcdPrefix, _ = config["etcd_prefix"].(string)
-        if (etcdPrefix == "")
-        {
-            etcdPrefix = "/vitastor"
-        }
+        args = append(args, "--config_path", ctxVars["configPath"])
     }
-    else
-    {
-        ctxVars["etcdPrefix"] = etcdPrefix
-    }
-    return ctxVars, etcdUrl, etcdPrefix
+    stdout, _, err := system("/usr/bin/vitastor-cli", args...)
+    return stdout, err
 }
 
 // Create the volume
@@ -132,142 +140,101 @@ func (cs *ControllerServer) CreateVolume(ctx context.Context, req *csi.CreateVol
         return nil, status.Error(codes.InvalidArgument, "volume capabilities is a required field")
     }
 
-    etcdVolumePrefix := req.Parameters["etcdVolumePrefix"]
-    poolId, _ := strconv.ParseUint(req.Parameters["poolId"], 10, 64)
-    if (poolId == 0)
+    ctxVars, err := GetConnectionParams(req.Parameters)
+    if (err != nil)
+    {
+        return nil, err
+    }
+
+    err = cs.checkCaps(volumeCapabilities, ctxVars["vitastorfs"] != "")
+    if (err != nil)
+    {
+        return nil, err
+    }
+
+    pool := req.Parameters["poolId"]
+    if (pool == "")
     {
         return nil, status.Error(codes.InvalidArgument, "poolId is missing in storage class configuration")
     }
-
-    volName := etcdVolumePrefix + req.GetName()
+    volumePrefix := req.Parameters["volumePrefix"]
+    if (volumePrefix == "")
+    {
+        // Old name
+        volumePrefix = req.Parameters["etcdVolumePrefix"]
+    }
+    volName := volumePrefix + req.GetName()
     volSize := 1 * GB
     if capRange := req.GetCapacityRange(); capRange != nil
     {
         volSize = ((capRange.GetRequiredBytes() + MB - 1) / MB) * MB
     }
 
-    // FIXME: The following should PROBABLY be implemented externally in a management tool
-
-    ctxVars, etcdUrl, etcdPrefix := GetConnectionParams(req.Parameters)
-    if (len(etcdUrl) == 0)
+    if (ctxVars["vitastorfs"] != "")
     {
-        return nil, status.Error(codes.InvalidArgument, "no etcdUrl in storage class configuration and no etcd_address in vitastor.conf")
+        // Nothing to create, subdirectories are created during mounting
+        // FIXME: It would be cool to support quotas some day and set it here
+        if (req.VolumeContentSource.GetSnapshot() != nil)
+        {
+            return nil, status.Error(codes.InvalidArgument, "VitastorFS doesn't support snapshots")
+        }
+        ctxVars["name"] = volName
+        ctxVars["pool"] = pool
+        volumeIdJson, _ := json.Marshal(ctxVars)
+        return &csi.CreateVolumeResponse{
+            Volume: &csi.Volume{
+                // Ugly, but VolumeContext isn't passed to DeleteVolume :-(
+                VolumeId: string(volumeIdJson),
+                CapacityBytes: volSize,
+            },
+        }, nil
     }
 
-    // Connect to etcd
-    cli, err := clientv3.New(clientv3.Config{
-        DialTimeout: ETCD_TIMEOUT,
-        Endpoints: etcdUrl,
-    })
+    args := []string{ "create", volName, "-s", fmt.Sprintf("%v", volSize), "--pool", pool }
+
+    // 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,
+                    },
+                },
+            }
+        }
+    }
+
+    // Create image using vitastor-cli
+    _, err = invokeCLI(ctxVars, args)
     if (err != nil)
     {
-        return nil, status.Error(codes.Internal, "failed to connect to etcd at "+strings.Join(etcdUrl, ",")+": "+err.Error())
-    }
-    defer cli.Close()
-
-    var imageId uint64 = 0
-    for
-    {
-        // Check if the image exists
-        ctx, cancel := context.WithTimeout(context.Background(), ETCD_TIMEOUT)
-        resp, err := cli.Get(ctx, etcdPrefix+"/index/image/"+volName)
-        cancel()
-        if (err != nil)
+        if (strings.Index(err.Error(), "already exists") > 0)
         {
-            return nil, status.Error(codes.Internal, "failed to read key from etcd: "+err.Error())
-        }
-        if (len(resp.Kvs) > 0)
-        {
-            kv := resp.Kvs[0]
-            var v InodeIndex
-            err := json.Unmarshal(kv.Value, &v)
+            inodeCfg, err := invokeList(ctxVars, volName, true)
             if (err != nil)
             {
-                return nil, status.Error(codes.Internal, "invalid /index/image/"+volName+" key in etcd: "+err.Error())
+                return nil, err
             }
-            poolId = v.PoolId
-            imageId = v.Id
-            inodeCfgKey := fmt.Sprintf("/config/inode/%d/%d", poolId, imageId)
-            ctx, cancel := context.WithTimeout(context.Background(), ETCD_TIMEOUT)
-            resp, err := cli.Get(ctx, etcdPrefix+inodeCfgKey)
-            cancel()
-            if (err != nil)
-            {
-                return nil, status.Error(codes.Internal, "failed to read key from etcd: "+err.Error())
-            }
-            if (len(resp.Kvs) == 0)
-            {
-                return nil, status.Error(codes.Internal, "missing "+inodeCfgKey+" key in etcd")
-            }
-            var inodeCfg InodeConfig
-            err = json.Unmarshal(resp.Kvs[0].Value, &inodeCfg)
-            if (err != nil)
-            {
-                return nil, status.Error(codes.Internal, "invalid "+inodeCfgKey+" key in etcd: "+err.Error())
-            }
-            if (inodeCfg.Size < uint64(volSize))
+            if (inodeCfg[0].Size < uint64(volSize))
             {
                 return nil, status.Error(codes.Internal, "image "+volName+" is already created, but size is less than expected")
             }
         }
         else
         {
-            // Find a free ID
-            // Create image metadata in a transaction verifying that the image doesn't exist yet AND ID is still free
-            maxIdKey := fmt.Sprintf("%s/index/maxid/%d", etcdPrefix, poolId)
-            ctx, cancel := context.WithTimeout(context.Background(), ETCD_TIMEOUT)
-            resp, err := cli.Get(ctx, maxIdKey)
-            cancel()
-            if (err != nil)
-            {
-                return nil, status.Error(codes.Internal, "failed to read key from etcd: "+err.Error())
-            }
-            var modRev int64
-            var nextId uint64
-            if (len(resp.Kvs) > 0)
-            {
-                var err error
-                nextId, err = strconv.ParseUint(string(resp.Kvs[0].Value), 10, 64)
-                if (err != nil)
-                {
-                    return nil, status.Error(codes.Internal, maxIdKey+" contains invalid ID")
-                }
-                modRev = resp.Kvs[0].ModRevision
-                nextId++
-            }
-            else
-            {
-                nextId = 1
-            }
-            inodeIdxJson, _ := json.Marshal(InodeIndex{
-                Id: nextId,
-                PoolId: poolId,
-            })
-            inodeCfgJson, _ := json.Marshal(InodeConfig{
-                Name: volName,
-                Size: uint64(volSize),
-            })
-            ctx, cancel = context.WithTimeout(context.Background(), ETCD_TIMEOUT)
-            txnResp, err := cli.Txn(ctx).If(
-                clientv3.Compare(clientv3.ModRevision(fmt.Sprintf("%s/index/maxid/%d", etcdPrefix, poolId)), "=", modRev),
-                clientv3.Compare(clientv3.CreateRevision(fmt.Sprintf("%s/index/image/%s", etcdPrefix, volName)), "=", 0),
-                clientv3.Compare(clientv3.CreateRevision(fmt.Sprintf("%s/config/inode/%d/%d", etcdPrefix, poolId, nextId)), "=", 0),
-            ).Then(
-                clientv3.OpPut(fmt.Sprintf("%s/index/maxid/%d", etcdPrefix, poolId), fmt.Sprintf("%d", nextId)),
-                clientv3.OpPut(fmt.Sprintf("%s/index/image/%s", etcdPrefix, volName), string(inodeIdxJson)),
-                clientv3.OpPut(fmt.Sprintf("%s/config/inode/%d/%d", etcdPrefix, poolId, nextId), string(inodeCfgJson)),
-            ).Commit()
-            cancel()
-            if (err != nil)
-            {
-                return nil, status.Error(codes.Internal, "failed to commit transaction in etcd: "+err.Error())
-            }
-            if (txnResp.Succeeded)
-            {
-                imageId = nextId
-                break
-            }
-            // Start over if the transaction fails
+            return nil, err
         }
     }
 
@@ -278,6 +245,7 @@ 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
 }
@@ -291,105 +259,30 @@ func (cs *ControllerServer) DeleteVolume(ctx context.Context, req *csi.DeleteVol
         return nil, status.Error(codes.InvalidArgument, "request cannot be empty")
     }
 
-    ctxVars := make(map[string]string)
-    err := json.Unmarshal([]byte(req.VolumeId), &ctxVars)
+    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 := ctxVars["name"]
+    volName := volVars["name"]
 
-    _, etcdUrl, etcdPrefix := GetConnectionParams(ctxVars)
-    if (len(etcdUrl) == 0)
+    ctxVars, err := GetConnectionParams(volVars)
+    if (err != nil)
     {
-        return nil, status.Error(codes.InvalidArgument, "no etcdUrl in storage class configuration and no etcd_address in vitastor.conf")
+        return nil, err
     }
 
-    cli, err := clientv3.New(clientv3.Config{
-        DialTimeout: ETCD_TIMEOUT,
-        Endpoints: etcdUrl,
-    })
-    if (err != nil)
+    if (ctxVars["vitastorfs"] != "")
     {
-        return nil, status.Error(codes.Internal, "failed to connect to etcd at "+strings.Join(etcdUrl, ",")+": "+err.Error())
-    }
-    defer cli.Close()
-
-    // Find inode by name
-    ctx, cancel := context.WithTimeout(context.Background(), ETCD_TIMEOUT)
-    resp, err := cli.Get(ctx, etcdPrefix+"/index/image/"+volName)
-    cancel()
-    if (err != nil)
-    {
-        return nil, status.Error(codes.Internal, "failed to read key from etcd: "+err.Error())
-    }
-    if (len(resp.Kvs) == 0)
-    {
-        return nil, status.Error(codes.NotFound, "volume "+volName+" does not exist")
-    }
-    var idx InodeIndex
-    err = json.Unmarshal(resp.Kvs[0].Value, &idx)
-    if (err != nil)
-    {
-        return nil, status.Error(codes.Internal, "invalid /index/image/"+volName+" key in etcd: "+err.Error())
+        // FIXME: Delete FS subdirectory
+        return &csi.DeleteVolumeResponse{}, nil
     }
 
-    // Get inode config
-    inodeCfgKey := fmt.Sprintf("%s/config/inode/%d/%d", etcdPrefix, idx.PoolId, idx.Id)
-    ctx, cancel = context.WithTimeout(context.Background(), ETCD_TIMEOUT)
-    resp, err = cli.Get(ctx, inodeCfgKey)
-    cancel()
+    _, err = invokeCLI(ctxVars, []string{ "rm", volName })
     if (err != nil)
     {
-        return nil, status.Error(codes.Internal, "failed to read key from etcd: "+err.Error())
-    }
-    if (len(resp.Kvs) == 0)
-    {
-        return nil, status.Error(codes.NotFound, "volume "+volName+" does not exist")
-    }
-    var inodeCfg InodeConfig
-    err = json.Unmarshal(resp.Kvs[0].Value, &inodeCfg)
-    if (err != nil)
-    {
-        return nil, status.Error(codes.Internal, "invalid "+inodeCfgKey+" key in etcd: "+err.Error())
-    }
-
-    // Delete inode data by invoking vitastor-cli
-    args := []string{
-        "rm", "--etcd_address", strings.Join(etcdUrl, ","),
-        "--pool", fmt.Sprintf("%d", idx.PoolId),
-        "--inode", fmt.Sprintf("%d", idx.Id),
-    }
-    if (ctxVars["configPath"] != "")
-    {
-        args = append(args, "--config_path", ctxVars["configPath"])
-    }
-    c := exec.Command("/usr/bin/vitastor-cli", args...)
-    var stderr bytes.Buffer
-    c.Stdout = nil
-    c.Stderr = &stderr
-    err = c.Run()
-    stderrStr := string(stderr.Bytes())
-    if (err != nil)
-    {
-        klog.Errorf("vitastor-cli rm failed: %s, status %s\n", stderrStr, err)
-        return nil, status.Error(codes.Internal, stderrStr+" (status "+err.Error()+")")
-    }
-
-    // Delete inode config in etcd
-    ctx, cancel = context.WithTimeout(context.Background(), ETCD_TIMEOUT)
-    txnResp, err := cli.Txn(ctx).Then(
-        clientv3.OpDelete(fmt.Sprintf("%s/index/image/%s", etcdPrefix, volName)),
-        clientv3.OpDelete(fmt.Sprintf("%s/config/inode/%d/%d", etcdPrefix, idx.PoolId, idx.Id)),
-    ).Commit()
-    cancel()
-    if (err != nil)
-    {
-        return nil, status.Error(codes.Internal, "failed to delete keys in etcd: "+err.Error())
-    }
-    if (!txnResp.Succeeded)
-    {
-        return nil, status.Error(codes.Internal, "failed to delete keys in etcd: transaction failed")
+        return nil, err
     }
 
     return &csi.DeleteVolumeResponse{}, nil
@@ -420,19 +313,72 @@ func (cs *ControllerServer) ValidateVolumeCapabilities(ctx context.Context, req
     {
         return nil, status.Error(codes.InvalidArgument, "volumeId is nil")
     }
+    volVars := make(map[string]string)
+    err := json.Unmarshal([]byte(volumeID), &volVars)
+    if (err != nil)
+    {
+        return nil, status.Error(codes.Internal, "volume ID not in JSON format")
+    }
+    ctxVars, err := GetConnectionParams(volVars)
+    if (err != nil)
+    {
+        return nil, err
+    }
+
     volumeCapabilities := req.GetVolumeCapabilities()
     if (volumeCapabilities == nil)
     {
         return nil, status.Error(codes.InvalidArgument, "volumeCapabilities is nil")
     }
 
+    err = cs.checkCaps(volumeCapabilities, ctxVars["vitastorfs"] != "")
+    if (err != nil)
+    {
+        return nil, err
+    }
+
+    return &csi.ValidateVolumeCapabilitiesResponse{
+        Confirmed: &csi.ValidateVolumeCapabilitiesResponse_Confirmed{
+            VolumeCapabilities: req.VolumeCapabilities,
+        },
+    }, nil
+}
+
+func (cs *ControllerServer) checkCaps(volumeCapabilities []*csi.VolumeCapability, fs bool) error
+{
     var volumeCapabilityAccessModes []*csi.VolumeCapability_AccessMode
     for _, mode := range []csi.VolumeCapability_AccessMode_Mode{
         csi.VolumeCapability_AccessMode_SINGLE_NODE_WRITER,
-        csi.VolumeCapability_AccessMode_MULTI_NODE_MULTI_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)
+        {
+            if (fs)
+            {
+                return status.Errorf(codes.InvalidArgument, "%v not supported with FS-based volumes", capability)
+            }
+            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
+        }
+    }
+
+    if (fs)
+    {
+        // All access modes including RWX are supported with FS-based volumes
+        return nil
+    }
 
     capabilitySupport := false
     for _, capability := range volumeCapabilities
@@ -448,14 +394,10 @@ func (cs *ControllerServer) ValidateVolumeCapabilities(ctx context.Context, req
 
     if (!capabilitySupport)
     {
-        return nil, status.Errorf(codes.NotFound, "%v not supported", req.GetVolumeCapabilities())
+        return status.Errorf(codes.InvalidArgument, "%v not supported", volumeCapabilities)
     }
 
-    return &csi.ValidateVolumeCapabilitiesResponse{
-        Confirmed: &csi.ValidateVolumeCapabilitiesResponse_Confirmed{
-            VolumeCapabilities: req.VolumeCapabilities,
-        },
-    }, nil
+    return nil
 }
 
 // ListVolumes returns a list of volumes
@@ -490,6 +432,8 @@ 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))
     }
@@ -499,28 +443,252 @@ 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)
 {
-    return nil, status.Error(codes.Unimplemented, "")
+    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")
+    }
+
+    if (ctxVars["vitastorfs"] != "")
+    {
+        return nil, status.Error(codes.InvalidArgument, "VitastorFS doesn't support snapshots")
+    }
+
+    volName := ctxVars["name"]
+
+    // Create image using vitastor-cli
+    _, err = invokeCLI(ctxVars, []string{ "create", "--snapshot", snapName, volName })
+    if (err != nil && strings.Index(err.Error(), "already exists") <= 0)
+    {
+        return nil, err
+    }
+
+    // Check created snapshot
+    inodeCfg, err := invokeList(ctxVars, volName+"@"+snapName, true)
+    if (err != nil)
+    {
+        return nil, err
+    }
+
+    // Use ugly JSON snapshot ID again, DeleteSnapshot doesn't have context :-(
+    ctxVars["snapshot"] = snapName
+    snapIdJson, _ := json.Marshal(ctxVars)
+    return &csi.CreateSnapshotResponse{
+        Snapshot: &csi.Snapshot{
+            SizeBytes: int64(inodeCfg[0].Size),
+            SnapshotId: string(snapIdJson),
+            SourceVolumeId: req.SourceVolumeId,
+            CreationTime: &timestamppb.Timestamp{ Seconds: int64(inodeCfg[0].CreateTs) },
+            ReadyToUse: true,
+        },
+    }, nil
 }
 
 // DeleteSnapshot delete provided snapshot of a PV
 func (cs *ControllerServer) DeleteSnapshot(ctx context.Context, req *csi.DeleteSnapshotRequest) (*csi.DeleteSnapshotResponse, error)
 {
-    return nil, status.Error(codes.Unimplemented, "")
+    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
+    }
+
+    if (ctxVars["vitastorfs"] != "")
+    {
+        return nil, status.Error(codes.InvalidArgument, "VitastorFS doesn't support snapshots")
+    }
+
+    _, err = invokeCLI(ctxVars, []string{ "rm", volName+"@"+snapName })
+    if (err != nil)
+    {
+        return nil, err
+    }
+
+    return &csi.DeleteSnapshotResponse{}, nil
 }
 
 // ListSnapshots list the snapshots of a PV
 func (cs *ControllerServer) ListSnapshots(ctx context.Context, req *csi.ListSnapshotsRequest) (*csi.ListSnapshotsResponse, error)
 {
-    return nil, status.Error(codes.Unimplemented, "")
+    klog.Infof("received controller list snapshots request %+v", protosanitizer.StripSecrets(req))
+    if (req == nil)
+    {
+        return nil, status.Error(codes.InvalidArgument, "request cannot be empty")
+    }
+
+    volVars := make(map[string]string)
+    err := json.Unmarshal([]byte(req.SourceVolumeId), &volVars)
+    if (err != nil)
+    {
+        return nil, status.Error(codes.Internal, "volume ID not in JSON format")
+    }
+    volName := volVars["name"]
+    ctxVars, err := GetConnectionParams(volVars)
+    if (err != nil)
+    {
+        return nil, err
+    }
+
+    if (ctxVars["vitastorfs"] != "")
+    {
+        return nil, status.Error(codes.InvalidArgument, "VitastorFS doesn't support snapshots")
+    }
+
+    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 resizes a volume
+// ControllerExpandVolume increases the size of a volume
 func (cs *ControllerServer) ControllerExpandVolume(ctx context.Context, req *csi.ControllerExpandVolumeRequest) (*csi.ControllerExpandVolumeResponse, error)
 {
-    return nil, status.Error(codes.Unimplemented, "")
+    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
+    }
+
+    if (ctxVars["vitastorfs"] != "")
+    {
+        // Nothing to change
+        // FIXME: Support quotas and change quota here
+        return &csi.ControllerExpandVolumeResponse{
+            CapacityBytes: req.CapacityRange.RequiredBytes,
+            NodeExpansionRequired: false,
+        }, nil
+    }
+
+    inodeCfg, err := invokeList(ctxVars, volName, true)
+    if (err != nil)
+    {
+        return nil, err
+    }
+
+    if (req.CapacityRange.RequiredBytes > 0 && inodeCfg[0].Size < uint64(req.CapacityRange.RequiredBytes))
+    {
+        sz := ((req.CapacityRange.RequiredBytes+4095)/4096)*4096
+        _, err := invokeCLI(ctxVars, []string{ "modify", "--inc_size", "1", "--resize", fmt.Sprintf("%d", sz), volName })
+        if (err != nil)
+        {
+            return nil, err
+        }
+        inodeCfg, err = invokeList(ctxVars, volName, true)
+        if (err != nil)
+        {
+            return nil, err
+        }
+    }
+
+    return &csi.ControllerExpandVolumeResponse{
+        CapacityBytes: int64(inodeCfg[0].Size),
+        NodeExpansionRequired: false,
+    }, nil
 }
 
 // ControllerGetVolume get volume info

csi/src/identityserver.go

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

csi/src/utils.go

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

debian/build-pve-qemu.sh

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

debian/build-vitastor-bookworm.sh

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

debian/build-vitastor-bullseye.sh

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

debian/build-vitastor-buster.sh

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

debian/build-vitastor-ubuntu-jammy.sh

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

debian/changelog

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

debian/control

@@ -2,16 +2,69 @@ 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
+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,
+  node-bindings <!nocheck>, node-gyp, node-nan
 Standards-Version: 4.5.0
 Homepage: https://vitastor.io/
 Rules-Requires-Root: no
 
 Package: vitastor
 Architecture: amd64
-Depends: ${shlibs:Depends}, ${misc:Depends}, fio (= ${dep:fio}), qemu (= ${dep:qemu}), nodejs (>= 10), node-sprintf-js, node-ws (>= 7), libjerasure2, lp-solve
+Depends: vitastor-osd, vitastor-mon, vitastor-client, vitastor-client-dev, vitastor-fio
 Description: Vitastor, a fast software-defined clustered block storage
  Vitastor is a small, simple and fast clustered block storage (storage for VM drives),
  architecturally similar to Ceph which means strong consistency, primary-replication,
  symmetric clustering and automatic data distribution over any number of drives of any
  size with configurable redundancy (replication or erasure codes/XOR).
+
+Package: vitastor-osd
+Architecture: amd64
+Depends: ${shlibs:Depends}, ${misc:Depends}, vitastor-client (= ${binary:Version}), fdisk, util-linux, parted
+Description: Vitastor, a fast software-defined clustered block storage - object storage daemon
+ Vitastor object storage daemon, i.e. server program that stores data.
+
+Package: vitastor-mon
+Architecture: amd64
+Depends: ${misc:Depends}, nodejs (>= 10), node-sprintf-js, node-ws (>= 7), lp-solve
+Description: Vitastor, a fast software-defined clustered block storage - monitor
+ Vitastor monitor, i.e. server program responsible for watching cluster state and
+ scheduling cluster-level operations.
+
+Package: vitastor-client
+Architecture: amd64
+Depends: ${shlibs:Depends}, ${misc:Depends}
+Description: Vitastor, a fast software-defined clustered block storage - client
+ Vitastor client library and command-line interface.
+
+Package: vitastor-client-dev
+Section: devel
+Architecture: amd64
+Depends: ${misc:Depends}, vitastor-client (= ${binary:Version})
+Description: Vitastor, a fast software-defined clustered block storage - development files
+ Vitastor library headers for development.
+
+Package: vitastor-fio
+Architecture: amd64
+Depends: ${shlibs:Depends}, ${misc:Depends}, vitastor-client (= ${binary:Version}), fio (= ${dep:fio})
+Description: Vitastor, a fast software-defined clustered block storage - fio drivers
+ Vitastor fio drivers for benchmarking.
+
+Package: pve-storage-vitastor
+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.
+
+Package: node-vitastor
+Architecture: amd64
+Depends: ${shlibs:Depends}, ${misc:Depends}, node-bindings
+Description: Node.js bindings for Vitastor client
+ Node.js native bindings for the Vitastor client library (vitastor-client).

debian/fio_version

@@ -0,0 +1 @@
+dep:fio=3.16-1

debian/install

@@ -1,3 +1,4 @@
 VNPL-1.1.txt usr/share/doc/vitastor
 GPL-2.0.txt usr/share/doc/vitastor
-mon usr/lib/vitastor
+README.md usr/share/doc/vitastor
+README-ru.md usr/share/doc/vitastor

debian/libisal.pc

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

debian/libvirt.Dockerfile

@@ -0,0 +1,41 @@
+# 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 .
+
+ARG DISTRO=
+ARG REL=
+FROM $DISTRO:$REL
+ARG REL=
+
+WORKDIR /root
+
+RUN if ([ "${DISTRO}" = "debian" ]) && ( [ "${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; \
+    echo 'APT::Install-Recommends false;' >> /etc/apt/apt.conf; \
+    echo 'APT::Install-Suggests false;' >> /etc/apt/apt.conf
+
+RUN apt-get update; apt-get -y install devscripts
+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
+RUN set -e; \
+    mkdir -p /root/packages/libvirt-$REL; \
+    rm -rf /root/packages/libvirt-$REL/*; \
+    cd /root/packages/libvirt-$REL; \
+    dpkg-source -x /root/libvirt*.dsc; \
+    D=$(ls -d libvirt-*/); \
+    V=$(ls -d libvirt-*/ | perl -pe 's/libvirt-(\d+\.\d+).*/$1/'); \
+    cp /root/libvirt-$V-vitastor.diff $D/debian/patches; \
+    echo libvirt-$V-vitastor.diff >> $D/debian/patches/series; \
+    cd $D; \
+    V=$(head -n1 debian/changelog | perl -pe 's/^.*\((.*?)(~bpo[\d\+]*)?(\+deb[u\d]+)?\).*$/$1/')+vitastor2; \
+    DEBEMAIL="Vitaliy Filippov <vitalif@yourcmc.ru>" dch -D $REL -v $V 'Add Vitastor support'; \
+    DEB_BUILD_OPTIONS=nocheck dpkg-buildpackage --jobs=auto -sa; \
+    rm -rf /root/packages/libvirt-$REL/$D

debian/node-vitastor.install

@@ -0,0 +1 @@
+usr/lib/x86_64-linux-gnu/nodejs/vitastor

debian/patched-qemu.Dockerfile

@@ -1,50 +1,67 @@
-# Build patched QEMU for Debian Buster or Bullseye/Sid inside a container
+# Build patched QEMU for Debian inside a container
 # cd ..; podman build --build-arg REL=bullseye -v `pwd`/packages:/root/packages -f debian/patched-qemu.Dockerfile .
 
-FROM debian:$REL
+ARG DISTRO=debian
+ARG REL=
+FROM $DISTRO:$REL
+ARG DISTRO=debian
+ARG REL=
 
 WORKDIR /root
 
-RUN if [ "$REL" = "buster" ]; then \
-        echo 'deb http://deb.debian.org/debian buster-backports main' >> /etc/apt/sources.list; \
+RUN if [ "$REL" = "buster" -o "$REL" = "bullseye" -o "$REL" = "bookworm" ]; then \
+        if [ "$REL" = "buster" ]; then \
+            echo "deb http://archive.debian.org/debian $REL-backports main" >> /etc/apt/sources.list; \
+        else \
+            echo "deb http://deb.debian.org/debian $REL-backports main" >> /etc/apt/sources.list; \
+        fi; \
         echo >> /etc/apt/preferences; \
         echo 'Package: *' >> /etc/apt/preferences; \
-        echo 'Pin: release a=buster-backports' >> /etc/apt/preferences; \
+        echo "Pin: release n=$REL-backports" >> /etc/apt/preferences; \
         echo 'Pin-Priority: 500' >> /etc/apt/preferences; \
-        echo >> /etc/apt/preferences; \
-        echo 'Package: libglvnd* libgles* libglx* libgl1 libegl* libopengl* mesa*' >> /etc/apt/preferences; \
-        echo 'Pin: release a=buster-backports' >> /etc/apt/preferences; \
-        echo 'Pin-Priority: 50' >> /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 qemu fio liburing1 liburing-dev libgoogle-perftools-dev devscripts
-RUN apt-get -y build-dep qemu
-RUN apt-get -y build-dep fio
+RUN DEBIAN_FRONTEND=noninteractive TZ=Europe/Moscow apt-get -y install fio liburing-dev libgoogle-perftools-dev devscripts
+RUN DEBIAN_FRONTEND=noninteractive TZ=Europe/Moscow 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
-RUN apt-get --download-only source fio
 
-ADD patches/qemu-5.0-vitastor.patch patches/qemu-5.1-vitastor.patch /root/vitastor/patches/
+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
+
 RUN set -e; \
+    DEBIAN_FRONTEND=noninteractive TZ=Europe/Moscow apt-get -y install /root/packages/vitastor-$REL/vitastor-client_*.deb /root/packages/vitastor-$REL/vitastor-client-dev_*.deb; \
+    apt-get update; \
+    DEBIAN_FRONTEND=noninteractive TZ=Europe/Moscow apt-get -y install quilt; \
     mkdir -p /root/packages/qemu-$REL; \
     rm -rf /root/packages/qemu-$REL/*; \
     cd /root/packages/qemu-$REL; \
     dpkg-source -x /root/qemu*.dsc; \
-    if [ -d /root/packages/qemu-$REL/qemu-5.0 ]; then \
-        cp /root/vitastor/patches/qemu-5.0-vitastor.patch /root/packages/qemu-$REL/qemu-5.0/debian/patches; \
-        echo qemu-5.0-vitastor.patch >> /root/packages/qemu-$REL/qemu-5.0/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; \
+    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; \
     cd /root/packages/qemu-$REL/qemu-*/; \
-    V=$(head -n1 debian/changelog | perl -pe 's/^.*\((.*?)(~bpo[\d\+]*)?\).*$/$1/')+vitastor1; \
-    DEBFULLNAME="Vitaliy Filippov <vitalif@yourcmc.ru>" dch -D $REL -v $V 'Plug Vitastor block driver'; \
+    quilt push -a; \
+    quilt add block/vitastor.c; \
+    cp /root/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/^.*\((.*?)(\+deb\d+u\d+)?(~bpo[\d\+]*)?\).*$/$1/')+vitastor5; \
+    if [ "$REL" = bullseye ]; then V=${V}bullseye; fi; \
+    DEBEMAIL="Vitaliy Filippov <vitalif@yourcmc.ru>" dch -D $REL -v $V 'Plug Vitastor block driver'; \
     DEB_BUILD_OPTIONS=nocheck dpkg-buildpackage --jobs=auto -sa; \
     rm -rf /root/packages/qemu-$REL/qemu-*/

debian/pve-storage-vitastor.install

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

debian/raw.h

@@ -0,0 +1,19 @@
+/* Removed in Linux 5.14 */
+
+/* SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note */
+#ifndef __LINUX_RAW_H
+#define __LINUX_RAW_H
+
+#include <linux/types.h>
+
+#define RAW_SETBIND	_IO( 0xac, 0 )
+#define RAW_GETBIND	_IO( 0xac, 1 )
+
+struct raw_config_request 
+{
+	int	raw_minor;
+	__u64	block_major;
+	__u64	block_minor;
+};
+
+#endif /* __LINUX_RAW_H */

debian/rules

@@ -4,6 +4,15 @@ export DH_VERBOSE = 1
 %:
 	dh $@
 
+override_dh_install:
+	perl -pe 's!prefix=/usr!prefix='`pwd`'/debian/tmp/usr!' < obj-x86_64-linux-gnu/src/client/vitastor.pc > node-binding/vitastor.pc
+	cd node-binding && PKG_CONFIG_PATH=./ PKG_CONFIG_ALLOW_SYSTEM_CFLAGS=1 npm install --unsafe-perm || exit 1
+	mkdir -p debian/tmp/usr/lib/x86_64-linux-gnu/nodejs/vitastor/build/Release
+	cp -v node-binding/package.json node-binding/index.js node-binding/addon.cc node-binding/addon.h node-binding/client.cc node-binding/client.h debian/tmp/usr/lib/x86_64-linux-gnu/nodejs/vitastor
+	cp -v node-binding/build/Release/addon.node debian/tmp/usr/lib/x86_64-linux-gnu/nodejs/vitastor/build/Release
+	dh_install
+
 override_dh_installdeb:
-	cat debian/substvars >> debian/vitastor.substvars
+	cat debian/fio_version >> debian/vitastor-fio.substvars
+	[ -f debian/qemu_version ] && (cat debian/qemu_version >> debian/vitastor-qemu.substvars) || true
 	dh_installdeb

debian/substvars

@@ -1,2 +0,0 @@
-dep:fio=3.16-1
-dep:qemu=1:5.1+dfsg-4+vitastor1

debian/vitastor-client-dev.install

@@ -0,0 +1,2 @@
+usr/include
+usr/lib/*/pkgconfig

debian/vitastor-client.install

@@ -0,0 +1,8 @@
+usr/bin/vita
+usr/bin/vitastor-cli
+usr/bin/vitastor-rm
+usr/bin/vitastor-nbd
+usr/bin/vitastor-nfs
+usr/bin/vitastor-kv
+usr/bin/vitastor-kv-stress
+usr/lib/*/libvitastor*.so*

debian/vitastor-fio.install

@@ -0,0 +1 @@
+usr/lib/*/libfio*.so*

debian/vitastor-mon.install

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

debian/vitastor-mon.postinst

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

debian/vitastor-opennebula.install

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

debian/vitastor-opennebula.postinst

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

debian/vitastor-opennebula.triggers

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

debian/vitastor-osd.install

@@ -0,0 +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

debian/vitastor-osd.postinst

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

debian/vitastor.Dockerfile

@@ -1,67 +1,65 @@
-# 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 .
+# 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 .
 
-FROM debian:$REL
+ARG DISTRO=debian
+ARG REL=
+FROM $DISTRO:$REL
+ARG DISTRO=debian
+ARG REL=
 
 WORKDIR /root
 
-RUN if [ "$REL" = "buster" ]; then \
-        echo 'deb http://deb.debian.org/debian buster-backports main' >> /etc/apt/sources.list; \
-        echo >> /etc/apt/preferences; \
-        echo 'Package: *' >> /etc/apt/preferences; \
-        echo 'Pin: release a=buster-backports' >> /etc/apt/preferences; \
-        echo 'Pin-Priority: 500' >> /etc/apt/preferences; \
+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; \
     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 qemu fio liburing1 liburing-dev libgoogle-perftools-dev devscripts
-RUN apt-get -y build-dep qemu
-RUN apt-get -y build-dep fio
-RUN apt-get --download-only source qemu
-RUN apt-get --download-only source fio
-RUN apt-get update && apt-get -y install libjerasure-dev cmake libibverbs-dev
+RUN apt-get update && \
+    apt-get -y install fio liburing-dev libgoogle-perftools-dev devscripts libjerasure-dev cmake \
+        libibverbs-dev librdmacm-dev libisal-dev libnl-3-dev libnl-genl-3-dev curl nodejs npm node-nan node-bindings && \
+    apt-get -y build-dep fio && \
+    apt-get --download-only source fio
 
 ADD . /root/vitastor
 RUN set -e -x; \
+    [ -e /usr/lib/x86_64-linux-gnu/pkgconfig/libisal.pc ] || cp /root/vitastor/debian/libisal.pc /usr/lib/x86_64-linux-gnu/pkgconfig; \
     mkdir -p /root/fio-build/; \
     cd /root/fio-build/; \
     rm -rf /root/fio-build/*; \
     dpkg-source -x /root/fio*.dsc; \
-    cd /root/packages/qemu-$REL/; \
-    rm -rf qemu*/; \
-    dpkg-source -x qemu*.dsc; \
-    cd /root/packages/qemu-$REL/qemu*/; \
-    debian/rules b/configure-stamp; \
-    cd b/qemu; \
-    make -j8 qapi/qapi-builtin-types.h; \
     mkdir -p /root/packages/vitastor-$REL; \
     rm -rf /root/packages/vitastor-$REL/*; \
     cd /root/packages/vitastor-$REL; \
-    cp -r /root/vitastor vitastor-0.6.6; \
-    ln -s /root/packages/qemu-$REL/qemu-*/ vitastor-0.6.6/qemu; \
-    ln -s /root/fio-build/fio-*/ vitastor-0.6.6/fio; \
-    cd vitastor-0.6.6; \
+    FULLVER=$(head -n1 /root/vitastor/debian/changelog | perl -pe 's/^.*\((.*?)\).*$/$1/'); \
+    VER=${FULLVER%%-*}; \
+    cp -r /root/vitastor vitastor-$VER; \
+    cd vitastor-$VER; \
+    ln -s /root/fio-build/fio-*/ ./fio; \
     FIO=$(head -n1 fio/debian/changelog | perl -pe 's/^.*\((.*?)\).*$/$1/'); \
-    QEMU=$(head -n1 qemu/debian/changelog | perl -pe 's/^.*\((.*?)\).*$/$1/'); \
-    sh copy-qemu-includes.sh; \
+    ls /usr/include/linux/raw.h || cp ./debian/raw.h /usr/include/linux/raw.h; \
     sh copy-fio-includes.sh; \
-    rm qemu fio; \
+    rm fio; \
     mkdir -p a b debian/patches; \
-    mv qemu-copy b/qemu; \
     mv fio-copy b/fio; \
-    diff -NaurpbB a b > debian/patches/qemu-fio-headers.patch || true; \
-    echo qemu-fio-headers.patch >> debian/patches/series; \
+    diff -NaurpbB a b > debian/patches/fio-headers.patch || true; \
+    echo fio-headers.patch >> debian/patches/series; \
     rm -rf a b; \
-    rm -rf /root/packages/qemu-$REL/qemu*/; \
-    echo "dep:fio=$FIO" > debian/substvars; \
-    echo "dep:qemu=$QEMU" >> debian/substvars; \
+    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_0.6.6.orig.tar.xz vitastor-0.6.6; \
-    cd vitastor-0.6.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"; \
+    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"; \
     DEB_BUILD_OPTIONS=nocheck dpkg-buildpackage --jobs=auto -sa; \
     rm -rf /root/packages/vitastor-$REL/vitastor-*/

docker/Dockerfile

@@ -1,9 +1,11 @@
 # Build Docker image with Vitastor packages
 
-FROM debian:bullseye
+FROM debian:bookworm
 
-ADD vitastor.list /etc/apt/sources.list.d
-ADD vitastor.gpg /etc/apt/trusted.gpg.d
-ADD vitastor.pref /etc/apt/preferences.d
-ADD apt.conf /etc/apt/
-RUN apt-get update && apt-get -y install vitastor qemu-system-x86 qemu-system-common && apt-get clean
+ADD etc/apt /etc/apt/
+RUN apt-get update && apt-get -y install vitastor udev systemd qemu-system-x86 qemu-system-common qemu-block-extra qemu-utils jq nfs-common && apt-get clean
+ADD sleep.sh /usr/bin/
+ADD install.sh /usr/bin/
+ADD scripts /opt/scripts/
+ADD etc /etc/
+RUN ln -s /usr/lib/vitastor/mon/make-etcd /usr/bin/make-etcd

docker/Makefile

@@ -0,0 +1,9 @@
+VITASTOR_VERSION ?= v2.1.0
+
+all: build push
+
+build:
+	@docker build --no-cache --rm -t vitalif/vitastor:$(VITASTOR_VERSION) .
+
+push:
+	@docker push vitalif/vitastor:$(VITASTOR_VERSION)

docker/etc/apt/sources.list.d/vitastor.list

@@ -0,0 +1,2 @@
+deb http://vitastor.io/debian bookworm main
+deb http://http.debian.net/debian/ bookworm-backports main

docker/etc/systemd/system/vitastor-etcd.service

@@ -0,0 +1,27 @@
+[Unit]
+Description=Containerized etcd for Vitastor
+After=network-online.target local-fs.target time-sync.target docker.service vitastor-host.service
+Wants=network-online.target local-fs.target time-sync.target docker.service vitastor-host.service
+PartOf=vitastor.target
+
+[Service]
+Restart=always
+Environment=GOGC=50
+EnvironmentFile=/etc/vitastor/docker.conf
+EnvironmentFile=/etc/vitastor/etcd.conf
+SyslogIdentifier=etcd
+ExecStart=bash -c 'docker run --rm -i -v /var/lib/vitastor/etcd:/data \
+    --log-driver none --network host $CONTAINER_OPTIONS --name vitastor-etcd \
+    $ETCD_IMAGE /usr/local/bin/etcd --name "$ETCD_NAME" --data-dir /data \
+    --snapshot-count 10000 --advertise-client-urls http://$ETCD_IP:2379 --listen-client-urls http://$ETCD_IP:2379 \
+    --initial-advertise-peer-urls http://$ETCD_IP:2380 --listen-peer-urls http://$ETCD_IP:2380 \
+    --initial-cluster-token vitastor-etcd-1 --initial-cluster "$ETCD_INITIAL_CLUSTER" \
+    --initial-cluster-state new --max-txn-ops=100000 --max-request-bytes=104857600 \
+    --auto-compaction-retention=10 --auto-compaction-mode=revision'
+ExecStop=docker stop vitastor-etcd
+Restart=always
+StartLimitInterval=0
+RestartSec=10
+
+[Install]
+WantedBy=multi-user.target

docker/etc/systemd/system/vitastor-host.service

@@ -0,0 +1,23 @@
+[Unit]
+Description=Empty container for running Vitastor commands
+After=network-online.target local-fs.target time-sync.target docker.service
+Wants=network-online.target local-fs.target time-sync.target docker.service
+PartOf=vitastor.target
+
+[Service]
+Restart=always
+EnvironmentFile=/etc/vitastor/docker.conf
+ExecStart=bash -c 'docker run --rm -i -v /etc/vitastor:/etc/vitastor -v /dev:/dev -v /run:/run \
+    --security-opt seccomp=unconfined --privileged --pid=host --log-driver none --network host --name vitastor vitastor:$VITASTOR_VERSION \
+    sleep.sh'
+ExecStartPost=udevadm trigger
+ExecStop=docker stop vitastor
+WorkingDirectory=/
+PrivateTmp=false
+TasksMax=infinity
+Restart=always
+StartLimitInterval=0
+RestartSec=10
+
+[Install]
+WantedBy=multi-user.target

docker/etc/systemd/system/vitastor-mon.service

@@ -0,0 +1,23 @@
+[Unit]
+Description=Containerized Vitastor monitor
+After=network-online.target local-fs.target time-sync.target docker.service
+Wants=network-online.target local-fs.target time-sync.target docker.service
+PartOf=vitastor.target
+
+[Service]
+Restart=always
+EnvironmentFile=/etc/vitastor/docker.conf
+SyslogIdentifier=vitastor-mon
+ExecStart=bash -c 'docker run --rm -i -v /etc/vitastor:/etc/vitastor -v /var/lib/vitastor:/var/lib/vitastor -v /dev:/dev \
+    --log-driver none --network host $CONTAINER_OPTIONS --name vitastor-mon vitastor:$VITASTOR_VERSION \
+    node /usr/lib/vitastor/mon/mon-main.js'
+ExecStop=docker stop vitastor-mon
+WorkingDirectory=/
+PrivateTmp=false
+TasksMax=infinity
+Restart=always
+StartLimitInterval=0
+RestartSec=10
+
+[Install]
+WantedBy=multi-user.target

docker/etc/systemd/system/vitastor-osd@.service

@@ -0,0 +1,28 @@
+[Unit]
+Description=Containerized Vitastor object storage daemon osd.%i
+After=network-online.target local-fs.target time-sync.target docker.service vitastor-host.service
+Wants=network-online.target local-fs.target time-sync.target docker.service vitastor-host.service
+PartOf=vitastor.target
+
+[Service]
+LimitNOFILE=1048576
+LimitNPROC=1048576
+LimitMEMLOCK=infinity
+EnvironmentFile=/etc/vitastor/docker.conf
+SyslogIdentifier=vitastor-osd%i
+ExecStart=bash -c 'docker run --rm -i -v /etc/vitastor:/etc/vitastor -v /dev:/dev \
+    $(for i in $(ls /dev/vitastor/osd%i-*); do echo --device $i:$i; done) \
+    --log-driver none --network host --ulimit nofile=1048576 --ulimit memlock=-1 \
+    --security-opt seccomp=unconfined $CONTAINER_OPTIONS --name vitastor-osd%i \
+    vitastor:$VITASTOR_VERSION vitastor-disk exec-osd /dev/vitastor/osd%i-data'
+ExecStartPre=+docker exec vitastor vitastor-disk pre-exec /dev/vitastor/osd%i-data
+ExecStop=docker stop vitastor-etcd%i
+WorkingDirectory=/
+PrivateTmp=false
+TasksMax=infinity
+Restart=always
+StartLimitInterval=0
+RestartSec=10
+
+[Install]
+WantedBy=vitastor.target

docker/etc/systemd/system/vitastor.target

@@ -0,0 +1,4 @@
+[Unit]
+Description=vitastor target
+[Install]
+WantedBy=multi-user.target

docker/etc/udev/rules.d/90-vitastor.rules

@@ -0,0 +1,7 @@
+SUBSYSTEM=="block", ENV{ID_PART_ENTRY_TYPE}=="e7009fac-a5a1-4d72-af72-53de13059903", \
+    OWNER="vitastor", GROUP="vitastor", \
+    IMPORT{program}="/usr/bin/docker exec vitastor vitastor-disk udev $devnode", \
+    SYMLINK+="vitastor/$env{VITASTOR_ALIAS}"
+
+ENV{VITASTOR_OSD_NUM}!="", ACTION=="add", RUN{program}+="/usr/bin/systemctl enable --now --no-block vitastor-osd@$env{VITASTOR_OSD_NUM}"
+ENV{VITASTOR_OSD_NUM}!="", ACTION=="remove", RUN{program}+="/usr/bin/systemctl disable --now --no-block vitastor-osd@$env{VITASTOR_OSD_NUM}"

docker/etc/vitastor/docker.conf

@@ -0,0 +1,11 @@
+#
+# Configuration file for containerized Vitastor installation
+# (non-Kubernetes, with systemd and udev-based orchestration)
+#
+
+# Desired Vitastor version
+VITASTOR_VERSION=v2.1.0
+
+# Additional arguments for all containers
+# For example, you may want to specify a custom logging driver here
+CONTAINER_OPTIONS=""

docker/etc/vitastor/etcd.conf

@@ -0,0 +1,4 @@
+ETCD_IMAGE=quay.io/coreos/etcd:v3.5.18
+ETCD_NAME=""
+ETCD_IP=""
+ETCD_INITIAL_CLUSTER=""

docker/etc/vitastor/vitastor.conf

@@ -0,0 +1,2 @@
+{
+}

docker/install.sh

@@ -0,0 +1,9 @@
+#!/bin/bash
+
+set -e
+
+cp -urv /etc/default /host-etc/
+cp -urv /etc/systemd /host-etc/
+cp -urv /etc/udev /host-etc/
+cp -urnv /etc/vitastor /host-etc/
+cp -urnv /opt/scripts/* /host-bin/

docker/scripts/vitastor-cli

@@ -0,0 +1,3 @@
+#!/bin/bash
+
+docker exec -it vitastor vitastor-cli "$@"

docker/scripts/vitastor-disk

@@ -0,0 +1,3 @@
+#!/bin/bash
+
+docker exec -it vitastor vitastor-disk "$@"

docker/scripts/vitastor-fio

@@ -0,0 +1,3 @@
+#!/bin/bash
+
+docker exec -it vitastor fio "$@"

docker/scripts/vitastor-nbd

@@ -0,0 +1,3 @@
+#!/bin/bash
+
+docker exec -it vitastor vitastor-nbd "$@"

docker/sleep.sh

@@ -0,0 +1,3 @@
+#!/bin/bash
+
+while :; do sleep infinity; done

docker/vitastor.list

@@ -1 +0,0 @@
-deb http://vitastor.io/debian bullseye main

docs/config.en.md

@@ -0,0 +1,40 @@
+[Documentation](../README.md#documentation) → Configuration Reference
+
+-----
+
+[Читать на русском](config.ru.md)
+
+# Configuration Reference
+
+Vitastor configuration consists of:
+- [Configuration parameters (key-value)](#parameter-reference)
+- [Pool configuration](config/pool.en.md)
+- [OSD placement tree configuration](config/pool.en.md#placement-tree)
+- [Separate OSD settings](config/pool.en.md#osd-settings)
+- [Inode configuration](config/inode.en.md) i.e. image metadata like name, size and parent reference
+
+Configuration parameters can be set in 4 places:
+- Configuration file (`/etc/vitastor/vitastor.conf` or other path)
+- etcd key `/vitastor/config/global`. Most variables can be set there, but etcd
+  connection parameters should obviously be set in the configuration file.
+- Command line of Vitastor components: OSD (when you run it without vitastor-disk),
+  mon, fio and QEMU options, OpenStack/Proxmox/etc configuration. The latter
+  doesn't allow to set all variables directly, but it allows to override the
+  configuration file and set everything you need inside it.
+- OSD superblocks created by [vitastor-disk](usage/disk.en.md) contain
+  primarily disk layout parameters of specific OSDs. In fact, these parameters
+  are automatically passed into the command line of vitastor-osd process, so
+  they have the same "status" as command-line parameters.
+
+In the future, additional configuration methods may be added:
+- OSD-specific keys in etcd like `/vitastor/config/osd/<number>`.
+
+## Parameter Reference
+
+- [Common](config/common.en.md)
+- [Network](config/network.en.md)
+- [Client](config/client.en.md)
+- [Global Disk Layout](config/layout-cluster.en.md)
+- [OSD Disk Layout](config/layout-osd.en.md)
+- [OSD Runtime Parameters](config/osd.en.md)
+- [Monitor](config/monitor.en.md)

docs/config.ru.md

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

docs/config/client.en.md

@@ -0,0 +1,217 @@
+[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_wait_up_timeout](#client_wait_up_timeout)
+- [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_wait_up_timeout
+
+- Type: seconds
+- Default: 16
+- Can be changed online: yes
+
+Wait for this number of seconds until PGs are up when doing operations
+which require all PGs to be up. Currently only used by object listings
+in delete and merge-based commands ([vitastor-cli rm](../usage/cli.en.md#rm), merge and so on).
+
+The default value is calculated as `1 + OSD lease timeout`, which is
+`1 + etcd_report_interval + max_etcd_attempts*2*etcd_quick_timeout`.
+
+## client_max_dirty_bytes
+
+- Type: integer
+- Default: 33554432
+- Can be changed online: yes
+
+Without [immediate_commit](layout-cluster.en.md#immediate_commit)=all this parameter sets the limit of "dirty"
+(not committed by fsync) data allowed by the client before forcing an
+additional fsync and committing the data. Also note that the client always
+holds a copy of uncommitted data in memory so this setting also affects
+RAM usage of clients.
+
+## client_max_dirty_ops
+
+- Type: integer
+- Default: 1024
+- Can be changed online: yes
+
+Same as client_max_dirty_bytes, but instead of total size, limits the number
+of uncommitted write operations.
+
+## client_enable_writeback
+
+- Type: boolean
+- Default: false
+- Can be changed online: yes
+
+This parameter enables client-side write buffering. This means that write
+requests are accumulated in memory for a short time before being sent to
+a Vitastor cluster which allows to send them in parallel and increase
+performance of some applications. Writes are buffered until client forces
+a flush with fsync() or until the amount of buffered writes exceeds the
+limit.
+
+Write buffering significantly increases performance of some applications,
+for example, CrystalDiskMark under Windows (LOL :-D), but also any other
+applications if they do writes in one of two non-optimal ways: either if
+they do a lot of small (4 kb or so) sequential writes, or if they do a lot
+of small random writes, but without any parallelism or asynchrony, and also
+without calling fsync().
+
+With write buffering enabled, you can expect around 22000 T1Q1 random write
+iops in QEMU more or less regardless of the quality of your SSDs, and this
+number is in fact bound by QEMU itself rather than Vitastor (check it
+yourself by adding a "driver=null-co" disk in QEMU). Without write
+buffering, the current record is 9900 iops, but the number is usually
+even lower with non-ideal hardware, for example, it may be 5000 iops.
+
+Even when this parameter is enabled, write buffering isn't enabled until
+the client explicitly allows it, because enabling it without the client
+being aware of the fact that his writes may be buffered may lead to data
+loss. Because of this, older versions of clients don't support write
+buffering at all, newer versions of the QEMU driver allow write buffering
+only if it's enabled in disk settings with `-blockdev cache.direct=false`,
+and newer versions of FIO only allow write buffering if you don't specify
+`-direct=1`. NBD and NFS drivers allow write buffering by default.
+
+You can overcome this restriction too with the `client_writeback_allowed`
+parameter, but you shouldn't do that unless you **really** know what you
+are doing.
+
+## client_max_buffered_bytes
+
+- Type: integer
+- Default: 33554432
+- Can be changed online: yes
+
+Maximum total size of buffered writes which triggers write-back when reached.
+
+## client_max_buffered_ops
+
+- Type: integer
+- Default: 1024
+- Can be changed online: yes
+
+Maximum number of buffered writes which triggers write-back when reached.
+Multiple consecutive modified data regions are counted as 1 write here.
+
+## client_max_writeback_iodepth
+
+- Type: integer
+- Default: 256
+- Can be changed online: yes
+
+Maximum number of parallel writes when flushing buffered data to the server.
+
+## nbd_timeout
+
+- Type: seconds
+- Default: 300
+
+Timeout for I/O operations for [NBD](../usage/nbd.en.md). If an operation
+executes for longer than this timeout, including when your cluster is just
+temporarily down for more than timeout, the NBD device will detach by itself
+(and possibly break the mounted file system).
+
+You can set timeout to 0 to never detach, but in that case you won't be
+able to remove the kernel device at all if the NBD process dies - you'll have
+to reboot the host.
+
+## nbd_max_devices
+
+- Type: integer
+- Default: 64
+
+Maximum number of NBD devices in the system. This value is passed as
+`nbds_max` parameter for the nbd kernel module when vitastor-nbd autoloads it.
+
+## nbd_max_part
+
+- Type: integer
+- Default: 3
+
+Maximum number of partitions per NBD device. This value is passed as
+`max_part` parameter for the nbd kernel module when vitastor-nbd autoloads it.
+Note that (nbds_max)*(1+max_part) usually can't exceed 256.
+
+## osd_nearfull_ratio
+
+- Type: number
+- Default: 0.95
+- Can be changed online: yes
+
+Ratio of used space on OSD to treat it as "almost full" in vitastor-cli status output.
+
+Remember that some client writes may hang or complete with an error if even
+just one OSD becomes 100 % full!
+
+However, unlike in Ceph, 100 % full Vitastor OSDs don't crash (in Ceph they're
+unable to start at all), so you'll be able to recover from "out of space" errors
+without destroying and recreating OSDs.

docs/config/client.ru.md

@@ -0,0 +1,221 @@
+[Документация](../../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_wait_up_timeout](#client_wait_up_timeout)
+- [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_wait_up_timeout
+
+- Тип: секунды
+- Значение по умолчанию: 16
+- Можно менять на лету: да
+
+Время ожидания поднятия PG при операциях, требующих активности всех PG.
+В данный момент используется листингами объектов в командах, использующих
+удаление и слияние ([vitastor-cli rm](../usage/cli.ru.md#rm), merge и подобные).
+
+Значение по умолчанию вычисляется как `1 + время lease OSD`, равное
+`1 + etcd_report_interval + max_etcd_attempts*2*etcd_quick_timeout`.
+
+## client_max_dirty_bytes
+
+- Тип: целое число
+- Значение по умолчанию: 33554432
+- Можно менять на лету: да
+
+При работе без [immediate_commit](layout-cluster.ru.md#immediate_commit)=all - это лимит объёма "грязных" (не
+зафиксированных fsync-ом) данных, при достижении которого клиент будет
+принудительно вызывать fsync и фиксировать данные. Также стоит иметь в виду,
+что в этом случае до момента fsync клиент хранит копию незафиксированных
+данных в памяти, то есть, настройка влияет на потребление памяти клиентами.
+
+## client_max_dirty_ops
+
+- Тип: целое число
+- Значение по умолчанию: 1024
+- Можно менять на лету: да
+
+Аналогично client_max_dirty_bytes, но ограничивает количество
+незафиксированных операций записи вместо их общего объёма.
+
+## client_enable_writeback
+
+- Тип: булево (да/нет)
+- Значение по умолчанию: false
+- Можно менять на лету: да
+
+Данный параметр разрешает включать буферизацию записи в памяти. Буферизация
+означает, что операции записи отправляются на кластер Vitastor не сразу, а
+могут небольшое время накапливаться в памяти и сбрасываться сразу пакетами,
+до тех пор, пока либо не будет превышен лимит неотправленных записей, либо
+пока клиент не вызовет fsync.
+
+Буферизация значительно повышает производительность некоторых приложений,
+например, CrystalDiskMark в Windows (ха-ха :-D), но также и любых других,
+которые пишут на диск неоптимально: либо последовательно, но мелкими блоками
+(например, по 4 кб), либо случайно, но без параллелизма и без fsync - то
+есть, например, отправляя 128 операций записи в разные места диска, но не
+все сразу с помощью асинхронного I/O, а по одной.
+
+В QEMU с буферизацией записи можно ожидать показателя примерно 22000
+операций случайной записи в секунду в 1 поток и с глубиной очереди 1 (T1Q1)
+без fsync, почти вне зависимости от того, насколько хороши ваши диски - эта
+цифра упирается в сам QEMU. Без буферизации рекорд пока что - 9900 операций
+в секунду, но на железе похуже может быть и поменьше, например, 5000 операций
+в секунду.
+
+При этом, даже если данный параметр включён, буферизация не включается, если
+явно не разрешена клиентом, т.к. если клиент не знает, что запросы записи
+буферизуются, это может приводить к потере данных. Поэтому в старых версиях
+клиентских драйверов буферизация записи не включается вообще, в новых
+версиях QEMU-драйвера включается, только если разрешена опцией диска
+`-blockdev cache.direct=false`, а в fio - только если нет опции `-direct=1`.
+В NBD и NFS драйверах буферизация записи разрешена по умолчанию.
+
+Можно обойти и это ограничение с помощью параметра `client_writeback_allowed`,
+но делать так не надо, если только вы не уверены в том, что делаете, на все
+100%. :-)
+
+## client_max_buffered_bytes
+
+- Тип: целое число
+- Значение по умолчанию: 33554432
+- Можно менять на лету: да
+
+Максимальный общий размер буферизованных записей, при достижении которого
+начинается процесс сброса данных на сервер.
+
+## client_max_buffered_ops
+
+- Тип: целое число
+- Значение по умолчанию: 1024
+- Можно менять на лету: да
+
+Максимальное количество буферизованных записей, при достижении которого
+начинается процесс сброса данных на сервер. При этом несколько
+последовательных изменённых областей здесь считаются 1 записью.
+
+## client_max_writeback_iodepth
+
+- Тип: целое число
+- Значение по умолчанию: 256
+- Можно менять на лету: да
+
+Максимальное число параллельных операций записи при сбросе буферов на сервер.
+
+## nbd_timeout
+
+- Тип: секунды
+- Значение по умолчанию: 300
+
+Таймаут для операций чтения/записи через [NBD](../usage/nbd.ru.md). Если
+операция выполняется дольше таймаута, включая временную недоступность
+кластера на время, большее таймаута, NBD-устройство отключится само собой
+(и, возможно, сломает примонтированную ФС).
+
+Вы можете установить таймаут в 0, чтобы никогда не отключать устройство по
+таймауту, но в этом случае вы вообще не сможете удалить устройство, если
+процесс NBD умрёт - вам придётся перезагружать сервер.
+
+## nbd_max_devices
+
+- Тип: целое число
+- Значение по умолчанию: 64
+
+Максимальное число NBD-устройств в системе. Данное значение передаётся
+модулю ядра nbd как параметр `nbds_max`, когда его загружает vitastor-nbd.
+
+## nbd_max_part
+
+- Тип: целое число
+- Значение по умолчанию: 3
+
+Максимальное число разделов на одном NBD-устройстве. Данное значение передаётся
+модулю ядра nbd как параметр `max_part`, когда его загружает vitastor-nbd.
+Имейте в виду, что (nbds_max)*(1+max_part) обычно не может превышать 256.
+
+## osd_nearfull_ratio
+
+- Тип: число
+- Значение по умолчанию: 0.95
+- Можно менять на лету: да
+
+Доля занятого места на OSD, начиная с которой он считается "почти заполненным" в
+выводе vitastor-cli status.
+
+Помните, что часть клиентских запросов может зависнуть или завершиться с ошибкой,
+если на 100 % заполнится хотя бы 1 OSD!
+
+Однако, в отличие от Ceph, заполненные на 100 % OSD Vitastor не падают (в Ceph
+заполненные на 100% OSD вообще не могут стартовать), так что вы сможете
+восстановить работу кластера после ошибок отсутствия свободного места
+без уничтожения и пересоздания OSD.

docs/config/common.en.md

@@ -0,0 +1,52 @@
+[Documentation](../../README.md#documentation) → [Configuration](../config.en.md) → Common Parameters
+
+-----
+
+[Читать на русском](common.ru.md)
+
+# Common Parameters
+
+These are the most common parameters which apply to all components of Vitastor.
+
+- [config_path](#config_path)
+- [etcd_address](#etcd_address)
+- [etcd_prefix](#etcd_prefix)
+- [log_level](#log_level)
+
+## config_path
+
+- Type: string
+- Default: /etc/vitastor/vitastor.conf
+
+Path to the JSON configuration file. Configuration file is optional,
+a non-existing configuration file does not prevent Vitastor from
+running if required parameters are specified.
+
+## etcd_address
+
+- Type: string or array of strings
+- Can be changed online: yes
+
+etcd connection endpoint(s). Multiple endpoints may be delimited by "," or
+specified in a JSON array `["10.0.115.10:2379/v3","10.0.115.11:2379/v3"]`.
+Note that https is not supported for etcd connections yet.
+
+etcd connection endpoints can be changed online by updating global
+configuration in etcd itself - this allows to switch the cluster to new
+etcd addresses without downtime.
+
+## etcd_prefix
+
+- Type: string
+- Default: /vitastor
+
+Prefix for all keys in etcd used by Vitastor. You can change prefix and, for
+example, use a single etcd cluster for multiple Vitastor clusters.
+
+## log_level
+
+- Type: integer
+- Default: 0
+- Can be changed online: yes
+
+Log level. Raise if you want more verbose output.

docs/config/common.ru.md

@@ -0,0 +1,50 @@
+[Документация](../../README-ru.md#документация) → [Конфигурация](../config.ru.md) → Общие параметры
+
+-----
+
+[Read in English](common.en.md)
+
+# Общие параметры
+
+Это наиболее общие параметры, используемые всеми компонентами Vitastor.
+
+- [config_path](#config_path)
+- [etcd_address](#etcd_address)
+- [etcd_prefix](#etcd_prefix)
+- [log_level](#log_level)
+
+## config_path
+
+- Тип: строка
+- Значение по умолчанию: /etc/vitastor/vitastor.conf
+
+Путь к файлу конфигурации в формате JSON. Файл конфигурации необязателен,
+без него Vitastor тоже будет работать, если переданы необходимые параметры.
+
+## etcd_address
+
+- Тип: строка или массив строк
+- Можно менять на лету: да
+
+Адрес(а) подключения к etcd. Несколько адресов могут разделяться запятой
+или указываться в виде JSON-массива `["10.0.115.10:2379/v3","10.0.115.11:2379/v3"]`.
+
+Адреса подключения к etcd можно поменять на лету, обновив конфигурацию в
+самом etcd - это позволяет переключить кластер на новые etcd без остановки.
+
+## etcd_prefix
+
+- Тип: строка
+- Значение по умолчанию: /vitastor
+
+Префикс для ключей etcd, которые использует Vitastor. Вы можете задать другой
+префикс, например, чтобы запустить несколько кластеров Vitastor с одним
+кластером etcd.
+
+## log_level
+
+- Тип: целое число
+- Значение по умолчанию: 0
+- Можно менять на лету: да
+
+Уровень логгирования. Повысьте, если хотите более подробный вывод.

docs/config/inode.en.md

@@ -0,0 +1,32 @@
+[Documentation](../../README.md#documentation) → [Configuration](../config.en.md) → Image metadata in etcd
+
+-----
+
+[Читать на русском](inode.ru.md)
+
+# Image metadata in etcd
+
+Image list is stored in etcd in `/vitastor/config/inode/<pool>/<inode>` keys.
+
+You can even create images manually:
+
+```
+etcdctl --endpoints=<etcd> put /vitastor/config/inode/<pool>/<inode> '{"name":"<name>","size":<size>[,"parent_id":<parent_inode_number>][,"readonly":true]}'
+```
+
+For example:
+
+```
+etcdctl --endpoints=http://10.115.0.10:2379/v3 put /vitastor/config/inode/1/1 '{"name":"testimg","size":2147483648}'
+```
+
+If you specify parent_id the image becomes a CoW clone. I.e. all writes go to the new inode and reads first check it
+and then upper layers. You can then make parent readonly by updating its entry with `"readonly":true` for safety and
+basically treat it as a snapshot.
+
+So to create a snapshot you basically rename the previous upper layer (for example from testimg to testimg@0), make it readonly
+and create a new top layer with the original name (testimg) and the previous one as a parent.
+
+vitastor-cli, K8s, OpenStack and other drivers also store the reverse mapping in `/vitastor/index/image/<name>` keys
+in JSON format: `{"id":<inode>,"pool_id":<pool>}` and ID counters in `/vitastor/index/maxid/<pool>` as numbers
+to simplify ID generation.

docs/config/inode.ru.md

@@ -0,0 +1,34 @@
+[Документация](../../README-ru.md#документация) → [Конфигурация](../config.ru.md) → Метаданные образов в etcd
+
+-----
+
+[Read in English](inode.en.md)
+
+# Метаданные образов в etcd
+
+Список образов хранится в etcd в ключах `/vitastor/config/inode/<pool>/<inode>`.
+
+Вы можете даже создавать образы вручную:
+
+```
+etcdctl --endpoints=<etcd> put /vitastor/config/inode/<pool>/<inode> '{"name":"<name>","size":<size>[,"parent_id":<parent_inode_number>][,"readonly":true]}'
+```
+
+Например:
+
+```
+etcdctl --endpoints=http://10.115.0.10:2379/v3 put /vitastor/config/inode/1/1 '{"name":"testimg","size":2147483648}'
+```
+
+Если вы зададите parent_id, то образ станет CoW-клоном, т.е. все новые запросы записи пойдут в новый инод, а запросы
+чтения будут проверять сначала его, а потом родительские слои по цепочке вверх. Чтобы случайно не перезаписать данные
+в родительском слое, вы можете переключить его в режим "только чтение", добавив флаг `"readonly":true` в его запись
+метаданных. В таком случае родительский образ становится просто снапшотом.
+
+Таким образом, для создания снапшота вам нужно просто переименовать предыдущий inode (например, из testimg в testimg@0),
+сделать его readonly и создать новый слой с исходным именем образа (testimg), ссылающийся на только что переименованный
+в качестве родительского.
+
+vitastor-cli и драйвера K8s, OpenStack и т.п. также хранят обратный маппинг в ключах `/vitastor/index/image/<name>`
+в JSON-формате: `{"id":<inode>,"pool_id":<pool>}` и счётчики ID `/vitastor/index/maxid/<pool>` в виде просто чисел
+для упрощения генерации ID новых образов.

docs/config/layout-cluster.en.md

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

docs/config/layout-cluster.ru.md

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

docs/config/layout-osd.en.md

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

docs/config/layout-osd.ru.md

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