Test etcd schizophrenia

- Fix a bug introduced in 2.2.0 - pg_locks weren't disabled for pools without local_reads
  correctly which could lead to inactive pools during various operations
- Fix an old bug where OSDs could send sub-operations to incorrect peer OSDs when their
  connections were stopped and reestablished quickly, in 2.2.0 it was usually leading
  to "sequencing broken" messages in OSD logs
- Fix debug use_sync_send_recv mode

.gitea/workflows/buildenv.Dockerfile

@@ -22,7 +22,7 @@ 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 -y install jq lp-solve sudo nfs-common
+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; \

.gitea/workflows/test.yml

@@ -288,6 +288,24 @@ jobs:
           echo ""
         done
 
+  test_create_halfhost:
+    runs-on: ubuntu-latest
+    needs: build
+    container: ${{env.TEST_IMAGE}}:${{github.sha}}
+    steps:
+    - name: Run test
+      id: test
+      timeout-minutes: 3
+      run: /root/vitastor/tests/test_create_halfhost.sh
+    - 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
+
   test_failure_domain:
     runs-on: ubuntu-latest
     needs: build
@@ -396,6 +414,24 @@ jobs:
           echo ""
         done
 
+  test_rm_degraded:
+    runs-on: ubuntu-latest
+    needs: build
+    container: ${{env.TEST_IMAGE}}:${{github.sha}}
+    steps:
+    - name: Run test
+      id: test
+      timeout-minutes: 3
+      run: /root/vitastor/tests/test_rm_degraded.sh
+    - 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
+
   test_snapshot_chain:
     runs-on: ubuntu-latest
     needs: build
@@ -648,6 +684,24 @@ jobs:
           echo ""
         done
 
+  test_write_iothreads:
+    runs-on: ubuntu-latest
+    needs: build
+    container: ${{env.TEST_IMAGE}}:${{github.sha}}
+    steps:
+    - name: Run test
+      id: test
+      timeout-minutes: 3
+      run: TEST_NAME=iothreads GLOBAL_CONFIG=',"client_iothread_count":4' /root/vitastor/tests/test_write.sh
+    - 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
+
   test_write_no_same:
     runs-on: ubuntu-latest
     needs: build
@@ -684,6 +738,24 @@ jobs:
           echo ""
         done
 
+  test_heal_local_read:
+    runs-on: ubuntu-latest
+    needs: build
+    container: ${{env.TEST_IMAGE}}:${{github.sha}}
+    steps:
+    - name: Run test
+      id: test
+      timeout-minutes: 10
+      run: TEST_NAME=local_read POOLCFG='"local_reads":"random",' /root/vitastor/tests/test_heal.sh
+    - 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
+
   test_heal_ec:
     runs-on: ubuntu-latest
     needs: build
@@ -828,6 +900,60 @@ jobs:
           echo ""
         done
 
+  test_resize:
+    runs-on: ubuntu-latest
+    needs: build
+    container: ${{env.TEST_IMAGE}}:${{github.sha}}
+    steps:
+    - name: Run test
+      id: test
+      timeout-minutes: 3
+      run: /root/vitastor/tests/test_resize.sh
+    - 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
+
+  test_resize_auto:
+    runs-on: ubuntu-latest
+    needs: build
+    container: ${{env.TEST_IMAGE}}:${{github.sha}}
+    steps:
+    - name: Run test
+      id: test
+      timeout-minutes: 3
+      run: /root/vitastor/tests/test_resize_auto.sh
+    - 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
+
+  test_snapshot_pool2:
+    runs-on: ubuntu-latest
+    needs: build
+    container: ${{env.TEST_IMAGE}}:${{github.sha}}
+    steps:
+    - name: Run test
+      id: test
+      timeout-minutes: 3
+      run: /root/vitastor/tests/test_snapshot_pool2.sh
+    - 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
+
   test_osd_tags:
     runs-on: ubuntu-latest
     needs: build

CMakeLists.txt

@@ -2,6 +2,6 @@ cmake_minimum_required(VERSION 2.8.12)
 
 project(vitastor)
 
-set(VITASTOR_VERSION "1.8.0")
+set(VITASTOR_VERSION "2.2.2")
 
 add_subdirectory(src)

README-ru.md

@@ -1,4 +1,4 @@
-## Vitastor
+# Vitastor
 
 [Read English version](README.md)
 
@@ -6,7 +6,7 @@
 
 Вернём былую скорость кластерному блочному хранилищу!
 
-Vitastor - распределённая блочная и файловая SDS (программная СХД), прямой аналог Ceph RBD и CephFS,
+Vitastor - распределённая блочная, файловая и объектная SDS (программная СХД), прямой аналог Ceph RBD, CephFS и RGW,
 а также внутренних СХД популярных облачных провайдеров. Однако, в отличие от них, Vitastor
 быстрый и при этом простой. Только пока маленький :-).
 
@@ -22,7 +22,7 @@ TCP и RDMA и на хорошем железе может достигать з
 Vitastor поддерживает QEMU-драйвер, протоколы NBD и NFS, драйверы OpenStack, OpenNebula, Proxmox, Kubernetes.
 Другие драйверы могут также быть легко реализованы.
 
-Подробности смотрите в документации по ссылкам ниже.
+Подробности смотрите в документации по ссылкам. Можете начать отсюда: [Быстрый старт](docs/intro/quickstart.ru.md).
 
 ## Презентации и записи докладов
 
@@ -41,17 +41,19 @@ Vitastor поддерживает QEMU-драйвер, протоколы NBD и
   - [Автор и лицензия](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.en.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)

README.md

@@ -6,7 +6,7 @@
 
 Make Clustered Block Storage Fast Again.
 
-Vitastor is a distributed block and file SDS, direct replacement of Ceph RBD and CephFS,
+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 :-).
 
@@ -22,7 +22,7 @@ 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 below in the documentation.
+Read more details in the documentation. You can start from here: [Quick Start](docs/intro/quickstart.en.md).
 
 ## Talks and presentations
 
@@ -41,10 +41,12 @@ Read more details below in the documentation.
   - [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)

csi/Dockerfile

@@ -22,6 +22,8 @@ RUN apt-get update && \
     (echo "APT::Install-Recommends false;" > /etc/apt/apt.conf) && \
     apt-get update && \
     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 && \
@@ -35,8 +37,8 @@ RUN (echo deb http://vitastor.io/debian bookworm main > /etc/apt/sources.list.d/
     wget -q -O /etc/apt/trusted.gpg.d/vitastor.gpg https://vitastor.io/debian/pubkey.gpg && \
     apt-get update && \
     apt-get install -y vitastor-client && \
-    wget https://vitastor.io/archive/qemu/qemu-bookworm-8.1.2%2Bds-1%2Bvitastor1/qemu-utils_8.1.2%2Bds-1%2Bvitastor1_amd64.deb && \
-    wget https://vitastor.io/archive/qemu/qemu-bookworm-8.1.2%2Bds-1%2Bvitastor1/qemu-block-extra_8.1.2%2Bds-1%2Bvitastor1_amd64.deb && \
+    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/ && \

csi/Makefile

@@ -1,4 +1,4 @@
-VITASTOR_VERSION ?= v1.8.0
+VITASTOR_VERSION ?= v2.2.2
 
 all: build push
 

csi/deploy/004-csi-nodeplugin.yaml

@@ -49,7 +49,7 @@ spec:
             capabilities:
               add: ["SYS_ADMIN"]
             allowPrivilegeEscalation: true
-          image: vitalif/vitastor-csi:v1.8.0
+          image: vitalif/vitastor-csi:v2.2.2
           args:
             - "--node=$(NODE_ID)"
             - "--endpoint=$(CSI_ENDPOINT)"

csi/deploy/007-csi-provisioner.yaml

@@ -121,7 +121,7 @@ spec:
             privileged: true
             capabilities:
               add: ["SYS_ADMIN"]
-          image: vitalif/vitastor-csi:v1.8.0
+          image: vitalif/vitastor-csi:v2.2.2
           args:
             - "--node=$(NODE_ID)"
             - "--endpoint=$(CSI_ENDPOINT)"

csi/deploy/009-storage-class.yaml

@@ -9,8 +9,16 @@ 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"

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/go.mod

@@ -3,10 +3,10 @@ module vitastor.io/csi
 go 1.15
 
 require (
-	github.com/container-storage-interface/spec v1.4.0
+	github.com/container-storage-interface/spec v1.8.0
 	github.com/golang/glog v0.0.0-20160126235308-23def4e6c14b
 	github.com/kubernetes-csi/csi-lib-utils v0.9.1
-	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

csi/go.sum

@@ -41,8 +41,8 @@ github.com/chzyer/logex v1.1.10/go.mod h1:+Ywpsq7O8HXn0nuIou7OrIPyXbp3wmkHB+jjWR
 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.4.0 h1:ozAshSKxpJnYUfmkpZCTYyF/4MYeYlhdXbAvPvfGmkg=
-github.com/container-storage-interface/spec v1.4.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=
@@ -182,6 +182,7 @@ github.com/stretchr/testify v1.3.0/go.mod h1:M5WIy9Dh21IEIfnGCwXGc5bZfKNJtfHm1UV
 github.com/stretchr/testify v1.4.0/go.mod h1:j7eGeouHqKxXV5pUuKE4zz7dFj8WfuZ+81PSLYec5m4=
 github.com/stretchr/testify v1.5.1 h1:nOGnQDM7FYENwehXlg/kFVnos3rEvtKTjRvOWSzb6H4=
 github.com/stretchr/testify v1.5.1/go.mod h1:5W2xD1RspED5o8YsWQXVCued0rvSQ+mT+I5cxcmMvtA=
+github.com/yuin/goldmark v1.4.13/go.mod h1:6yULJ656Px+3vBD8DxQVa3kxgyrAnzto9xy5taEt/CY=
 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=
@@ -195,6 +196,7 @@ golang.org/x/crypto v0.0.0-20190605123033-f99c8df09eb5/go.mod h1:yigFU9vqHzYiE8U
 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=
@@ -213,6 +215,7 @@ golang.org/x/mobile v0.0.0-20190719004257-d2bd2a29d028/go.mod h1:E/iHnbuqvinMTCc
 golang.org/x/mod v0.0.0-20190513183733-4bf6d317e70e/go.mod h1:mXi4GBBbnImb6dmsKGUJ2LatrhH/nqhxcFungHvyanc=
 golang.org/x/mod v0.1.0/go.mod h1:0QHyrYULN0/3qlju5TqG8bIK38QM8yzMo5ekMj3DlcY=
 golang.org/x/mod v0.1.1-0.20191105210325-c90efee705ee/go.mod h1:QqPTAvyqsEbceGzBzNggFXnrqF1CaUcvgkdR5Ot7KZg=
+golang.org/x/mod v0.6.0-dev.0.20220419223038-86c51ed26bb4/go.mod h1:jJ57K6gSWd91VN4djpZkiMVwK6gcyfeH4XE8wZrZaV4=
 golang.org/x/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=
@@ -228,8 +231,10 @@ golang.org/x/net v0.0.0-20190620200207-3b0461eec859/go.mod h1:z5CRVTTTmAJ677TzLL
 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-20201202161906-c7110b5ffcbb h1:eBmm0M9fYhWpKZLjQUUKka/LtIxf46G4fxeEz5KJr9U=
-golang.org/x/net v0.0.0-20201202161906-c7110b5ffcbb/go.mod h1:sp8m0HH+o8qH0wwXwYZr8TS3Oi6o0r6Gce1SSxlDquU=
+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=
@@ -240,6 +245,7 @@ golang.org/x/sync v0.0.0-20181221193216-37e7f081c4d4/go.mod h1:RxMgew5VJxzue5/jJ
 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=
@@ -259,13 +265,22 @@ golang.org/x/sys v0.0.0-20200302150141-5c8b2ff67527/go.mod h1:h1NjWce9XRLGQEsW7w
 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-20200930185726-fdedc70b468f h1:+Nyd8tzPX9R7BWHguqsrbFdRx3WQ/1ib8I44HXV5yTA=
-golang.org/x/sys v0.0.0-20200930185726-fdedc70b468f/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 h1:cokOdA+Jmi5PJGXLlLllQSgYigAEfHXJAERHVMaCc2k=
 golang.org/x/text v0.3.3/go.mod h1:5Zoc/QRtKVWzQhOtBMvqHzDpF6irO9z98xDceosuGiQ=
+golang.org/x/text v0.3.7/go.mod h1:u+2+/6zg+i71rQMx5EYifcz6MCKuco9NR6JIITiCfzQ=
+golang.org/x/text v0.7.0 h1:4BRB4x83lYWy72KwLD/qYDuTu7q9PjSagHvijDw7cLo=
+golang.org/x/text v0.7.0/go.mod h1:mrYo+phRRbMaCq/xk9113O4dZlRixOauAjOtrjsXDZ8=
 golang.org/x/time v0.0.0-20181108054448-85acf8d2951c/go.mod h1:tRJNPiyCQ0inRvYxbN9jk5I+vvW/OXSQhTDSoE431IQ=
 golang.org/x/time v0.0.0-20190308202827-9d24e82272b4/go.mod h1:tRJNPiyCQ0inRvYxbN9jk5I+vvW/OXSQhTDSoE431IQ=
 golang.org/x/time v0.0.0-20191024005414-555d28b269f0/go.mod h1:tRJNPiyCQ0inRvYxbN9jk5I+vvW/OXSQhTDSoE431IQ=
@@ -286,8 +301,10 @@ golang.org/x/tools v0.0.0-20190628153133-6cdbf07be9d0/go.mod h1:/rFqwRUd4F7ZHNgw
 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=

csi/src/config.go

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

csi/src/controllerserver.go

@@ -8,11 +8,8 @@ import (
     "encoding/json"
     "fmt"
     "strings"
-    "bytes"
-    "strconv"
     "time"
     "os"
-    "os/exec"
     "io/ioutil"
 
     "github.com/kubernetes-csi/csi-lib-utils/protosanitizer"
@@ -70,9 +67,10 @@ func GetConnectionParams(params map[string]string) (map[string]string, error)
     {
         configPath = "/etc/vitastor/vitastor.conf"
     }
-    else
+    ctxVars["configPath"] = configPath
+    if (params["vitastorfs"] != "")
     {
-        ctxVars["configPath"] = configPath
+        ctxVars["vitastorfs"] = params["vitastorfs"]
     }
     config := make(map[string]interface{})
     configFD, err := os.Open(configPath)
@@ -114,22 +112,6 @@ func GetConnectionParams(params map[string]string) (map[string]string, error)
     return ctxVars, nil
 }
 
-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, status %s\n", stdoutStr+stderrStr, err)
-        return nil, nil, status.Error(codes.Internal, stdoutStr+stderrStr+" (status "+err.Error()+")")
-    }
-    return stdout.Bytes(), stderr.Bytes(), nil
-}
-
 func invokeCLI(ctxVars map[string]string, args []string) ([]byte, error)
 {
     if (ctxVars["configPath"] != "")
@@ -158,27 +140,57 @@ 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)
-    {
-        return nil, status.Error(codes.InvalidArgument, "poolId is missing in storage class configuration")
-    }
-
-    volName := etcdVolumePrefix + req.GetName()
-    volSize := 1 * GB
-    if capRange := req.GetCapacityRange(); capRange != nil
-    {
-        volSize = ((capRange.GetRequiredBytes() + MB - 1) / MB) * MB
-    }
-
     ctxVars, err := GetConnectionParams(req.Parameters)
     if (err != nil)
     {
         return nil, err
     }
 
-    args := []string{ "create", volName, "-s", fmt.Sprintf("%v", volSize), "--pool", fmt.Sprintf("%v", poolId) }
+    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")
+    }
+    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
+    }
+
+    if (ctxVars["vitastorfs"] != "")
+    {
+        // 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
+    }
+
+    args := []string{ "create", volName, "-s", fmt.Sprintf("%v", volSize), "--pool", pool }
 
     // Support creation from snapshot
     var src *csi.VolumeContentSource
@@ -261,6 +273,12 @@ func (cs *ControllerServer) DeleteVolume(ctx context.Context, req *csi.DeleteVol
         return nil, err
     }
 
+    if (ctxVars["vitastorfs"] != "")
+    {
+        // FIXME: Delete FS subdirectory
+        return &csi.DeleteVolumeResponse{}, nil
+    }
+
     _, err = invokeCLI(ctxVars, []string{ "rm", volName })
     if (err != nil)
     {
@@ -295,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
@@ -323,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
@@ -419,6 +486,12 @@ func (cs *ControllerServer) CreateSnapshot(ctx context.Context, req *csi.CreateS
     {
         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
@@ -477,6 +550,11 @@ func (cs *ControllerServer) DeleteSnapshot(ctx context.Context, req *csi.DeleteS
         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)
     {
@@ -508,6 +586,11 @@ func (cs *ControllerServer) ListSnapshots(ctx context.Context, req *csi.ListSnap
         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)
     {
@@ -571,6 +654,16 @@ func (cs *ControllerServer) ControllerExpandVolume(ctx context.Context, req *csi
         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)
     {

csi/src/nodeserver.go

@@ -5,11 +5,15 @@ package vitastor
 
 import (
     "context"
+    "crypto/sha1"
+    "encoding/hex"
     "encoding/json"
     "fmt"
     "os"
     "os/exec"
     "path/filepath"
+    "regexp"
+    "strconv"
     "strings"
     "sync"
     "syscall"
@@ -29,13 +33,14 @@ import (
 type NodeServer struct
 {
     *Driver
-    useVduse bool
-    stateDir string
-    mounter mount.Interface
+    useVduse        bool
+    stateDir        string
+    nfsStageDir     string
+    mounter         mount.Interface
     restartInterval time.Duration
-    mu sync.Mutex
-    cond *sync.Cond
-    volumeLocks map[string]bool
+    mu              sync.Mutex
+    cond            *sync.Cond
+    volumeLocks     map[string]bool
 }
 
 type DeviceState struct
@@ -48,6 +53,15 @@ type DeviceState struct
     PidFile    string `json:"pidFile"`
 }
 
+type NfsState struct
+{
+    ConfigPath string `json:"configPath"`
+    FsName     string `json:"fsName"`
+    Pool       string `json:"pool"`
+    Path       string `json:"path"`
+    Port       int    `json:"port"`
+}
+
 // NewNodeServer create new instance node
 func NewNodeServer(driver *Driver) *NodeServer
 {
@@ -60,11 +74,17 @@ func NewNodeServer(driver *Driver) *NodeServer
     {
         stateDir += "/"
     }
+    nfsStageDir := os.Getenv("NFS_STAGE_DIR")
+    if (nfsStageDir == "")
+    {
+        nfsStageDir = "/var/lib/kubelet/plugins/csi.vitastor.io/nfs"
+    }
     ns := &NodeServer{
-        Driver: driver,
-        useVduse: checkVduseSupport(),
-        stateDir: stateDir,
-        mounter: mount.New(""),
+        Driver:      driver,
+        useVduse:    checkVduseSupport(),
+        stateDir:    stateDir,
+        nfsStageDir: nfsStageDir,
+        mounter:     mount.New(""),
         volumeLocks: make(map[string]bool),
     }
     ns.cond = sync.NewCond(&ns.mu)
@@ -123,12 +143,12 @@ func (ns *NodeServer) restarter()
 func (ns *NodeServer) restoreVduseDaemons()
 {
     pattern := ns.stateDir+"vitastor-vduse-*.json"
-    matches, err := filepath.Glob(pattern)
+    stateFiles, err := filepath.Glob(pattern)
     if (err != nil)
     {
         klog.Errorf("failed to list %s: %v", pattern, err)
     }
-    if (len(matches) == 0)
+    if (len(stateFiles) == 0)
     {
         return
     }
@@ -146,59 +166,162 @@ func (ns *NodeServer) restoreVduseDaemons()
         klog.Errorf("/sbin/vdpa -j dev list returned bad JSON (error %v): %v", err, string(devListJSON))
         return
     }
-    for _, stateFile := range matches
+    for _, stateFile := range stateFiles
     {
-        vdpaId := filepath.Base(stateFile)
-        vdpaId = vdpaId[0:len(vdpaId)-5]
-        // Check if VDPA device is still added to the bus
-        if (devs[vdpaId] == nil)
-        {
-            // Unused, clean it up
-            unmapVduseById(ns.stateDir, vdpaId)
-            continue
-        }
+        ns.checkVduseState(stateFile, devs)
+    }
+}
 
-        stateJSON, err := os.ReadFile(stateFile)
+func (ns *NodeServer) checkVduseState(stateFile string, devs map[string]interface{})
+{
+    // Check if VDPA device is still added to the bus
+    vdpaId := filepath.Base(stateFile)
+    vdpaId = vdpaId[0:len(vdpaId)-5]
+    if (devs[vdpaId] == nil)
+    {
+        // Unused, clean it up
+        unmapVduseById(ns.stateDir, vdpaId)
+        return
+    }
+
+    // Read state file
+    stateJSON, err := os.ReadFile(stateFile)
+    if (err != nil)
+    {
+        klog.Warningf("error reading state file %v: %v", stateFile, err)
+        return
+    }
+    var state DeviceState
+    err = json.Unmarshal(stateJSON, &state)
+    if (err != nil)
+    {
+        klog.Warningf("state file %v contains invalid JSON (error %v): %v", stateFile, err, string(stateJSON))
+        return
+    }
+
+    // Lock volume
+    ns.lockVolume(state.ConfigPath+":block:"+state.Image)
+    defer ns.unlockVolume(state.ConfigPath+":block:"+state.Image)
+
+    // Recheck state file after locking
+    _, err = os.ReadFile(stateFile)
+    if (err != nil)
+    {
+        klog.Warningf("state file %v disappeared, skipping volume", stateFile)
+        return
+    }
+
+    // Check if the storage daemon is still active
+    pidFile := ns.stateDir + vdpaId + ".pid"
+    exists := false
+    proc, err := findByPidFile(pidFile)
+    if (err == nil)
+    {
+        exists = proc.Signal(syscall.Signal(0)) == nil
+    }
+    if (!exists)
+    {
+        // Restart daemon
+        klog.Warningf("restarting storage daemon for volume %v (VDPA ID %v)", state.Image, vdpaId)
+        err = startStorageDaemon(vdpaId, state.Image, pidFile, state.ConfigPath, state.Readonly)
         if (err != nil)
         {
-            klog.Warningf("error reading state file %v: %v", stateFile, err)
-            continue
+            klog.Warningf("failed to restart storage daemon for volume %v: %v", state.Image, err)
         }
-        var state DeviceState
-        err = json.Unmarshal(stateJSON, &state)
+    }
+}
+
+func (ns *NodeServer) restoreNfsDaemons()
+{
+    pattern := ns.stateDir+"vitastor-nfs-*.json"
+    stateFiles, err := filepath.Glob(pattern)
+    if (err != nil)
+    {
+        klog.Errorf("failed to list %s: %v", pattern, err)
+    }
+    if (len(stateFiles) == 0)
+    {
+        return
+    }
+    activeNFS, err := ns.listActiveNFS()
+    if (err != nil)
+    {
+        return
+    }
+    // Check all state files and try to restore active mounts
+    for _, stateFile := range stateFiles
+    {
+        ns.checkNfsState(stateFile, activeNFS)
+    }
+}
+
+func (ns *NodeServer) readNfsState(stateFile string, allowNotExists bool) (*NfsState, error)
+{
+    stateJSON, err := os.ReadFile(stateFile)
+    if (err != nil)
+    {
+        if (allowNotExists && os.IsNotExist(err))
+        {
+            return nil, nil
+        }
+        klog.Warningf("error reading state file %v: %v", stateFile, err)
+        return nil, err
+    }
+    var state NfsState
+    err = json.Unmarshal(stateJSON, &state)
+    if (err != nil)
+    {
+        klog.Warningf("state file %v contains invalid JSON (error %v): %v", stateFile, err, string(stateJSON))
+        return nil, err
+    }
+    return &state, nil
+}
+
+func (ns *NodeServer) checkNfsState(stateFile string, activeNfs map[int][]string)
+{
+    // Read state file
+    state, err := ns.readNfsState(stateFile, false)
+    if (err != nil)
+    {
+        return
+    }
+    // Lock FS
+    ns.lockVolume(state.ConfigPath+":fs:"+state.FsName)
+    defer ns.unlockVolume(state.ConfigPath+":fs:"+state.FsName)
+    // Check if NFS at this port is still mounted
+    pidFile := ns.stateDir + filepath.Base(stateFile)
+    pidFile = pidFile[0:len(pidFile)-5] + ".pid"
+    if (len(activeNfs[state.Port]) == 0)
+    {
+        // this is a stale state file, remove it
+        klog.Warningf("state file %v contains stale mount at port %d, removing it", stateFile, state.Port)
+        ns.stopNFS(stateFile, pidFile)
+        return
+    }
+    // Check PID file
+    exists := false
+    proc, err := findByPidFile(pidFile)
+    if (err == nil)
+    {
+        exists = proc.Signal(syscall.Signal(0)) == nil
+    }
+    if (!exists)
+    {
+        // Restart vitastor-nfs server
+        klog.Warningf("restarting NFS server for FS %v at port %v", state.FsName, state.Port)
+        _, _, err := system(
+            "/usr/bin/vitastor-nfs", "start",
+            "--pidfile", pidFile,
+            "--bind", "127.0.0.1",
+            "--port", fmt.Sprintf("%d", state.Port),
+            "--fs", state.FsName,
+            "--pool", state.Pool,
+            "--portmap", "0",
+        )
         if (err != nil)
         {
-            klog.Warningf("state file %v contains invalid JSON (error %v): %v", stateFile, err, string(stateJSON))
-            continue
+            klog.Warningf("failed to restart NFS server for FS %v: %v", state.FsName, err)
         }
-
-        ns.lockVolume(state.ConfigPath+":"+state.Image)
-
-        // Recheck state file after locking
-        _, err = os.ReadFile(stateFile)
-        if (err != nil)
-        {
-            klog.Warningf("state file %v disappeared, skipping volume", stateFile)
-            ns.unlockVolume(state.ConfigPath+":"+state.Image)
-            continue
-        }
-
-        // Check if the storage daemon is still active
-        pidFile := ns.stateDir + vdpaId + ".pid"
-        exists := false
-        proc, err := findByPidFile(pidFile)
-        if (err == nil)
-        {
-            exists = proc.Signal(syscall.Signal(0)) == nil
-        }
-        if (!exists)
-        {
-            // Restart daemon
-            klog.Warningf("restarting storage daemon for volume %v (VDPA ID %v)", state.Image, vdpaId)
-            _ = startStorageDaemon(vdpaId, state.Image, pidFile, state.ConfigPath, state.Readonly)
-        }
-
-        ns.unlockVolume(state.ConfigPath+":"+state.Image)
     }
 }
 
@@ -220,14 +343,44 @@ func (ns *NodeServer) NodeStageVolume(ctx context.Context, req *csi.NodeStageVol
     }
     volName := ctxVars["name"]
 
-    ns.lockVolume(ctxVars["configPath"]+":"+volName)
-    defer ns.unlockVolume(ctxVars["configPath"]+":"+volName)
+    if (ctxVars["vitastorfs"] != "")
+    {
+        return &csi.NodeStageVolumeResponse{}, nil
+    }
+
+    ns.lockVolume(ctxVars["configPath"]+":block:"+volName)
+    defer ns.unlockVolume(ctxVars["configPath"]+":block:"+volName)
 
     targetPath := req.GetStagingTargetPath()
     isBlock := req.GetVolumeCapability().GetBlock() != nil
 
     // Check that it's not already mounted
-    _, err = mount.IsNotMountPoint(ns.mounter, targetPath)
+    notmnt, err := mount.IsNotMountPoint(ns.mounter, targetPath)
+    if (err == nil)
+    {
+        if (!notmnt)
+        {
+            klog.Errorf("target path %s is already mounted", targetPath)
+            return nil, fmt.Errorf("target path %s is already mounted", targetPath)
+        }
+        var finfo os.FileInfo
+        finfo, err = os.Stat(targetPath)
+        if (err != nil)
+        {
+            klog.Errorf("failed to stat %s: %v", targetPath, err)
+            return nil, err
+        }
+        if (finfo.IsDir() != (!isBlock))
+        {
+            err = os.Remove(targetPath)
+            if (err != nil)
+            {
+                klog.Errorf("failed to remove %s (to recreate it with correct type): %v", targetPath, err)
+                return nil, err
+            }
+            err = os.ErrNotExist
+        }
+    }
     if (err != nil)
     {
         if (os.IsNotExist(err))
@@ -280,6 +433,7 @@ func (ns *NodeServer) NodeStageVolume(ctx context.Context, req *csi.NodeStageVol
     diskMounter := &mount.SafeFormatAndMount{Interface: ns.mounter, Exec: utilexec.New()}
     if (isBlock)
     {
+        klog.Infof("bind-mounting %s to %s", devicePath, targetPath)
         err = diskMounter.Mount(devicePath, targetPath, "", []string{"bind"})
     }
     else
@@ -309,39 +463,40 @@ func (ns *NodeServer) NodeStageVolume(ctx context.Context, req *csi.NodeStageVol
         readOnly := Contains(opt, "ro")
         if (existingFormat == "" && !readOnly)
         {
-            var cmdOut []byte
             switch fsType
             {
                 case "ext4":
                     args := []string{"-m0", "-Enodiscard,lazy_itable_init=1,lazy_journal_init=1", devicePath}
-                    cmdOut, err = diskMounter.Exec.Command("mkfs.ext4", args...).CombinedOutput()
+                    _, err = systemCombined("mkfs.ext4", args...)
                 case "xfs":
-                    cmdOut, err = diskMounter.Exec.Command("mkfs.xfs", "-K", devicePath).CombinedOutput()
+                    _, err = systemCombined("mkfs.xfs", "-K", devicePath)
             }
             if (err != nil)
             {
-                klog.Errorf("failed to run mkfs error: %v, output: %v", err, string(cmdOut))
                 goto unmap
             }
         }
 
+        klog.Infof("formatting and mounting %s to %s with FS %s, options: %v", devicePath, targetPath, fsType, opt)
         err = diskMounter.FormatAndMount(devicePath, targetPath, fsType, opt)
+        if (err == nil)
+        {
+            klog.Infof("successfully mounted %s to %s", devicePath, targetPath)
+        }
 
         // Try to run online resize on mount.
         // FIXME: Implement online resize. It requires online resize support in vitastor-nbd.
         if (err == nil && existingFormat != "" && !readOnly)
         {
-            var cmdOut []byte
             switch (fsType)
             {
                 case "ext4":
-                    cmdOut, err = diskMounter.Exec.Command("resize2fs", devicePath).CombinedOutput()
+                    _, err = systemCombined("resize2fs", devicePath)
                 case "xfs":
-                    cmdOut, err = diskMounter.Exec.Command("xfs_growfs", devicePath).CombinedOutput()
+                    _, err = systemCombined("xfs_growfs", devicePath)
             }
             if (err != nil)
             {
-                klog.Errorf("failed to run resizefs error: %v, output: %v", err, string(cmdOut))
                 goto unmap
             }
         }
@@ -381,11 +536,16 @@ func (ns *NodeServer) NodeUnstageVolume(ctx context.Context, req *csi.NodeUnstag
     }
     volName := ctxVars["name"]
 
-    ns.lockVolume(ctxVars["configPath"]+":"+volName)
-    defer ns.unlockVolume(ctxVars["configPath"]+":"+volName)
+    if (ctxVars["vitastorfs"] != "")
+    {
+        return &csi.NodeUnstageVolumeResponse{}, nil
+    }
+
+    ns.lockVolume(ctxVars["configPath"]+":block:"+volName)
+    defer ns.unlockVolume(ctxVars["configPath"]+":block:"+volName)
 
     targetPath := req.GetStagingTargetPath()
-    devicePath, refCount, err := mount.GetDeviceNameFromMount(ns.mounter, targetPath)
+    devicePath, _, err := mount.GetDeviceNameFromMount(ns.mounter, targetPath)
     if (err != nil)
     {
         if (os.IsNotExist(err))
@@ -402,6 +562,16 @@ func (ns *NodeServer) NodeUnstageVolume(ctx context.Context, req *csi.NodeUnstag
         return &csi.NodeUnstageVolumeResponse{}, nil
     }
 
+    refList, err := ns.mounter.GetMountRefs(targetPath)
+    if (err != nil)
+    {
+        return nil, err
+    }
+    if (len(refList) > 0)
+    {
+        klog.Warningf("%s is still referenced: %v", targetPath, refList)
+    }
+
     // unmount
     err = mount.CleanupMountPoint(targetPath, ns.mounter, false)
     if (err != nil)
@@ -410,7 +580,7 @@ func (ns *NodeServer) NodeUnstageVolume(ctx context.Context, req *csi.NodeUnstag
     }
 
     // unmap device
-    if (refCount == 1)
+    if (len(refList) == 0)
     {
         if (!ns.useVduse)
         {
@@ -425,6 +595,153 @@ func (ns *NodeServer) NodeUnstageVolume(ctx context.Context, req *csi.NodeUnstag
     return &csi.NodeUnstageVolumeResponse{}, nil
 }
 
+// Mount or check if NFS is already mounted
+func (ns *NodeServer) mountNFS(ctxVars map[string]string) (string, error)
+{
+    sum := sha1.Sum([]byte(ctxVars["configPath"]+":fs:"+ctxVars["vitastorfs"]))
+    nfsHash := hex.EncodeToString(sum[:])
+    stateFile := ns.stateDir+"vitastor-nfs-"+nfsHash+".json"
+    pidFile := ns.stateDir+"vitastor-nfs-"+nfsHash+".pid"
+    mountPath := ns.nfsStageDir+"/"+nfsHash
+    state, err := ns.readNfsState(stateFile, true)
+    if (state != nil)
+    {
+        return state.Path, nil
+    }
+    if (err != nil)
+    {
+        return "", err
+    }
+    err = os.MkdirAll(mountPath, 0777)
+    if (err != nil)
+    {
+        return "", err
+    }
+    // Create a new mount
+    state = &NfsState{
+        ConfigPath: ctxVars["configPath"],
+        FsName:     ctxVars["vitastorfs"],
+        Pool:       ctxVars["pool"],
+        Path:       mountPath,
+    }
+    klog.Infof("starting new NFS server for FS %v", state.FsName)
+    stdout, _, err := system(
+        "/usr/bin/vitastor-nfs", "start",
+        "--pidfile", pidFile,
+        "--bind", "127.0.0.1",
+        "--port", "auto",
+        "--fs", state.FsName,
+        "--pool", state.Pool,
+        "--portmap", "0",
+    )
+    if (err != nil)
+    {
+        return "", err
+    }
+    match := regexp.MustCompile("Port: (\\d+)").FindStringSubmatch(string(stdout))
+    if (match == nil)
+    {
+        klog.Errorf("failed to find port in vitastor-nfs output: %v", string(stdout))
+        ns.stopNFS(stateFile, pidFile)
+        return "", fmt.Errorf("failed to find port in vitastor-nfs output (bad vitastor-nfs version?)")
+    }
+    port, _ := strconv.ParseUint(match[1], 0, 16)
+    state.Port = int(port)
+    // Write state file
+    stateJSON, _ := json.Marshal(state)
+    err = os.WriteFile(stateFile, stateJSON, 0600)
+    if (err != nil)
+    {
+        klog.Errorf("failed to write state file %v", stateFile)
+        ns.stopNFS(stateFile, pidFile)
+        return "", err
+    }
+    // Mount NFS
+    _, _, err = system(
+        "mount", "-t", "nfs", "127.0.0.1:/", state.Path,
+        "-o", fmt.Sprintf("port=%d,mountport=%d,nfsvers=3,soft,nolock,tcp", port, port),
+    )
+    if (err != nil)
+    {
+        ns.stopNFS(stateFile, pidFile)
+        return "", err
+    }
+    return state.Path, nil
+}
+
+// Mount or check if NFS is already mounted
+func (ns *NodeServer) checkStopNFS(ctxVars map[string]string)
+{
+    sum := sha1.Sum([]byte(ctxVars["configPath"]+":fs:"+ctxVars["vitastorfs"]))
+    nfsHash := hex.EncodeToString(sum[:])
+    stateFile := ns.stateDir+"vitastor-nfs-"+nfsHash+".json"
+    pidFile := ns.stateDir+"vitastor-nfs-"+nfsHash+".pid"
+    mountPath := ns.nfsStageDir+"/"+nfsHash
+    state, err := ns.readNfsState(stateFile, true)
+    if (state == nil)
+    {
+        return
+    }
+    activeNFS, err := ns.listActiveNFS()
+    if (err != nil)
+    {
+        return
+    }
+    if (len(activeNFS[state.Port]) > 0)
+    {
+        return
+    }
+    // All volume mounts are detached, unmount the root mount and kill the server
+    err = mount.CleanupMountPoint(mountPath, ns.mounter, false)
+    if (err != nil)
+    {
+        klog.Errorf("failed to unmount %v: %v", mountPath, err)
+        return
+    }
+    ns.stopNFS(stateFile, pidFile)
+}
+
+func (ns *NodeServer) stopNFS(stateFile, pidFile string)
+{
+    err := killByPidFile(pidFile)
+    if (err != nil)
+    {
+        klog.Errorf("failed to kill process with pid from %v: %v", pidFile, err)
+    }
+    os.Remove(pidFile)
+    os.Remove(stateFile)
+}
+
+func (ns *NodeServer) listActiveNFS() (map[int][]string, error)
+{
+    mounts, err := mount.ParseMountInfo("/proc/self/mountinfo")
+    if (err != nil)
+    {
+        klog.Errorf("failed to list mounts: %v", err)
+        return nil, err
+    }
+    activeNFS := make(map[int][]string)
+    for _, mount := range mounts
+    {
+        // Volume mounts always refer to subpaths
+        if (mount.FsType == "nfs" && mount.Root != "/")
+        {
+            for _, opt := range mount.MountOptions
+            {
+                if (strings.HasPrefix(opt, "port="))
+                {
+                    port64, err := strconv.ParseUint(opt[5:], 10, 16)
+                    if (err == nil)
+                    {
+                        activeNFS[int(port64)] = append(activeNFS[int(port64)], mount.MountPoint)
+                    }
+                }
+            }
+        }
+    }
+    return activeNFS, nil
+}
+
 // NodePublishVolume mounts the volume mounted to the staging path to the target path
 func (ns *NodeServer) NodePublishVolume(ctx context.Context, req *csi.NodePublishVolumeRequest) (*csi.NodePublishVolumeResponse, error)
 {
@@ -443,23 +760,39 @@ func (ns *NodeServer) NodePublishVolume(ctx context.Context, req *csi.NodePublis
     }
     volName := ctxVars["name"]
 
-    ns.lockVolume(ctxVars["configPath"]+":"+volName)
-    defer ns.unlockVolume(ctxVars["configPath"]+":"+volName)
+    if (ctxVars["vitastorfs"] != "")
+    {
+        ns.lockVolume(ctxVars["configPath"]+":fs:"+ctxVars["vitastorfs"])
+        defer ns.unlockVolume(ctxVars["configPath"]+":fs:"+ctxVars["vitastorfs"])
+    }
+    else
+    {
+        ns.lockVolume(ctxVars["configPath"]+":block:"+volName)
+        defer ns.unlockVolume(ctxVars["configPath"]+":block:"+volName)
+    }
 
     stagingTargetPath := req.GetStagingTargetPath()
     targetPath := req.GetTargetPath()
     isBlock := req.GetVolumeCapability().GetBlock() != nil
 
-    // Check that stagingTargetPath is mounted
-    _, err = mount.IsNotMountPoint(ns.mounter, stagingTargetPath)
-    if (err != nil)
+    if (ctxVars["vitastorfs"] == "")
     {
-        klog.Errorf("staging path %v is not mounted: %v", stagingTargetPath, err)
-        return nil, fmt.Errorf("staging path %v is not mounted: %v", stagingTargetPath, err)
+        // Check that stagingTargetPath is mounted
+        notmnt, err := mount.IsNotMountPoint(ns.mounter, stagingTargetPath)
+        if (err != nil)
+        {
+            klog.Errorf("staging path %v is not mounted: %w", stagingTargetPath, err)
+            return nil, fmt.Errorf("staging path %v is not mounted: %w", stagingTargetPath, err)
+        }
+        else if (notmnt)
+        {
+            klog.Errorf("staging path %v is not mounted", stagingTargetPath)
+            return nil, fmt.Errorf("staging path %v is not mounted", stagingTargetPath)
+        }
     }
 
     // Check that targetPath is not already mounted
-    _, err = mount.IsNotMountPoint(ns.mounter, targetPath)
+    notmnt, err := mount.IsNotMountPoint(ns.mounter, targetPath)
     if (err != nil)
     {
         if (os.IsNotExist(err))
@@ -494,6 +827,29 @@ func (ns *NodeServer) NodePublishVolume(ctx context.Context, req *csi.NodePublis
             return nil, err
         }
     }
+    else if (!notmnt)
+    {
+        klog.Errorf("target path %s is already mounted", targetPath)
+        return nil, fmt.Errorf("target path %s is already mounted", targetPath)
+    }
+
+    if (ctxVars["vitastorfs"] != "")
+    {
+        nfspath, err := ns.mountNFS(ctxVars)
+        if (err != nil)
+        {
+            ns.checkStopNFS(ctxVars)
+            return nil, err
+        }
+        // volName should include prefix
+        stagingTargetPath = nfspath+"/"+volName
+        err = os.MkdirAll(stagingTargetPath, 0777)
+        if (err != nil && !os.IsExist(err))
+        {
+            ns.checkStopNFS(ctxVars)
+            return nil, err
+        }
+    }
 
     execArgs := []string{"--bind", stagingTargetPath, targetPath}
     if (req.GetReadonly())
@@ -506,6 +862,10 @@ func (ns *NodeServer) NodePublishVolume(ctx context.Context, req *csi.NodePublis
     out, err := cmd.Output()
     if (err != nil)
     {
+        if (ctxVars["vitastorfs"] != "")
+        {
+            ns.checkStopNFS(ctxVars)
+        }
         return nil, fmt.Errorf("Error running mount %v: %s", strings.Join(execArgs, " "), out)
     }
 
@@ -525,8 +885,16 @@ func (ns *NodeServer) NodeUnpublishVolume(ctx context.Context, req *csi.NodeUnpu
     }
     volName := ctxVars["name"]
 
-    ns.lockVolume(ctxVars["configPath"]+":"+volName)
-    defer ns.unlockVolume(ctxVars["configPath"]+":"+volName)
+    if (ctxVars["vitastorfs"] != "")
+    {
+        ns.lockVolume(ctxVars["configPath"]+":fs:"+ctxVars["vitastorfs"])
+        defer ns.unlockVolume(ctxVars["configPath"]+":fs:"+ctxVars["vitastorfs"])
+    }
+    else
+    {
+        ns.lockVolume(ctxVars["configPath"]+":block:"+volName)
+        defer ns.unlockVolume(ctxVars["configPath"]+":block:"+volName)
+    }
 
     targetPath := req.GetTargetPath()
     devicePath, _, err := mount.GetDeviceNameFromMount(ns.mounter, targetPath)
@@ -553,6 +921,11 @@ func (ns *NodeServer) NodeUnpublishVolume(ctx context.Context, req *csi.NodeUnpu
         return nil, err
     }
 
+    if (ctxVars["vitastorfs"] != "")
+    {
+        ns.checkStopNFS(ctxVars)
+    }
+
     return &csi.NodeUnpublishVolumeResponse{}, nil
 }
 

csi/src/utils.go

@@ -4,6 +4,7 @@
 package vitastor
 
 import (
+    "bytes"
     "errors"
     "encoding/json"
     "fmt"
@@ -15,6 +16,8 @@ import (
     "syscall"
 
     "k8s.io/klog"
+    "google.golang.org/grpc/codes"
+    "google.golang.org/grpc/status"
 )
 
 func Contains(list []string, s string) bool
@@ -73,6 +76,10 @@ func checkVduseSupport() bool
             " 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
 }
 
@@ -97,6 +104,7 @@ func mapNbd(volName string, ctxVars map[string]string, readonly bool) (string, e
     {
         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
 }
 
@@ -217,6 +225,7 @@ func mapVduse(stateDir string, volName string, ctxVars map[string]string, readon
                     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
                     }
                 }
@@ -299,3 +308,35 @@ func unmapVduseById(stateDir, vdpaId string)
         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/changelog

@@ -1,4 +1,4 @@
-vitastor (1.8.0-1) unstable; urgency=medium
+vitastor (2.2.2-1) unstable; urgency=medium
 
   * Bugfixes
 

debian/control

@@ -2,7 +2,10 @@ Source: vitastor
 Section: admin
 Priority: optional
 Maintainer: Vitaliy Filippov <vitalif@yourcmc.ru>
-Build-Depends: debhelper, liburing-dev (>= 0.6), g++ (>= 8), libstdc++6 (>= 8), linux-libc-dev, libgoogle-perftools-dev, libjerasure-dev, libgf-complete-dev, libibverbs-dev, libisal-dev, cmake, pkg-config, libnl-3-dev, libnl-genl-3-dev
+Build-Depends: debhelper, liburing-dev (>= 0.6), g++ (>= 8), libstdc++6 (>= 8),
+  linux-libc-dev, libgoogle-perftools-dev, libjerasure-dev, libgf-complete-dev,
+  libibverbs-dev, libisal-dev, 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
@@ -59,3 +62,9 @@ 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/node-vitastor.install

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

debian/patched-qemu.Dockerfile

@@ -1,17 +1,23 @@
 # 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 .
 
+ARG DISTRO=debian
 ARG REL=
-FROM debian:$REL
+FROM $DISTRO:$REL
+ARG DISTRO=debian
 ARG REL=
 
 WORKDIR /root
 
 RUN if [ "$REL" = "buster" -o "$REL" = "bullseye" -o "$REL" = "bookworm" ]; then \
-        echo "deb http://deb.debian.org/debian $REL-backports main" >> /etc/apt/sources.list; \
+        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=$REL-backports" >> /etc/apt/preferences; \
+        echo "Pin: release n=$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; \
@@ -20,8 +26,8 @@ RUN if [ "$REL" = "buster" -o "$REL" = "bullseye" -o "$REL" = "bookworm" ]; then
     echo 'APT::Install-Suggests false;' >> /etc/apt/apt.conf
 
 RUN apt-get update
-RUN apt-get -y install fio liburing-dev libgoogle-perftools-dev devscripts
-RUN apt-get -y build-dep qemu
+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
@@ -38,9 +44,9 @@ ADD src/client/qemu_driver.c /root/qemu_driver.c
 #    apt-get install -y vitastor-client vitastor-client-dev quilt
 
 RUN set -e; \
-    dpkg -i /root/packages/vitastor-$REL/vitastor-client_*.deb /root/packages/vitastor-$REL/vitastor-client-dev_*.deb; \
+    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; \
-    apt-get install -y quilt; \
+    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; \
@@ -54,7 +60,7 @@ RUN set -e; \
     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/^.*\((.*?)(~bpo[\d\+]*)?\).*$/$1/')+vitastor4; \
+    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; \

debian/rules

@@ -4,6 +4,14 @@ 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/fio_version >> debian/vitastor-fio.substvars
 	[ -f debian/qemu_version ] && (cat debian/qemu_version >> debian/vitastor-qemu.substvars) || true

debian/vitastor.Dockerfile

@@ -21,10 +21,11 @@ RUN set -e -x; \
     echo 'APT::Install-Recommends false;' >> /etc/apt/apt.conf; \
     echo 'APT::Install-Suggests false;' >> /etc/apt/apt.conf
 
-RUN apt-get update
-RUN apt-get -y install fio liburing-dev libgoogle-perftools-dev devscripts libjerasure-dev cmake libibverbs-dev libisal-dev libnl-3-dev libnl-genl-3-dev curl
-RUN apt-get -y build-dep fio
-RUN apt-get --download-only source fio
+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; \

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

@@ -13,7 +13,7 @@ Vitastor configuration consists of:
 - [Separate OSD settings](config/pool.en.md#osd-settings)
 - [Inode configuration](config/inode.en.md) i.e. image metadata like name, size and parent reference
 
-Configuration parameters can be set in 3 places:
+Configuration 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.

docs/config.ru.md

@@ -14,7 +14,7 @@
 - [Настроек инодов](config/inode.ru.md), т.е. метаданных образов, таких, как имя, размер и ссылки на
   родительский образ
 
-Параметры конфигурации могут задаваться в 3 местах:
+Параметры конфигурации могут задаваться в 4 местах:
 - Файле конфигурации (`/etc/vitastor/vitastor.conf` или по другому пути)
 - Ключе в etcd `/vitastor/config/global`. Большая часть параметров может
   задаваться там, кроме, естественно, самих параметров соединения с etcd,

docs/config/client.en.md

@@ -13,6 +13,7 @@ affect their interaction with the cluster.
 - [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)
@@ -23,6 +24,7 @@ affect their interaction with the cluster.
 - [nbd_max_devices](#nbd_max_devices)
 - [nbd_max_part](#nbd_max_part)
 - [osd_nearfull_ratio](#osd_nearfull_ratio)
+- [hostname](#hostname)
 
 ## client_iothread_count
 
@@ -70,6 +72,19 @@ and clients are not blocked and just get EIO error code instead.
 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
@@ -201,3 +216,12 @@ 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.
+
+## hostname
+
+- Type: string
+- Can be changed online: yes
+
+Clients use host name to find their distance to OSDs when [localized reads](pool.en.md#local_reads)
+are enabled. By default, standard [gethostname](https://man7.org/linux/man-pages/man2/gethostname.2.html)
+function is used to determine host name, but you can also override it with this parameter.

docs/config/client.ru.md

@@ -13,6 +13,7 @@
 - [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)
@@ -23,6 +24,7 @@
 - [nbd_max_devices](#nbd_max_devices)
 - [nbd_max_part](#nbd_max_part)
 - [osd_nearfull_ratio](#osd_nearfull_ratio)
+- [hostname](#hostname)
 
 ## client_iothread_count
 
@@ -72,6 +74,19 @@ RDMA и хотите повысить пиковую производитель
 Повторять запросы записи, завершившиеся с ошибками нехватки места, т.е.
 ожидать, пока на 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
 
 - Тип: целое число
@@ -205,3 +220,13 @@ RDMA и хотите повысить пиковую производитель
 заполненные на 100% OSD вообще не могут стартовать), так что вы сможете
 восстановить работу кластера после ошибок отсутствия свободного места
 без уничтожения и пересоздания OSD.
+
+## hostname
+
+- Тип: строка
+- Можно менять на лету: да
+
+Клиенты используют имя хоста для определения расстояния до OSD, когда включены
+[локальные чтения](pool.ru.md#local_reads). По умолчанию для определения имени
+хоста используется стандартная функция [gethostname](https://man7.org/linux/man-pages/man2/gethostname.2.html),
+но вы также можете задать имя хоста вручную данным параметром.

docs/config/layout-cluster.en.md

@@ -106,8 +106,8 @@ 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.yml#disable_journal_fsync) and
-[disable_meta_fsync](layout-osd.en.yml#disable_meta_fsync), setting it to
-"all" also requires enabling [disable_data_fsync](layout-osd.en.yml#disable_data_fsync).
+[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

@@ -112,6 +112,6 @@ HDD-дисках с внутренним SSD или "медиа" кэшем - н
 указано в спецификациях).
 
 Указание "all" или "small" в настройках / командной строке OSD требует
-включения [disable_journal_fsync](layout-osd.ru.yml#disable_journal_fsync) и
-[disable_meta_fsync](layout-osd.ru.yml#disable_meta_fsync), значение "all"
-также требует включения [disable_data_fsync](layout-osd.ru.yml#disable_data_fsync).
+включения [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

@@ -118,12 +118,13 @@ Physical block size of the journal device. Must be a multiple of
 - Type: boolean
 - Default: false
 
-Do not issue fsyncs to the data device, i.e. do not flush its cache.
-Safe ONLY if your data device has write-through cache. If you disable
-the cache yourself using `hdparm` or `scsi_disk/cache_type` then make sure
-that the cache disable command is run every time before starting Vitastor
-OSD, for example, in the systemd unit. See also `immediate_commit` option
-for the instructions to disable cache and how to benefit from it.
+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
 
@@ -171,8 +172,7 @@ 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 the only SSD that may fit into this category is
-Intel Optane (probably, not tested yet).
+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.

docs/config/layout-osd.ru.md

@@ -122,13 +122,14 @@ SSD-диске, иначе производительность пострада
 - Тип: булево (да/нет)
 - Значение по умолчанию: false
 
-Не отправлять fsync-и устройству данных, т.е. не сбрасывать его кэш.
+Не отправлять fsync-и устройству данных, т.е. не заставлять его сбрасывать кэш.
 Безопасно, ТОЛЬКО если ваше устройство данных имеет кэш со сквозной
-записью (write-through). Если вы отключаете кэш через `hdparm` или
-`scsi_disk/cache_type`, то удостоверьтесь, что команда отключения кэша
-выполняется перед каждым запуском Vitastor OSD, например, в systemd unit-е.
-Смотрите также опцию `immediate_commit` для инструкций по отключению кэша
-и о том, как из этого извлечь выгоду.
+записью (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
 
@@ -179,9 +180,8 @@ SSD и HDD диски используют 4 КБ физические сект
 
 Поэтому, на самом деле, может быть выгодно найти SSD, хорошо работающие с
 меньшими, 512-байтными, блоками и использовать 512-байтные disk_alignment,
-journal_block_size и meta_block_size. Однако единственные SSD, которые
-теоретически могут попасть в эту категорию - это Intel Optane (но и это
-пока не проверялось автором).
+journal_block_size и meta_block_size. Однако на данный момент такие SSD
+не известны...
 
 Клиентам не обязательно знать про disk_alignment, так что помещать значение
 этого параметра в etcd в /vitastor/config/global не нужно.

docs/config/monitor.en.md

@@ -24,6 +24,7 @@ These parameters only apply to Monitors.
 - [osd_out_time](#osd_out_time)
 - [placement_levels](#placement_levels)
 - [use_old_pg_combinator](#use_old_pg_combinator)
+- [osd_backfillfull_ratio](#osd_backfillfull_ratio)
 
 ## use_antietcd
 
@@ -73,13 +74,13 @@ Grafana dashboard suitable for this exporter is here: [Vitastor-Grafana-6+.json]
 - Type: integer
 - Default: 8060
 
-HTTP port for monitors to listen on (including metrics exporter)
+HTTP port for monitors to listen to (including metrics exporter)
 
 ## mon_http_ip
 
 - Type: string
 
-IP address for monitors to listen on (all addresses by default)
+IP address for monitors to listen to (all addresses by default)
 
 ## mon_https_cert
 
@@ -175,3 +176,18 @@ present in the configuration, then it is defined with the default priority
 
 Use the old PG combination generator which doesn't support [level_placement](pool.en.md#level_placement)
 and [raw_placement](pool.en.md#raw_placement) for pools which don't use this features.
+
+## osd_backfillfull_ratio
+
+- Type: number
+- Default: 0.99
+
+Monitors try to prevent OSDs becoming 100% full during rebalance or recovery by
+calculating how much space will be occupied on every OSD after all rebalance
+and recovery operations finish, and pausing rebalance and recovery if that
+amount of space exceeds OSD capacity multiplied by the value of this
+configuration parameter.
+
+Future used space is calculated by summing space used by all user data blocks
+(objects) in all PGs placed on a specific OSD, even if some of these objects
+currently reside on a different set of OSDs.

docs/config/monitor.ru.md

@@ -24,6 +24,7 @@
 - [osd_out_time](#osd_out_time)
 - [placement_levels](#placement_levels)
 - [use_old_pg_combinator](#use_old_pg_combinator)
+- [osd_backfillfull_ratio](#osd_backfillfull_ratio)
 
 ## use_antietcd
 
@@ -178,3 +179,19 @@ OSD перед обновлением агрегированной статис
 
 Использовать старый генератор комбинаций PG, не поддерживающий [level_placement](pool.ru.md#level_placement)
 и [raw_placement](pool.ru.md#raw_placement) для пулов, которые не используют данные функции.
+
+## osd_backfillfull_ratio
+
+- Тип: число
+- Значение по умолчанию: 0.99
+
+Мониторы стараются предотвратить 100% заполнение OSD в процессе ребаланса
+или восстановления, рассчитывая, сколько места будет занято на каждом OSD после
+завершения всех операций ребаланса и восстановления, и приостанавливая
+ребаланс и восстановление, если рассчитанный объём превышает ёмкость OSD,
+умноженную на значение данного параметра.
+
+Будущее занятое место рассчитывается сложением места, занятого всеми
+пользовательскими блоками данных (объектами) во всех PG, расположенных
+на конкретном OSD, даже если часть этих объектов в данный момент находится
+на другом наборе OSD.

docs/config/network.en.md

@@ -9,9 +9,11 @@
 These parameters apply to clients and OSDs and affect network connection logic
 between clients, OSDs and etcd.
 
-- [tcp_header_buffer_size](#tcp_header_buffer_size)
-- [use_sync_send_recv](#use_sync_send_recv)
+- [osd_network](#osd_network)
+- [osd_cluster_network](#osd_cluster_network)
 - [use_rdma](#use_rdma)
+- [use_rdmacm](#use_rdmacm)
+- [disable_tcp](#disable_tcp)
 - [rdma_device](#rdma_device)
 - [rdma_port_num](#rdma_port_num)
 - [rdma_gid_index](#rdma_gid_index)
@@ -30,49 +32,80 @@ between clients, OSDs and etcd.
 - [etcd_slow_timeout](#etcd_slow_timeout)
 - [etcd_keepalive_timeout](#etcd_keepalive_timeout)
 - [etcd_ws_keepalive_interval](#etcd_ws_keepalive_interval)
+- [etcd_min_reload_interval](#etcd_min_reload_interval)
+- [tcp_header_buffer_size](#tcp_header_buffer_size)
+- [min_zerocopy_send_size](#min_zerocopy_send_size)
+- [use_sync_send_recv](#use_sync_send_recv)
 
-## tcp_header_buffer_size
+## osd_network
 
-- Type: integer
-- Default: 65536
+- Type: string or array of strings
 
-Size of the buffer used to read data using an additional copy. Vitastor
-packet headers are 128 bytes, payload is always at least 4 KB, so it is
-usually beneficial to try to read multiple packets at once even though
-it requires to copy the data an additional time. The rest of each packet
-is received without an additional copy. You can try to play with this
-parameter and see how it affects random iops and linear bandwidth if you
-want.
+Network mask of public OSD network(s) (IPv4 or IPv6). Each OSD listens to all
+addresses of UP + RUNNING interfaces matching one of these networks, on the
+same port. Port is auto-selected except if [bind_port](osd.en.md#bind_port) is
+explicitly specified. Bind address(es) may also be overridden manually by
+specifying [bind_address](osd.en.md#bind_address). If OSD networks are not specified
+at all, OSD just listens to a wildcard address (0.0.0.0).
 
-## use_sync_send_recv
+## osd_cluster_network
 
-- Type: boolean
-- Default: false
+- Type: string or array of strings
 
-If true, synchronous send/recv syscalls are used instead of io_uring for
-socket communication. Useless for OSDs because they require io_uring anyway,
-but may be required for clients with old kernel versions.
+Network mask of separate network(s) (IPv4 or IPv6) to use for OSD
+cluster connections. I.e. OSDs will always attempt to use these networks
+to connect to other OSDs, while clients will attempt to use networks from
+[osd_network](#osd_network).
 
 ## use_rdma
 
 - Type: boolean
 - Default: true
 
-Try to use RDMA for communication if it's available. Disable if you don't
-want Vitastor to use RDMA. TCP-only clients can also talk to an RDMA-enabled
-cluster, so disabling RDMA may be needed if clients have RDMA devices,
-but they are not connected to the cluster.
+Try to use RDMA through libibverbs for communication if it's available.
+Disable if you don't want Vitastor to use RDMA. TCP-only clients can also
+talk to an RDMA-enabled cluster, so disabling RDMA may be needed if clients
+have RDMA devices, but they are not connected to the cluster.
+
+`use_rdma` works with RoCEv1/RoCEv2 networks, but not with iWARP and,
+maybe, with some Infiniband configurations which require RDMA-CM.
+Consider `use_rdmacm` for such networks.
+
+## use_rdmacm
+
+- Type: boolean
+- Default: true
+
+Use an alternative implementation of RDMA through RDMA-CM (Connection
+Manager). Works with all RDMA networks: Infiniband, iWARP and
+RoCEv1/RoCEv2, and even allows to disable TCP and run only with RDMA.
+OSDs always use random port numbers for RDMA-CM listeners, different
+from their TCP ports. `use_rdma` is automatically disabled when
+`use_rdmacm` is enabled.
+
+## disable_tcp
+
+- Type: boolean
+- Default: true
+
+Fully disable TCP and only use RDMA-CM for OSD communication.
 
 ## rdma_device
 
 - Type: string
 
 RDMA device name to use for Vitastor OSD communications (for example,
-"rocep5s0f0"). Now Vitastor supports all adapters, even ones without
-ODP support, like Mellanox ConnectX-3 and non-Mellanox cards.
+"rocep5s0f0"). If not specified, Vitastor will try to find an RoCE
+device matching [osd_network](osd.en.md#osd_network), preferring RoCEv2,
+or choose the first available RDMA device if no RoCE devices are
+found or if `osd_network` is not specified. Auto-selection is also
+unsupported with old libibverbs < v32, like in Debian 10 Buster or
+CentOS 7.
 
-Versions up to Vitastor 1.2.0 required ODP which is only present in
-Mellanox ConnectX >= 4. See also [rdma_odp](#rdma_odp).
+Vitastor supports all adapters, even ones without ODP support, like
+Mellanox ConnectX-3 and non-Mellanox cards. Versions up to Vitastor
+1.2.0 required ODP which is only present in Mellanox ConnectX >= 4.
+See also [rdma_odp](#rdma_odp).
 
 Run `ibv_devinfo -v` as root to list available RDMA devices and their
 features.
@@ -86,32 +119,36 @@ PFC (Priority Flow Control) and ECN (Explicit Congestion Notification).
 ## rdma_port_num
 
 - Type: integer
-- Default: 1
 
 RDMA device port number to use. Only for devices that have more than 1 port.
 See `phys_port_cnt` in `ibv_devinfo -v` output to determine how many ports
 your device has.
 
+Not relevant for RDMA-CM (use_rdmacm).
+
 ## rdma_gid_index
 
 - Type: integer
-- Default: 0
 
 Global address identifier index of the RDMA device to use. Different GID
 indexes may correspond to different protocols like RoCEv1, RoCEv2 and iWARP.
 Search for "GID" in `ibv_devinfo -v` output to determine which GID index
 you need.
 
-**IMPORTANT:** If you want to use RoCEv2 (as recommended) then the correct
-rdma_gid_index is usually 1 (IPv6) or 3 (IPv4).
+If not specified, Vitastor will try to auto-select a RoCEv2 IPv4 GID, then
+RoCEv2 IPv6 GID, then RoCEv1 IPv4 GID, then RoCEv1 IPv6 GID, then IB GID.
+GID auto-selection is unsupported with libibverbs < v32.
+
+A correct rdma_gid_index for RoCEv2 is usually 1 (IPv6) or 3 (IPv4).
+
+Not relevant for RDMA-CM (use_rdmacm).
 
 ## rdma_mtu
 
 - Type: integer
-- Default: 4096
 
-RDMA Path MTU to use. Must be 1024, 2048 or 4096. There is usually no
-sense to change it from the default 4096.
+RDMA Path MTU to use. Must be 1024, 2048 or 4096. Default is to use the
+RDMA device's MTU.
 
 ## rdma_max_sge
 
@@ -253,3 +290,63 @@ etcd_report_interval to guarantee that keepalive actually works.
 
 etcd websocket ping interval required to keep the connection alive and
 detect disconnections quickly.
+
+## etcd_min_reload_interval
+
+- Type: milliseconds
+- Default: 1000
+- Can be changed online: yes
+
+Minimum interval for full etcd state reload. Introduced to prevent
+excessive load on etcd during outages when etcd can't keep up with event
+streams and cancels them.
+
+## tcp_header_buffer_size
+
+- Type: integer
+- Default: 65536
+
+Size of the buffer used to read data using an additional copy. Vitastor
+packet headers are 128 bytes, payload is always at least 4 KB, so it is
+usually beneficial to try to read multiple packets at once even though
+it requires to copy the data an additional time. The rest of each packet
+is received without an additional copy. You can try to play with this
+parameter and see how it affects random iops and linear bandwidth if you
+want.
+
+## min_zerocopy_send_size
+
+- Type: integer
+- Default: 32768
+
+OSDs and clients will attempt to use io_uring-based zero-copy TCP send
+for buffers larger than this number of bytes. Zero-copy send with io_uring is
+supported since Linux kernel version 6.1. Support is auto-detected and disabled
+automatically when not available. It can also be disabled explicitly by setting
+this parameter to a negative value.
+
+⚠️ Warning! Zero-copy send performance may vary greatly from CPU to CPU and from
+one kernel version to another. Generally, it tends to only make benefit with larger
+messages. With smaller messages (say, 4 KB), it may actually be slower. 32 KB is
+enough for almost all CPUs, but even smaller values are optimal for some of them.
+For example, 4 KB is OK for EPYC Milan/Genoa and 12 KB is OK for Xeon Ice Lake
+(but verify it yourself please).
+
+Verification instructions:
+1. Add `iommu=pt` into your Linux kernel command line and reboot.
+2. Upgrade your kernel. For example, it's very important to use 6.11+ with recent AMD EPYCs.
+3. Run some tests with the [send-zerocopy liburing example](https://github.com/axboe/liburing/blob/master/examples/send-zerocopy.c)
+   to find the minimal message size for which zero-copy is optimal.
+   Use `./send-zerocopy tcp -4 -R` at the server side and
+   `time ./send-zerocopy tcp -4 -b 0 -s BUFFER_SIZE -D SERVER_IP` at the client side with
+   `-z 0` (no zero-copy) and `-z 1` (zero-copy), and compare MB/s and used CPU time
+   (user+system).
+
+## use_sync_send_recv
+
+- Type: boolean
+- Default: false
+
+If true, synchronous send/recv syscalls are used instead of io_uring for
+socket communication. Useless for OSDs because they require io_uring anyway,
+but may be required for clients with old kernel versions.

docs/config/network.ru.md

@@ -9,9 +9,11 @@
 Данные параметры используются клиентами и OSD и влияют на логику сетевого
 взаимодействия между клиентами, OSD, а также etcd.
 
-- [tcp_header_buffer_size](#tcp_header_buffer_size)
-- [use_sync_send_recv](#use_sync_send_recv)
+- [osd_network](#osd_network)
+- [osd_cluster_network](#osd_cluster_network)
 - [use_rdma](#use_rdma)
+- [use_rdmacm](#use_rdmacm)
+- [disable_tcp](#disable_tcp)
 - [rdma_device](#rdma_device)
 - [rdma_port_num](#rdma_port_num)
 - [rdma_gid_index](#rdma_gid_index)
@@ -30,53 +32,80 @@
 - [etcd_slow_timeout](#etcd_slow_timeout)
 - [etcd_keepalive_timeout](#etcd_keepalive_timeout)
 - [etcd_ws_keepalive_interval](#etcd_ws_keepalive_interval)
+- [etcd_min_reload_interval](#etcd_min_reload_interval)
+- [tcp_header_buffer_size](#tcp_header_buffer_size)
+- [min_zerocopy_send_size](#min_zerocopy_send_size)
+- [use_sync_send_recv](#use_sync_send_recv)
 
-## tcp_header_buffer_size
+## osd_network
 
-- Тип: целое число
-- Значение по умолчанию: 65536
+- Тип: строка или массив строк
 
-Размер буфера для чтения данных с дополнительным копированием. Пакеты
-Vitastor содержат 128-байтные заголовки, за которыми следуют данные размером
-от 4 КБ и для мелких операций ввода-вывода обычно выгодно за 1 вызов читать
-сразу несколько пакетов, даже не смотря на то, что это требует лишний раз
-скопировать данные. Часть каждого пакета за пределами значения данного
-параметра читается без дополнительного копирования. Вы можете попробовать
-поменять этот параметр и посмотреть, как он влияет на производительность
-случайного и линейного доступа.
+Маски подсетей (IPv4 или IPv6) публичной сети или сетей OSD. Каждый OSD слушает
+один и тот же порт на всех адресах поднятых (UP + RUNNING) сетевых интерфейсов,
+соответствующих одной из указанных сетей. Порт выбирается автоматически, если
+только [bind_port](osd.ru.md#bind_port) не задан явно. Адреса для подключений можно
+также переопределить явно, задав [bind_address](osd.ru.md#bind_address). Если сети OSD
+не заданы вообще, OSD слушает все адреса (0.0.0.0).
 
-## use_sync_send_recv
+## osd_cluster_network
 
-- Тип: булево (да/нет)
-- Значение по умолчанию: false
+- Тип: строка или массив строк
 
-Если установлено в истину, то вместо io_uring для передачи данных по сети
-будут использоваться обычные синхронные системные вызовы send/recv. Для OSD
-это бессмысленно, так как OSD в любом случае нуждается в io_uring, но, в
-принципе, это может применяться для клиентов со старыми версиями ядра.
+Маски подсетей (IPv4 или IPv6) отдельной кластерной сети или сетей OSD.
+То есть, OSD будут всегда стараться использовать эти сети для соединений
+с другими OSD, а клиенты будут стараться использовать сети из [osd_network](#osd_network).
 
 ## use_rdma
 
 - Тип: булево (да/нет)
 - Значение по умолчанию: true
 
-Пытаться использовать RDMA для связи при наличии доступных устройств.
-Отключите, если вы не хотите, чтобы Vitastor использовал RDMA.
-TCP-клиенты также могут работать с RDMA-кластером, так что отключать
-RDMA может быть нужно только если у клиентов есть RDMA-устройства,
-но они не имеют соединения с кластером Vitastor.
+Попробовать использовать RDMA через libibverbs для связи при наличии
+доступных устройств. Отключите, если вы не хотите, чтобы Vitastor
+использовал RDMA. TCP-клиенты также могут работать с RDMA-кластером,
+так что отключать RDMA может быть нужно, только если у клиентов есть
+RDMA-устройства, но они не имеют соединения с кластером Vitastor.
+
+`use_rdma` работает с RoCEv1/RoCEv2 сетями, но не работает с iWARP и
+может не работать с частью конфигураций Infiniband, требующих RDMA-CM.
+Рассмотрите включение `use_rdmacm` для таких сетей.
+
+## use_rdmacm
+
+- Тип: булево (да/нет)
+- Значение по умолчанию: true
+
+Использовать альтернативную реализацию RDMA на основе RDMA-CM (Connection
+Manager). Работает со всеми типами RDMA-сетей: Infiniband, iWARP и
+RoCEv1/RoCEv2, и даже позволяет полностью отключить TCP и работать
+только на RDMA. OSD используют случайные номера портов для ожидания
+соединений через RDMA-CM, отличающиеся от их TCP-портов. Также при
+включении `use_rdmacm` автоматически отключается опция `use_rdma`.
+
+## disable_tcp
+
+- Тип: булево (да/нет)
+- Значение по умолчанию: true
+
+Полностью отключить TCP и использовать только RDMA-CM для соединений с OSD.
 
 ## rdma_device
 
 - Тип: строка
 
 Название RDMA-устройства для связи с Vitastor OSD (например, "rocep5s0f0").
-Сейчас Vitastor поддерживает все модели адаптеров, включая те, у которых
-нет поддержки ODP, то есть вы можете использовать RDMA с ConnectX-3 и
-картами производства не Mellanox.
+Если не указано, Vitastor попробует найти RoCE-устройство, соответствующее
+[osd_network](osd.en.md#osd_network), предпочитая RoCEv2, или выбрать первое
+попавшееся RDMA-устройство, если RoCE-устройств нет или если сеть `osd_network`
+не задана. Также автовыбор не поддерживается со старыми версиями библиотеки
+libibverbs < v32, например в Debian 10 Buster или CentOS 7.
 
-Версии Vitastor до 1.2.0 включительно требовали ODP, который есть только
-на Mellanox ConnectX 4 и более новых. См. также [rdma_odp](#rdma_odp).
+Vitastor поддерживает все модели адаптеров, включая те, у которых
+нет поддержки ODP, то есть вы можете использовать RDMA с ConnectX-3 и
+картами производства не Mellanox. Версии Vitastor до 1.2.0 включительно
+требовали ODP, который есть только на Mellanox ConnectX 4 и более новых.
+См. также [rdma_odp](#rdma_odp).
 
 Запустите `ibv_devinfo -v` от имени суперпользователя, чтобы посмотреть
 список доступных RDMA-устройств, их параметры и возможности.
@@ -91,33 +120,38 @@ Control) и ECN (Explicit Congestion Notification).
 ## rdma_port_num
 
 - Тип: целое число
-- Значение по умолчанию: 1
 
 Номер порта RDMA-устройства, который следует использовать. Имеет смысл
 только для устройств, у которых более 1 порта. Чтобы узнать, сколько портов
 у вашего адаптера, посмотрите `phys_port_cnt` в выводе команды
 `ibv_devinfo -v`.
 
+Опция неприменима к RDMA-CM (use_rdmacm).
+
 ## rdma_gid_index
 
 - Тип: целое число
-- Значение по умолчанию: 0
 
 Номер глобального идентификатора адреса RDMA-устройства, который следует
 использовать. Разным gid_index могут соответствовать разные протоколы связи:
 RoCEv1, RoCEv2, iWARP. Чтобы понять, какой нужен вам - смотрите строчки со
 словом "GID" в выводе команды `ibv_devinfo -v`.
 
-**ВАЖНО:** Если вы хотите использовать RoCEv2 (как мы и рекомендуем), то
-правильный rdma_gid_index, как правило, 1 (IPv6) или 3 (IPv4).
+Если не указан, Vitastor попробует автоматически выбрать сначала GID,
+соответствующий RoCEv2 IPv4, потом RoCEv2 IPv6, потом RoCEv1 IPv4, потом
+RoCEv1 IPv6, потом IB. Авто-выбор GID не поддерживается со старыми версиями
+libibverbs < v32.
+
+Правильный rdma_gid_index для RoCEv2, как правило, 1 (IPv6) или 3 (IPv4).
+
+Опция неприменима к RDMA-CM (use_rdmacm).
 
 ## rdma_mtu
 
 - Тип: целое число
-- Значение по умолчанию: 4096
 
 Максимальная единица передачи (Path MTU) для RDMA. Должно быть равно 1024,
-2048 или 4096. Обычно нет смысла менять значение по умолчанию, равное 4096.
+2048 или 4096. По умолчанию используется значение MTU RDMA-устройства.
 
 ## rdma_max_sge
 
@@ -263,3 +297,65 @@ etcd_report_interval, чтобы keepalive гарантированно рабо
 - Можно менять на лету: да
 
 Интервал проверки живости вебсокет-подключений к etcd.
+
+## etcd_min_reload_interval
+
+- Тип: миллисекунды
+- Значение по умолчанию: 1000
+- Можно менять на лету: да
+
+Минимальный интервал полной перезагрузки состояния из etcd. Добавлено для
+предотвращения избыточной нагрузки на etcd во время отказов, когда etcd не
+успевает рассылать потоки событий и отменяет их.
+
+## tcp_header_buffer_size
+
+- Тип: целое число
+- Значение по умолчанию: 65536
+
+Размер буфера для чтения данных с дополнительным копированием. Пакеты
+Vitastor содержат 128-байтные заголовки, за которыми следуют данные размером
+от 4 КБ и для мелких операций ввода-вывода обычно выгодно за 1 вызов читать
+сразу несколько пакетов, даже не смотря на то, что это требует лишний раз
+скопировать данные. Часть каждого пакета за пределами значения данного
+параметра читается без дополнительного копирования. Вы можете попробовать
+поменять этот параметр и посмотреть, как он влияет на производительность
+случайного и линейного доступа.
+
+## min_zerocopy_send_size
+
+- Тип: целое число
+- Значение по умолчанию: 32768
+
+OSD и клиенты будут пробовать использовать TCP-отправку без копирования (zero-copy) на
+основе io_uring для буферов, больших, чем это число байт. Отправка без копирования
+поддерживается в io_uring, начиная с версии ядра Linux 6.1. Наличие поддержки
+проверяется автоматически и zero-copy отключается, когда поддержки нет. Также
+её можно отключить явно, установив данный параметр в отрицательное значение.
+
+⚠️ Внимание! Производительность данной функции может сильно отличаться на разных
+процессорах и на разных версиях ядра Linux. В целом, zero-copy обычно быстрее с
+большими сообщениями, а с мелкими (например, 4 КБ) zero-copy может быть даже
+медленнее. 32 КБ достаточно почти для всех процессоров, но для каких-то можно
+использовать даже меньшие значения. Например, для EPYC Milan/Genoa подходит 4 КБ,
+а для Xeon Ice Lake - 12 КБ (но, пожалуйста, перепроверьте это сами).
+
+Инструкция по проверке:
+1. Добавьте `iommu=pt` в командную строку загрузки вашего ядра Linux и перезагрузитесь.
+2. Обновите ядро. Например, для AMD EPYC очень важно использовать версию 6.11+.
+3. Позапускайте тесты с помощью [send-zerocopy из примеров liburing](https://github.com/axboe/liburing/blob/master/examples/send-zerocopy.c),
+   чтобы найти минимальный размер сообщения, для которого zero-copy отправка оптимальна.
+   Запускайте `./send-zerocopy tcp -4 -R` на стороне сервера и
+   `time ./send-zerocopy tcp -4 -b 0 -s РАЗМЕР_БУФЕРА -D АДРЕС_СЕРВЕРА` на стороне клиента
+   с опцией `-z 0` (обычная отправка) и `-z 1` (отправка без копирования), и сравнивайте
+   скорость в МБ/с и занятое процессорное время (user+system).
+
+## use_sync_send_recv
+
+- Тип: булево (да/нет)
+- Значение по умолчанию: false
+
+Если установлено в истину, то вместо io_uring для передачи данных по сети
+будут использоваться обычные синхронные системные вызовы send/recv. Для OSD
+это бессмысленно, так как OSD в любом случае нуждается в io_uring, но, в
+принципе, это может применяться для клиентов со старыми версиями ядра.

docs/config/osd.en.md

@@ -7,16 +7,15 @@
 # Runtime OSD Parameters
 
 These parameters only apply to OSDs, are not fixed at the moment of OSD drive
-initialization and can be changed - either with an OSD restart or, for some of
-them, even without restarting by updating configuration in etcd.
+initialization and can be changed - in /etc/vitastor/vitastor.conf or [vitastor-disk update-sb](../usage/disk.en.md#update-sb)
+with an OSD restart or, for some of them, even without restarting by updating configuration in etcd.
 
+- [bind_address](#bind_address)
+- [bind_port](#bind_port)
 - [osd_iothread_count](#osd_iothread_count)
 - [etcd_report_interval](#etcd_report_interval)
 - [etcd_stats_interval](#etcd_stats_interval)
 - [run_primary](#run_primary)
-- [osd_network](#osd_network)
-- [bind_address](#bind_address)
-- [bind_port](#bind_port)
 - [autosync_interval](#autosync_interval)
 - [autosync_writes](#autosync_writes)
 - [recovery_queue_depth](#recovery_queue_depth)
@@ -61,6 +60,28 @@ them, even without restarting by updating configuration in etcd.
 - [recovery_tune_agg_interval](#recovery_tune_agg_interval)
 - [recovery_tune_sleep_min_us](#recovery_tune_sleep_min_us)
 - [recovery_tune_sleep_cutoff_us](#recovery_tune_sleep_cutoff_us)
+- [discard_on_start](#discard_on_start)
+- [min_discard_size](#min_discard_size)
+- [allow_net_split](#allow_net_split)
+- [enable_pg_locks](#enable_pg_locks)
+- [pg_lock_retry_interval_ms](#pg_lock_retry_interval_ms)
+
+## bind_address
+
+- Type: string or array of strings
+
+Instead of the network masks ([osd_network](network.en.md#osd_network) and
+[osd_cluster_network](network.en.md#osd_cluster_network)), you can also set
+OSD listen addresses explicitly using this parameter. May be useful if you
+want to start OSDs on interfaces that are not UP + RUNNING.
+
+## bind_port
+
+- Type: integer
+
+By default, OSDs pick random ports to use for incoming connections
+automatically. With this option you can set a specific port for a specific
+OSD by hand.
 
 ## osd_iothread_count
 
@@ -104,34 +125,6 @@ debugging purposes. It's possible to implement additional feature for the
 monitor which may allow to separate primary and secondary OSDs, but it's
 unclear why anyone could need it, so it's not implemented.
 
-## osd_network
-
-- Type: string or array of strings
-
-Network mask of the network (IPv4 or IPv6) to use for OSDs. Note that
-although it's possible to specify multiple networks here, this does not
-mean that OSDs will create multiple listening sockets - they'll only
-pick the first matching address of an UP + RUNNING interface. Separate
-networks for cluster and client connections are also not implemented, but
-they are mostly useless anyway, so it's not a big deal.
-
-## bind_address
-
-- Type: string
-- Default: 0.0.0.0
-
-Instead of the network mask, you can also set OSD listen address explicitly
-using this parameter. May be useful if you want to start OSDs on interfaces
-that are not UP + RUNNING.
-
-## bind_port
-
-- Type: integer
-
-By default, OSDs pick random ports to use for incoming connections
-automatically. With this option you can set a specific port for a specific
-OSD by hand.
-
 ## autosync_interval
 
 - Type: seconds
@@ -316,7 +309,7 @@ for hot data and slower disks - HDDs and maybe SATA SSDs - but will slightly
 decrease write performance for fast disks because page cache is an overhead
 itself.
 
-Choose "directsync" to use [immediate_commit](layout-cluster.ru.md#immediate_commit)
+Choose "directsync" to use [immediate_commit](layout-cluster.en.md#immediate_commit)
 (which requires disable_data_fsync) with drives having write-back cache
 which can't be turned off, for example, Intel Optane. Also note that *some*
 desktop SSDs (for example, HP EX950) may ignore O_SYNC thus making
@@ -629,3 +622,47 @@ are changed to 0.
 
 Maximum possible value for auto-tuned recovery_sleep_us. Higher values
 are treated as outliers and ignored in aggregation.
+
+## discard_on_start
+
+- Type: boolean
+
+Discard (SSD TRIM) unused data device blocks on every OSD startup.
+
+## min_discard_size
+
+- Type: integer
+- Default: 1048576
+
+Minimum consecutive block size to TRIM it.
+
+## allow_net_split
+
+- Type: boolean
+- Default: false
+
+Allow "safe" cases of network splits/partitions - allow to start PGs without
+connections to some OSDs currently registered as alive in etcd, if the number
+of actually connected PG OSDs is at least pg_minsize. That is, allow some OSDs to lose
+connectivity with some other OSDs as long as it doesn't break pg_minsize guarantees.
+The downside is that it increases the probability of writing data into just pg_minsize
+OSDs during failover which can lead to PGs becoming incomplete after additional outages.
+
+The old behaviour in versions up to 2.0.0 was equal to enabled allow_net_split.
+
+## enable_pg_locks
+
+- Type: boolean
+
+Vitastor 2.2.0 introduces a new layer of split-brain prevention mechanism in
+addition to etcd: PG locks. They prevent split-brain even in abnormal theoretical cases
+when etcd is extremely laggy. As a new feature, by default, PG locks are only enabled
+for pools where they're required - pools with [localized reads](pool.en.md#local_reads).
+Use this parameter to enable or disable this function for all pools.
+
+## pg_lock_retry_interval_ms
+
+- Type: milliseconds
+- Default: 100
+
+Retry interval for failed PG lock attempts.

docs/config/osd.ru.md

@@ -8,16 +8,15 @@
 
 Данные параметры используются только OSD, но, в отличие от дисковых параметров,
 не фиксируются в момент инициализации дисков OSD и могут быть изменены в любой
-момент с помощью перезапуска OSD, а некоторые и без перезапуска, с помощью
-изменения конфигурации в etcd.
+момент с перезапуском OSD в /etc/vitastor/vitastor.conf или [vitastor-disk update-sb](../usage/disk.ru.md#update-sb),
+а некоторые и без перезапуска, с помощью изменения конфигурации в etcd.
 
+- [bind_address](#bind_address)
+- [bind_port](#bind_port)
 - [osd_iothread_count](#osd_iothread_count)
 - [etcd_report_interval](#etcd_report_interval)
 - [etcd_stats_interval](#etcd_stats_interval)
 - [run_primary](#run_primary)
-- [osd_network](#osd_network)
-- [bind_address](#bind_address)
-- [bind_port](#bind_port)
 - [autosync_interval](#autosync_interval)
 - [autosync_writes](#autosync_writes)
 - [recovery_queue_depth](#recovery_queue_depth)
@@ -62,6 +61,28 @@
 - [recovery_tune_agg_interval](#recovery_tune_agg_interval)
 - [recovery_tune_sleep_min_us](#recovery_tune_sleep_min_us)
 - [recovery_tune_sleep_cutoff_us](#recovery_tune_sleep_cutoff_us)
+- [discard_on_start](#discard_on_start)
+- [min_discard_size](#min_discard_size)
+- [allow_net_split](#allow_net_split)
+- [enable_pg_locks](#enable_pg_locks)
+- [pg_lock_retry_interval_ms](#pg_lock_retry_interval_ms)
+
+## bind_address
+
+- Тип: строка или массив строк
+
+Вместо использования масок подсети ([osd_network](network.ru.md#osd_network) и
+[osd_cluster_network](network.ru.md#osd_cluster_network)), вы также можете явно
+задать адрес(а), на которых будут ожидать соединений OSD, с помощью данного
+параметра. Это может быть полезно, например, чтобы запускать OSD на неподнятых
+интерфейсах (не UP + RUNNING).
+
+## bind_port
+
+- Тип: целое число
+
+По умолчанию OSD сами выбирают случайные порты для входящих подключений.
+С помощью данной опции вы можете задать порт для отдельного OSD вручную.
 
 ## osd_iothread_count
 
@@ -107,34 +128,6 @@ max_etcd_attempts * etcd_quick_timeout.
 первичные OSD от вторичных, но пока не понятно, зачем это может кому-то
 понадобиться, поэтому это не реализовано.
 
-## osd_network
-
-- Тип: строка или массив строк
-
-Маска подсети (IPv4 или IPv6) для использования для соединений с OSD.
-Имейте в виду, что хотя сейчас и можно передать в этот параметр несколько
-подсетей, это не означает, что OSD будут создавать несколько слушающих
-сокетов - они лишь будут выбирать адрес первого поднятого (состояние UP +
-RUNNING), подходящий под заданную маску. Также не реализовано разделение
-кластерной и публичной сетей OSD. Правда, от него обычно всё равно довольно
-мало толку, так что особенной проблемы в этом нет.
-
-## bind_address
-
-- Тип: строка
-- Значение по умолчанию: 0.0.0.0
-
-Этим параметром можно явным образом задать адрес, на котором будет ожидать
-соединений OSD (вместо использования маски подсети). Может быть полезно,
-например, чтобы запускать OSD на неподнятых интерфейсах (не UP + RUNNING).
-
-## bind_port
-
-- Тип: целое число
-
-По умолчанию OSD сами выбирают случайные порты для входящих подключений.
-С помощью данной опции вы можете задать порт для отдельного OSD вручную.
-
 ## autosync_interval
 
 - Тип: секунды
@@ -660,3 +653,49 @@ EC (кодов коррекции ошибок) с более, чем 1 диск
 Максимальное возможное значение авто-подстроенного recovery_sleep_us.
 Большие значения считаются случайными выбросами и игнорируются в
 усреднении.
+
+## discard_on_start
+
+- Тип: булево (да/нет)
+
+Освобождать (SSD TRIM) неиспользуемые блоки диска данных при каждом запуске OSD.
+
+## min_discard_size
+
+- Тип: целое число
+- Значение по умолчанию: 1048576
+
+Минимальный размер последовательного блока данных, чтобы освобождать его через TRIM.
+
+## allow_net_split
+
+- Тип: булево (да/нет)
+- Значение по умолчанию: false
+
+Разрешить "безопасные" случаи разделений сети - разрешить активировать PG без
+соединений к некоторым OSD, помеченным активными в etcd, если общее число активных
+OSD в PG составляет как минимум pg_minsize. То есть, разрешать некоторым OSD терять
+соединения с некоторыми другими OSD, если это не нарушает гарантий pg_minsize.
+Минус такого разрешения в том, что оно повышает вероятность записи данных ровно в
+pg_minsize OSD во время переключений, что может потом привести к тому, что PG станут
+неполными (incomplete), если упадут ещё какие-то OSD.
+
+Старое поведение в версиях до 2.0.0 было идентично включённому allow_net_split.
+
+## enable_pg_locks
+
+- Тип: булево (да/нет)
+
+В Vitastor 2.2.0 появился новый слой защиты от сплитбрейна в дополнение к etcd -
+блокировки PG. Они гарантируют порядок даже в теоретических ненормальных случаях,
+когда etcd очень сильно тормозит. Так как функция новая, по умолчанию она включается
+только для пулов, в которых она необходима - а именно, в пулах с включёнными
+[локальными чтениями](pool.ru.md#local_reads). Ну а с помощью данного параметра
+можно включить блокировки PG для всех пулов.
+
+## pg_lock_retry_interval_ms
+
+- Тип: миллисекунды
+- Значение по умолчанию: 100
+
+Интервал повтора неудачных попыток блокировки PG.

docs/config/pool.en.md

@@ -34,6 +34,7 @@ Parameters:
 - [failure_domain](#failure_domain)
 - [level_placement](#level_placement)
 - [raw_placement](#raw_placement)
+- [local_reads](#local_reads)
 - [max_osd_combinations](#max_osd_combinations)
 - [block_size](#block_size)
 - [bitmap_granularity](#bitmap_granularity)
@@ -43,7 +44,7 @@ Parameters:
 - [osd_tags](#osd_tags)
 - [primary_affinity_tags](#primary_affinity_tags)
 - [scrub_interval](#scrub_interval)
-- [used_for_fs](#used_for_fs)
+- [used_for_app](#used_for_app)
 
 Examples:
 
@@ -55,7 +56,7 @@ Examples:
 OSD placement tree is set in a separate etcd key `/vitastor/config/node_placement`
 in the following JSON format:
 
-`
+```
 {
   "<node name or OSD number>": {
     "level": "<level>",
@@ -63,7 +64,7 @@ in the following JSON format:
   },
   ...
 }
-`
+```
 
 Here, if a node name is a number then it is assumed to refer to an OSD.
 Level of the OSD is always "osd" and cannot be overriden. You may only
@@ -133,8 +134,8 @@ Pool name.
 ## scheme
 
 - Type: string
-- Required
 - One of: "replicated", "xor", "ec" or "jerasure"
+- Required
 
 Redundancy scheme used for data in this pool. "jerasure" is an alias for "ec",
 both use Reed-Solomon-Vandermonde codes based on ISA-L or jerasure libraries.
@@ -189,6 +190,9 @@ So, pg_minsize regulates the number of failures that a pool can tolerate
 without temporary downtime for [osd_out_time](monitor.en.md#osd_out_time),
 but at a cost of slightly reduced storage reliability.
 
+See also [allow_net_split](osd.en.md#allow_net_split) and
+[PG state descriptions](../usage/admin.en.md#pg-states).
+
 FIXME: pg_minsize behaviour may be changed in the future to only make PGs
 read-only instead of deactivating them.
 
@@ -286,6 +290,30 @@ Examples:
 - EC 4+2 in 3 DC: `any, dc=1 host!=1, dc!=1, dc=3 host!=3, dc!=(1,3), dc=5 host!=5`
 - 1 replica in fixed DC + 2 in random DCs: `dc?=meow, dc!=1, dc!=(1,2)`
 
+## local_reads
+
+- Type: string
+- One of: "primary", "nearest" or "random"
+- Default: primary
+
+By default, Vitastor serves all read and write requests from the primary OSD of each PG.
+But it can also serve read requests for replicated pools from secondary OSDs in clean PGs
+(active or active+left_on_dead) which may be useful if you have OSDs with different network
+latency to the client - for example, if you have a cross-datacenter setup.
+
+If you set this parameter to "nearest", clients will try to read from the nearest OSD
+in the [Placement Tree](#placement-tree), i.e. from an OSD from the same host or datacenter.
+Distance to different OSDs will be calculated based on client hostname, determined
+automatically or set manually in the [hostname](client.en.md#hostname) parameter.
+
+If you set this parameter to "random", clients will try to distribute read requests over
+all available secondary OSDs. This mode is mainly useful for tests, but, probably, not
+really required in production setups.
+
+[PG locks](osd.en.md#enable_pg_locks) are required for local reads to function. However,
+PG locks are enabled automatically by default for pools with enabled local reads, so you
+don't have to enable them explicitly.
+
 ## max_osd_combinations
 
 - Type: integer
@@ -321,7 +349,8 @@ Read more about this parameter in [Cluster-Wide Disk Layout Parameters](layout-c
 
 ## immediate_commit
 
-- Type: string, one of "all", "small" and "none"
+- Type: string
+- One of: "all", "small" or "none"
 - Default: none
 
 Immediate commit setting for this pool. The value from /vitastor/config/global
@@ -377,24 +406,37 @@ of the OSDs containing a data chunk for a PG.
 Automatic scrubbing interval for this pool. Overrides
 [global scrub_interval setting](osd.en.md#scrub_interval).
 
-## used_for_fs
+## used_for_app
 
 - Type: string
 
-If non-empty, the pool is marked as used for VitastorFS with metadata stored
-in block image (regular Vitastor volume) named as the value of this pool parameter.
+If non-empty, the pool is marked as used for a separate application, for example,
+VitastorFS or S3, which allocates Vitastor volume IDs by itself and does not use
+image/inode metadata in etcd.
 
-When a pool is marked as used for VitastorFS, regular block volume creation in it
+When a pool is marked as used for such app, regular block volume creation in it
 is disabled (vitastor-cli refuses to create images without --force) to protect
-the user from block volume and FS file ID collisions and data loss.
+the user from block volume and FS/S3 volume ID collisions and data loss.
 
-[vitastor-nfs](../usage/nfs.ru.md), in its turn, refuses to use pools not marked
+Also such pools do not calculate per-inode space usage statistics in etcd because
+using it for an external application implies that it may contain a very large
+number of volumes and their statistics may take too much space in etcd.
+
+Setting used_for_app to `fs:<name>` tells Vitastor that the pool is used for VitastorFS
+with VitastorKV metadata base stored in a block image (regular Vitastor volume) named
+`<name>`.
+
+[vitastor-nfs](../usage/nfs.en.md), in its turn, refuses to use pools not marked
 for the corresponding FS when starting. This also implies that you can use one
 pool only for one VitastorFS.
 
-The second thing that is disabled for VitastorFS pools is reporting per-inode space
-usage statistics in etcd because a FS pool may store a very large number of files
-and statistics for them all would take a lot of space in etcd.
+If you plan to use the pool for S3, set its used_for_app to `s3:<name>`. `<name>` may
+be basically anything you want (for example, `s3:standard`) - it's not validated
+by Vitastor S3 components in any way.
+
+All other values except prefixed with `fs:` or `s3:` may be used freely and don't
+mean anything special for Vitastor core components. For now, you can use them as
+you wish.
 
 # Examples
 

docs/config/pool.ru.md

@@ -33,6 +33,7 @@
 - [failure_domain](#failure_domain)
 - [level_placement](#level_placement)
 - [raw_placement](#raw_placement)
+- [local_reads](#local_reads)
 - [max_osd_combinations](#max_osd_combinations)
 - [block_size](#block_size)
 - [bitmap_granularity](#bitmap_granularity)
@@ -42,7 +43,7 @@
 - [osd_tags](#osd_tags)
 - [primary_affinity_tags](#primary_affinity_tags)
 - [scrub_interval](#scrub_interval)
-- [used_for_fs](#used_for_fs)
+- [used_for_app](#used_for_app)
 
 Примеры:
 
@@ -54,7 +55,7 @@
 Дерево размещения OSD задаётся в отдельном ключе etcd `/vitastor/config/node_placement`
 в следующем JSON-формате:
 
-`
+```
 {
   "<имя узла или номер OSD>": {
     "level": "<уровень>",
@@ -62,7 +63,7 @@
   },
   ...
 }
-`
+```
 
 Здесь, если название узла - число, считается, что это OSD. Уровень OSD
 всегда равен "osd" и не может быть переопределён. Для OSD вы можете только
@@ -133,8 +134,8 @@ OSD игнорируется и OSD не удаляется из распред
 ## scheme
 
 - Тип: строка
-- Обязательный
 - Возможные значения: "replicated", "xor", "ec" или "jerasure"
+- Обязательный
 
 Схема избыточности, используемая в данном пуле. "jerasure" - синоним для "ec",
 в обеих схемах используются коды Рида-Соломона-Вандермонда, реализованные на
@@ -256,7 +257,7 @@ PG в Vitastor эферемерны, то есть вы можете менят
 
 ## raw_placement
 
-- Type: string
+- Тип: строка
 
 Низкоуровневые правила генерации PG в форме DSL (доменно-специфичного языка).
 Используйте, только если действительно знаете, зачем вам это надо :)
@@ -287,6 +288,30 @@ meow недоступен".
 - EC 4+2 в 3 датацентрах: `any, dc=1 host!=1, dc!=1, dc=3 host!=3, dc!=(1,3), dc=5 host!=5`
 - 1 копия в фиксированном ДЦ + 2 в других ДЦ: `dc?=meow, dc!=1, dc!=(1,2)`
 
+## local_reads
+
+- Тип: строка
+- Возможные значения: "primary", "nearest" или "random"
+- По умолчанию: primary
+
+По умолчанию Vitastor обслуживает все запросы чтения и записи с первичного OSD каждой PG.
+Однако, в чистых PG (active или active+left_on_dead) реплицированных пулов также есть
+возможность обслуживать запросы чтения с вторичных OSD, что может быть полезно, если
+у вас сильно отличается время сетевого обращения от клиента к разным OSD - например,
+если у вас несколько дата-центров.
+
+Если данный параметр установлен в значение "nearest", клиенты будут стараться читать с
+ближайших по [Дереву размещения](#дерево-размещения) OSD, то есть, с OSD с того же хоста
+или датацентра. Расстояние до разных OSD будет рассчитываться с помощью имени хоста клиента,
+определяемого автоматически или заданного вручную параметром [hostname](client.ru.md#hostname).
+
+Если данный параметр установлен в значение "random", клиенты будут стараться распределять
+запросы чтения по всем доступным вторичным OSD. Этот режим в основном полезен для тестов,
+но, скорее всего, редко нужен в реальных инсталляциях.
+
+Для работы локальных чтений требуются [блокировки PG](osd.ru.md#enable_pg_locks). Включать
+их явно не нужно - они включаются автоматически для пулов с включёнными локальными чтениями.
+
 ## max_osd_combinations
 
 - Тип: целое число
@@ -324,7 +349,8 @@ meow недоступен".
 
 ## immediate_commit
 
-- Тип: строка "all", "small" или "none"
+- Тип: строка
+- Возможные значения: "all", "small" или "none"
 - По умолчанию: none
 
 Настройка мгновенного коммита для данного пула. Если не задана, используется
@@ -383,26 +409,42 @@ OSD с "all".
 Интервал скраба, то есть, автоматической фоновой проверки данных для данного пула.
 Переопределяет [глобальную настройку scrub_interval](osd.ru.md#scrub_interval).
 
-## used_for_fs
+## used_for_app
 
-- Type: string
+- Тип: строка
 
-Если непусто, пул помечается как используемый для файловой системы VitastorFS с
-метаданными, хранимыми в блочном образе Vitastor с именем, равным значению
-этого параметра.
+Если непусто, пул помечается как используемый для отдельного приложения, например,
+для VitastorFS или S3, которое распределяет ID образов в пуле само и не использует
+метаданные образов/инодов в etcd.
 
-Когда пул помечается как используемый для VitastorFS, создание обычных блочных
-образов в нём отключается (vitastor-cli отказывается создавать образы без --force),
-чтобы защитить пользователя от коллизий ID файлов и блочных образов и, таким
-образом, от потери данных.
+Когда пул помечается используемым для такого приложения, создание обычных блочных
+образов в нём запрещается (vitastor-cli отказывается создавать образы без --force),
+чтобы защитить пользователя от коллизий ID блочных образов и томов ФС/S3, и,
+таким образом, от потери данных.
+
+Также для таких пулов отключается передача статистики в etcd по отдельным инодам,
+так как использование для внешнего приложения подразумевает, что пул может содержать
+очень много томов и их статистика может занять слишком много места в etcd.
+
+Установка used_for_app в значение `fs:<name>` сообщает о том, что пул используется
+для VitastorFS с базой метаданных VitastorKV, хранимой в блочном образе с именем
+`<name>`.
 
 [vitastor-nfs](../usage/nfs.ru.md), в свою очередь, при запуске отказывается
-использовать для ФС пулы, не выделенные для неё. Это также означает, что один
-пул может использоваться только для одной VitastorFS.
+использовать для ФС пулы, не помеченные, как используемые для неё. Это также
+означает, что один пул может использоваться только для одной VitastorFS.
 
-Также для ФС-пулов отключается передача статистики в etcd по отдельным инодам,
-так как ФС-пул может содержать очень много файлов и статистика по ним всем
-заняла бы очень много места в etcd.
+Если же вы планируете использовать пул для данных S3, установите его used_for_app
+в значение `s3:<name>`, где `<name>` - любое название по вашему усмотрению
+(например, `s3:standard`) - конкретное содержимое `<name>` пока никак не проверяется
+компонентами Vitastor S3.
+
+Смотрите также [allow_net_split](osd.ru.md#allow_net_split) и
+[документацию по состояниям PG](../usage/admin.ru.md#состояния-pg).
+
+Все остальные значения used_for_app, кроме начинающихся на `fs:` или `s3:`, не
+означают ничего особенного для основных компонентов Vitastor. Поэтому сейчас вы
+можете использовать их свободно любым желаемым способом.
 
 # Примеры
 

docs/config/src/client.yml

@@ -61,6 +61,24 @@
   info_ru: |
     Повторять запросы записи, завершившиеся с ошибками нехватки места, т.е.
     ожидать, пока на OSD не освободится место.
+- name: client_wait_up_timeout
+  type: sec
+  default: 16
+  online: true
+  info: |
+    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`.
+  info_ru: |
+    Время ожидания поднятия 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`.
 - name: client_max_dirty_bytes
   type: int
   default: 33554432
@@ -253,3 +271,15 @@
     заполненные на 100% OSD вообще не могут стартовать), так что вы сможете
     восстановить работу кластера после ошибок отсутствия свободного места
     без уничтожения и пересоздания OSD.
+- name: hostname
+  type: string
+  online: true
+  info: |
+    Clients use host name to find their distance to OSDs when [localized reads](pool.en.md#local_reads)
+    are enabled. By default, standard [gethostname](https://man7.org/linux/man-pages/man2/gethostname.2.html)
+    function is used to determine host name, but you can also override it with this parameter.
+  info_ru: |
+    Клиенты используют имя хоста для определения расстояния до OSD, когда включены
+    [локальные чтения](pool.ru.md#local_reads). По умолчанию для определения имени
+    хоста используется стандартная функция [gethostname](https://man7.org/linux/man-pages/man2/gethostname.2.html),
+    но вы также можете задать имя хоста вручную данным параметром.

docs/config/src/included.en.md

@@ -14,8 +14,12 @@
 
 {{../../installation/packages.en.md}}
 
+{{../../installation/docker.en.md}}
+
 {{../../installation/proxmox.en.md}}
 
+{{../../installation/opennebula.en.md}}
+
 {{../../installation/openstack.en.md}}
 
 {{../../installation/kubernetes.en.md}}

docs/config/src/included.ru.md

@@ -14,8 +14,12 @@
 
 {{../../installation/packages.ru.md}}
 
+{{../../installation/docker.ru.md}}
+
 {{../../installation/proxmox.ru.md}}
 
+{{../../installation/opennebula.ru.md}}
+
 {{../../installation/openstack.ru.md}}
 
 {{../../installation/kubernetes.ru.md}}

docs/config/src/layout-cluster.yml

@@ -97,9 +97,9 @@
     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.yml#disable_journal_fsync) and
-    [disable_meta_fsync](layout-osd.en.yml#disable_meta_fsync), setting it to
-    "all" also requires enabling [disable_data_fsync](layout-osd.en.yml#disable_data_fsync).
+    [disable_journal_fsync](layout-osd.en.md#disable_journal_fsync) and
+    [disable_meta_fsync](layout-osd.en.md#disable_meta_fsync), setting it to
+    "all" also requires enabling [disable_data_fsync](layout-osd.en.md#disable_data_fsync).
     vitastor-disk tried to do that by default, first checking/disabling drive cache.
     If it can't disable drive cache, OSD get initialized with "none".
   info_ru: |
@@ -156,6 +156,6 @@
     указано в спецификациях).
 
     Указание "all" или "small" в настройках / командной строке OSD требует
-    включения [disable_journal_fsync](layout-osd.ru.yml#disable_journal_fsync) и
-    [disable_meta_fsync](layout-osd.ru.yml#disable_meta_fsync), значение "all"
-    также требует включения [disable_data_fsync](layout-osd.ru.yml#disable_data_fsync).
+    включения [disable_journal_fsync](layout-osd.ru.md#disable_journal_fsync) и
+    [disable_meta_fsync](layout-osd.ru.md#disable_meta_fsync), значение "all"
+    также требует включения [disable_data_fsync](layout-osd.ru.md#disable_data_fsync).

docs/config/src/layout-osd.yml

@@ -110,20 +110,22 @@
   type: bool
   default: false
   info: |
-    Do not issue fsyncs to the data device, i.e. do not flush its cache.
-    Safe ONLY if your data device has write-through cache. If you disable
-    the cache yourself using `hdparm` or `scsi_disk/cache_type` then make sure
-    that the cache disable command is run every time before starting Vitastor
-    OSD, for example, in the systemd unit. See also `immediate_commit` option
-    for the instructions to disable cache and how to benefit from it.
+    Do not issue fsyncs to the data device, i.e. do not force it to flush cache.
+    Safe ONLY if your data device has write-through cache or if write-back
+    cache is disabled. If you disable drive cache manually with `hdparm` or
+    writing to `/sys/.../scsi_disk/cache_type` then make sure that you do it
+    every time before starting Vitastor OSD (vitastor-disk does it automatically).
+    See also [immediate_commit](layout-cluster.en.md#immediate_commit)
+    for information about how to benefit from disabled cache.
   info_ru: |
-    Не отправлять fsync-и устройству данных, т.е. не сбрасывать его кэш.
+    Не отправлять fsync-и устройству данных, т.е. не заставлять его сбрасывать кэш.
     Безопасно, ТОЛЬКО если ваше устройство данных имеет кэш со сквозной
-    записью (write-through). Если вы отключаете кэш через `hdparm` или
-    `scsi_disk/cache_type`, то удостоверьтесь, что команда отключения кэша
-    выполняется перед каждым запуском Vitastor OSD, например, в systemd unit-е.
-    Смотрите также опцию `immediate_commit` для инструкций по отключению кэша
-    и о том, как из этого извлечь выгоду.
+    записью (write-through) или если кэш с отложенной записью (write-back) отключён.
+    Если вы отключаете кэш вручную через `hdparm` или запись в `/sys/.../scsi_disk/cache_type`,
+    то удостоверьтесь, что вы делаете это каждый раз перед запуском Vitastor OSD
+    (vitastor-disk делает это автоматически). Смотрите также опцию
+    [immediate_commit](layout-cluster.ru.md#immediate_commit) для информации о том,
+    как извлечь выгоду из отключённого кэша.
 - name: disable_meta_fsync
   type: bool
   default: false
@@ -179,8 +181,7 @@
 
     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 the only SSD that may fit into this category is
-    Intel Optane (probably, not tested yet).
+    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.
@@ -198,9 +199,8 @@
 
     Поэтому, на самом деле, может быть выгодно найти SSD, хорошо работающие с
     меньшими, 512-байтными, блоками и использовать 512-байтные disk_alignment,
-    journal_block_size и meta_block_size. Однако единственные SSD, которые
-    теоретически могут попасть в эту категорию - это Intel Optane (но и это
-    пока не проверялось автором).
+    journal_block_size и meta_block_size. Однако на данный момент такие SSD
+    не известны...
 
     Клиентам не обязательно знать про disk_alignment, так что помещать значение
     этого параметра в etcd в /vitastor/config/global не нужно.

docs/config/src/monitor.yml

@@ -75,11 +75,11 @@
 - name: mon_http_port
   type: int
   default: 8060
-  info: HTTP port for monitors to listen on (including metrics exporter)
+  info: HTTP port for monitors to listen to (including metrics exporter)
   info_ru: Порт, на котором мониторы принимают HTTP-соединения (в том числе для отдачи метрик)
 - name: mon_http_ip
   type: string
-  info: IP address for monitors to listen on (all addresses by default)
+  info: IP address for monitors to listen to (all addresses by default)
   info_ru: IP-адрес, на котором мониторы принимают HTTP-соединения (по умолчанию все адреса)
 - name: mon_https_cert
   type: string
@@ -172,3 +172,27 @@
   info_ru: |
     Использовать старый генератор комбинаций PG, не поддерживающий [level_placement](pool.ru.md#level_placement)
     и [raw_placement](pool.ru.md#raw_placement) для пулов, которые не используют данные функции.
+- name: osd_backfillfull_ratio
+  type: float
+  default: 0.99
+  info: |
+    Monitors try to prevent OSDs becoming 100% full during rebalance or recovery by
+    calculating how much space will be occupied on every OSD after all rebalance
+    and recovery operations finish, and pausing rebalance and recovery if that
+    amount of space exceeds OSD capacity multiplied by the value of this
+    configuration parameter.
+
+    Future used space is calculated by summing space used by all user data blocks
+    (objects) in all PGs placed on a specific OSD, even if some of these objects
+    currently reside on a different set of OSDs.
+  info_ru: |
+    Мониторы стараются предотвратить 100% заполнение OSD в процессе ребаланса
+    или восстановления, рассчитывая, сколько места будет занято на каждом OSD после
+    завершения всех операций ребаланса и восстановления, и приостанавливая
+    ребаланс и восстановление, если рассчитанный объём превышает ёмкость OSD,
+    умноженную на значение данного параметра.
+
+    Будущее занятое место рассчитывается сложением места, занятого всеми
+    пользовательскими блоками данных (объектами) во всех PG, расположенных
+    на конкретном OSD, даже если часть этих объектов в данный момент находится
+    на другом наборе OSD.

docs/config/src/network.yml

@@ -1,58 +1,93 @@
-- name: tcp_header_buffer_size
-  type: int
-  default: 65536
+- name: osd_network
+  type: string or array of strings
+  type_ru: строка или массив строк
   info: |
-    Size of the buffer used to read data using an additional copy. Vitastor
-    packet headers are 128 bytes, payload is always at least 4 KB, so it is
-    usually beneficial to try to read multiple packets at once even though
-    it requires to copy the data an additional time. The rest of each packet
-    is received without an additional copy. You can try to play with this
-    parameter and see how it affects random iops and linear bandwidth if you
-    want.
+    Network mask of public OSD network(s) (IPv4 or IPv6). Each OSD listens to all
+    addresses of UP + RUNNING interfaces matching one of these networks, on the
+    same port. Port is auto-selected except if [bind_port](osd.en.md#bind_port) is
+    explicitly specified. Bind address(es) may also be overridden manually by
+    specifying [bind_address](osd.en.md#bind_address). If OSD networks are not specified
+    at all, OSD just listens to a wildcard address (0.0.0.0).
   info_ru: |
-    Размер буфера для чтения данных с дополнительным копированием. Пакеты
-    Vitastor содержат 128-байтные заголовки, за которыми следуют данные размером
-    от 4 КБ и для мелких операций ввода-вывода обычно выгодно за 1 вызов читать
-    сразу несколько пакетов, даже не смотря на то, что это требует лишний раз
-    скопировать данные. Часть каждого пакета за пределами значения данного
-    параметра читается без дополнительного копирования. Вы можете попробовать
-    поменять этот параметр и посмотреть, как он влияет на производительность
-    случайного и линейного доступа.
-- name: use_sync_send_recv
-  type: bool
-  default: false
+    Маски подсетей (IPv4 или IPv6) публичной сети или сетей OSD. Каждый OSD слушает
+    один и тот же порт на всех адресах поднятых (UP + RUNNING) сетевых интерфейсов,
+    соответствующих одной из указанных сетей. Порт выбирается автоматически, если
+    только [bind_port](osd.ru.md#bind_port) не задан явно. Адреса для подключений можно
+    также переопределить явно, задав [bind_address](osd.ru.md#bind_address). Если сети OSD
+    не заданы вообще, OSD слушает все адреса (0.0.0.0).
+- name: osd_cluster_network
+  type: string or array of strings
+  type_ru: строка или массив строк
   info: |
-    If true, synchronous send/recv syscalls are used instead of io_uring for
-    socket communication. Useless for OSDs because they require io_uring anyway,
-    but may be required for clients with old kernel versions.
+    Network mask of separate network(s) (IPv4 or IPv6) to use for OSD
+    cluster connections. I.e. OSDs will always attempt to use these networks
+    to connect to other OSDs, while clients will attempt to use networks from
+    [osd_network](#osd_network).
   info_ru: |
-    Если установлено в истину, то вместо io_uring для передачи данных по сети
-    будут использоваться обычные синхронные системные вызовы send/recv. Для OSD
-    это бессмысленно, так как OSD в любом случае нуждается в io_uring, но, в
-    принципе, это может применяться для клиентов со старыми версиями ядра.
+    Маски подсетей (IPv4 или IPv6) отдельной кластерной сети или сетей OSD.
+    То есть, OSD будут всегда стараться использовать эти сети для соединений
+    с другими OSD, а клиенты будут стараться использовать сети из [osd_network](#osd_network).
 - name: use_rdma
   type: bool
   default: true
   info: |
-    Try to use RDMA for communication if it's available. Disable if you don't
-    want Vitastor to use RDMA. TCP-only clients can also talk to an RDMA-enabled
-    cluster, so disabling RDMA may be needed if clients have RDMA devices,
-    but they are not connected to the cluster.
+    Try to use RDMA through libibverbs for communication if it's available.
+    Disable if you don't want Vitastor to use RDMA. TCP-only clients can also
+    talk to an RDMA-enabled cluster, so disabling RDMA may be needed if clients
+    have RDMA devices, but they are not connected to the cluster.
+
+    `use_rdma` works with RoCEv1/RoCEv2 networks, but not with iWARP and,
+    maybe, with some Infiniband configurations which require RDMA-CM.
+    Consider `use_rdmacm` for such networks.
   info_ru: |
-    Пытаться использовать RDMA для связи при наличии доступных устройств.
-    Отключите, если вы не хотите, чтобы Vitastor использовал RDMA.
-    TCP-клиенты также могут работать с RDMA-кластером, так что отключать
-    RDMA может быть нужно только если у клиентов есть RDMA-устройства,
-    но они не имеют соединения с кластером Vitastor.
+    Попробовать использовать RDMA через libibverbs для связи при наличии
+    доступных устройств. Отключите, если вы не хотите, чтобы Vitastor
+    использовал RDMA. TCP-клиенты также могут работать с RDMA-кластером,
+    так что отключать RDMA может быть нужно, только если у клиентов есть
+    RDMA-устройства, но они не имеют соединения с кластером Vitastor.
+
+    `use_rdma` работает с RoCEv1/RoCEv2 сетями, но не работает с iWARP и
+    может не работать с частью конфигураций Infiniband, требующих RDMA-CM.
+    Рассмотрите включение `use_rdmacm` для таких сетей.
+- name: use_rdmacm
+  type: bool
+  default: true
+  info: |
+    Use an alternative implementation of RDMA through RDMA-CM (Connection
+    Manager). Works with all RDMA networks: Infiniband, iWARP and
+    RoCEv1/RoCEv2, and even allows to disable TCP and run only with RDMA.
+    OSDs always use random port numbers for RDMA-CM listeners, different
+    from their TCP ports. `use_rdma` is automatically disabled when
+    `use_rdmacm` is enabled.
+  info_ru: |
+    Использовать альтернативную реализацию RDMA на основе RDMA-CM (Connection
+    Manager). Работает со всеми типами RDMA-сетей: Infiniband, iWARP и
+    RoCEv1/RoCEv2, и даже позволяет полностью отключить TCP и работать
+    только на RDMA. OSD используют случайные номера портов для ожидания
+    соединений через RDMA-CM, отличающиеся от их TCP-портов. Также при
+    включении `use_rdmacm` автоматически отключается опция `use_rdma`.
+- name: disable_tcp
+  type: bool
+  default: true
+  info: |
+    Fully disable TCP and only use RDMA-CM for OSD communication.
+  info_ru: |
+    Полностью отключить TCP и использовать только RDMA-CM для соединений с OSD.
 - name: rdma_device
   type: string
   info: |
     RDMA device name to use for Vitastor OSD communications (for example,
-    "rocep5s0f0"). Now Vitastor supports all adapters, even ones without
-    ODP support, like Mellanox ConnectX-3 and non-Mellanox cards.
+    "rocep5s0f0"). If not specified, Vitastor will try to find an RoCE
+    device matching [osd_network](osd.en.md#osd_network), preferring RoCEv2,
+    or choose the first available RDMA device if no RoCE devices are
+    found or if `osd_network` is not specified. Auto-selection is also
+    unsupported with old libibverbs < v32, like in Debian 10 Buster or
+    CentOS 7.
 
-    Versions up to Vitastor 1.2.0 required ODP which is only present in
-    Mellanox ConnectX >= 4. See also [rdma_odp](#rdma_odp).
+    Vitastor supports all adapters, even ones without ODP support, like
+    Mellanox ConnectX-3 and non-Mellanox cards. Versions up to Vitastor
+    1.2.0 required ODP which is only present in Mellanox ConnectX >= 4.
+    See also [rdma_odp](#rdma_odp).
 
     Run `ibv_devinfo -v` as root to list available RDMA devices and their
     features.
@@ -64,12 +99,17 @@
     PFC (Priority Flow Control) and ECN (Explicit Congestion Notification).
   info_ru: |
     Название RDMA-устройства для связи с Vitastor OSD (например, "rocep5s0f0").
-    Сейчас Vitastor поддерживает все модели адаптеров, включая те, у которых
-    нет поддержки ODP, то есть вы можете использовать RDMA с ConnectX-3 и
-    картами производства не Mellanox.
+    Если не указано, Vitastor попробует найти RoCE-устройство, соответствующее
+    [osd_network](osd.en.md#osd_network), предпочитая RoCEv2, или выбрать первое
+    попавшееся RDMA-устройство, если RoCE-устройств нет или если сеть `osd_network`
+    не задана. Также автовыбор не поддерживается со старыми версиями библиотеки
+    libibverbs < v32, например в Debian 10 Buster или CentOS 7.
 
-    Версии Vitastor до 1.2.0 включительно требовали ODP, который есть только
-    на Mellanox ConnectX 4 и более новых. См. также [rdma_odp](#rdma_odp).
+    Vitastor поддерживает все модели адаптеров, включая те, у которых
+    нет поддержки ODP, то есть вы можете использовать RDMA с ConnectX-3 и
+    картами производства не Mellanox. Версии Vitastor до 1.2.0 включительно
+    требовали ODP, который есть только на Mellanox ConnectX 4 и более новых.
+    См. также [rdma_odp](#rdma_odp).
 
     Запустите `ibv_devinfo -v` от имени суперпользователя, чтобы посмотреть
     список доступных RDMA-устройств, их параметры и возможности.
@@ -82,44 +122,56 @@
     Control) и ECN (Explicit Congestion Notification).
 - name: rdma_port_num
   type: int
-  default: 1
   info: |
     RDMA device port number to use. Only for devices that have more than 1 port.
     See `phys_port_cnt` in `ibv_devinfo -v` output to determine how many ports
     your device has.
+
+    Not relevant for RDMA-CM (use_rdmacm).
   info_ru: |
     Номер порта RDMA-устройства, который следует использовать. Имеет смысл
     только для устройств, у которых более 1 порта. Чтобы узнать, сколько портов
     у вашего адаптера, посмотрите `phys_port_cnt` в выводе команды
     `ibv_devinfo -v`.
+
+    Опция неприменима к RDMA-CM (use_rdmacm).
 - name: rdma_gid_index
   type: int
-  default: 0
   info: |
     Global address identifier index of the RDMA device to use. Different GID
     indexes may correspond to different protocols like RoCEv1, RoCEv2 and iWARP.
     Search for "GID" in `ibv_devinfo -v` output to determine which GID index
     you need.
 
-    **IMPORTANT:** If you want to use RoCEv2 (as recommended) then the correct
-    rdma_gid_index is usually 1 (IPv6) or 3 (IPv4).
+    If not specified, Vitastor will try to auto-select a RoCEv2 IPv4 GID, then
+    RoCEv2 IPv6 GID, then RoCEv1 IPv4 GID, then RoCEv1 IPv6 GID, then IB GID.
+    GID auto-selection is unsupported with libibverbs < v32.
+
+    A correct rdma_gid_index for RoCEv2 is usually 1 (IPv6) or 3 (IPv4).
+
+    Not relevant for RDMA-CM (use_rdmacm).
   info_ru: |
     Номер глобального идентификатора адреса RDMA-устройства, который следует
     использовать. Разным gid_index могут соответствовать разные протоколы связи:
     RoCEv1, RoCEv2, iWARP. Чтобы понять, какой нужен вам - смотрите строчки со
     словом "GID" в выводе команды `ibv_devinfo -v`.
 
-    **ВАЖНО:** Если вы хотите использовать RoCEv2 (как мы и рекомендуем), то
-    правильный rdma_gid_index, как правило, 1 (IPv6) или 3 (IPv4).
+    Если не указан, Vitastor попробует автоматически выбрать сначала GID,
+    соответствующий RoCEv2 IPv4, потом RoCEv2 IPv6, потом RoCEv1 IPv4, потом
+    RoCEv1 IPv6, потом IB. Авто-выбор GID не поддерживается со старыми версиями
+    libibverbs < v32.
+
+    Правильный rdma_gid_index для RoCEv2, как правило, 1 (IPv6) или 3 (IPv4).
+
+    Опция неприменима к RDMA-CM (use_rdmacm).
 - name: rdma_mtu
   type: int
-  default: 4096
   info: |
-    RDMA Path MTU to use. Must be 1024, 2048 or 4096. There is usually no
-    sense to change it from the default 4096.
+    RDMA Path MTU to use. Must be 1024, 2048 or 4096. Default is to use the
+    RDMA device's MTU.
   info_ru: |
     Максимальная единица передачи (Path MTU) для RDMA. Должно быть равно 1024,
-    2048 или 4096. Обычно нет смысла менять значение по умолчанию, равное 4096.
+    2048 или 4096. По умолчанию используется значение MTU RDMA-устройства.
 - name: rdma_max_sge
   type: int
   default: 128
@@ -289,3 +341,96 @@
     detect disconnections quickly.
   info_ru: |
     Интервал проверки живости вебсокет-подключений к etcd.
+- name: etcd_min_reload_interval
+  type: ms
+  default: 1000
+  online: true
+  info: |
+    Minimum interval for full etcd state reload. Introduced to prevent
+    excessive load on etcd during outages when etcd can't keep up with event
+    streams and cancels them.
+  info_ru: |
+    Минимальный интервал полной перезагрузки состояния из etcd. Добавлено для
+    предотвращения избыточной нагрузки на etcd во время отказов, когда etcd не
+    успевает рассылать потоки событий и отменяет их.
+- name: tcp_header_buffer_size
+  type: int
+  default: 65536
+  info: |
+    Size of the buffer used to read data using an additional copy. Vitastor
+    packet headers are 128 bytes, payload is always at least 4 KB, so it is
+    usually beneficial to try to read multiple packets at once even though
+    it requires to copy the data an additional time. The rest of each packet
+    is received without an additional copy. You can try to play with this
+    parameter and see how it affects random iops and linear bandwidth if you
+    want.
+  info_ru: |
+    Размер буфера для чтения данных с дополнительным копированием. Пакеты
+    Vitastor содержат 128-байтные заголовки, за которыми следуют данные размером
+    от 4 КБ и для мелких операций ввода-вывода обычно выгодно за 1 вызов читать
+    сразу несколько пакетов, даже не смотря на то, что это требует лишний раз
+    скопировать данные. Часть каждого пакета за пределами значения данного
+    параметра читается без дополнительного копирования. Вы можете попробовать
+    поменять этот параметр и посмотреть, как он влияет на производительность
+    случайного и линейного доступа.
+- name: min_zerocopy_send_size
+  type: int
+  default: 32768
+  info: |
+    OSDs and clients will attempt to use io_uring-based zero-copy TCP send
+    for buffers larger than this number of bytes. Zero-copy send with io_uring is
+    supported since Linux kernel version 6.1. Support is auto-detected and disabled
+    automatically when not available. It can also be disabled explicitly by setting
+    this parameter to a negative value.
+
+    ⚠️ Warning! Zero-copy send performance may vary greatly from CPU to CPU and from
+    one kernel version to another. Generally, it tends to only make benefit with larger
+    messages. With smaller messages (say, 4 KB), it may actually be slower. 32 KB is
+    enough for almost all CPUs, but even smaller values are optimal for some of them.
+    For example, 4 KB is OK for EPYC Milan/Genoa and 12 KB is OK for Xeon Ice Lake
+    (but verify it yourself please).
+
+    Verification instructions:
+    1. Add `iommu=pt` into your Linux kernel command line and reboot.
+    2. Upgrade your kernel. For example, it's very important to use 6.11+ with recent AMD EPYCs.
+    3. Run some tests with the [send-zerocopy liburing example](https://github.com/axboe/liburing/blob/master/examples/send-zerocopy.c)
+       to find the minimal message size for which zero-copy is optimal.
+       Use `./send-zerocopy tcp -4 -R` at the server side and
+       `time ./send-zerocopy tcp -4 -b 0 -s BUFFER_SIZE -D SERVER_IP` at the client side with
+       `-z 0` (no zero-copy) and `-z 1` (zero-copy), and compare MB/s and used CPU time
+       (user+system).
+  info_ru: |
+    OSD и клиенты будут пробовать использовать TCP-отправку без копирования (zero-copy) на
+    основе io_uring для буферов, больших, чем это число байт. Отправка без копирования
+    поддерживается в io_uring, начиная с версии ядра Linux 6.1. Наличие поддержки
+    проверяется автоматически и zero-copy отключается, когда поддержки нет. Также
+    её можно отключить явно, установив данный параметр в отрицательное значение.
+
+    ⚠️ Внимание! Производительность данной функции может сильно отличаться на разных
+    процессорах и на разных версиях ядра Linux. В целом, zero-copy обычно быстрее с
+    большими сообщениями, а с мелкими (например, 4 КБ) zero-copy может быть даже
+    медленнее. 32 КБ достаточно почти для всех процессоров, но для каких-то можно
+    использовать даже меньшие значения. Например, для EPYC Milan/Genoa подходит 4 КБ,
+    а для Xeon Ice Lake - 12 КБ (но, пожалуйста, перепроверьте это сами).
+
+    Инструкция по проверке:
+    1. Добавьте `iommu=pt` в командную строку загрузки вашего ядра Linux и перезагрузитесь.
+    2. Обновите ядро. Например, для AMD EPYC очень важно использовать версию 6.11+.
+    3. Позапускайте тесты с помощью [send-zerocopy из примеров liburing](https://github.com/axboe/liburing/blob/master/examples/send-zerocopy.c),
+       чтобы найти минимальный размер сообщения, для которого zero-copy отправка оптимальна.
+       Запускайте `./send-zerocopy tcp -4 -R` на стороне сервера и
+       `time ./send-zerocopy tcp -4 -b 0 -s РАЗМЕР_БУФЕРА -D АДРЕС_СЕРВЕРА` на стороне клиента
+       с опцией `-z 0` (обычная отправка) и `-z 1` (отправка без копирования), и сравнивайте
+       скорость в МБ/с и занятое процессорное время (user+system).
+- name: use_sync_send_recv
+  type: bool
+  default: false
+  info: |
+    If true, synchronous send/recv syscalls are used instead of io_uring for
+    socket communication. Useless for OSDs because they require io_uring anyway,
+    but may be required for clients with old kernel versions.
+  info_ru: |
+    Если установлено в истину, то вместо io_uring для передачи данных по сети
+    будут использоваться обычные синхронные системные вызовы send/recv. Для OSD
+    это бессмысленно, так как OSD в любом случае нуждается в io_uring, но, в
+    принципе, это может применяться для клиентов со старыми версиями ядра.

docs/config/src/osd.en.md

@@ -1,5 +1,5 @@
 # Runtime OSD Parameters
 
 These parameters only apply to OSDs, are not fixed at the moment of OSD drive
-initialization and can be changed - either with an OSD restart or, for some of
-them, even without restarting by updating configuration in etcd.
+initialization and can be changed - in /etc/vitastor/vitastor.conf or [vitastor-disk update-sb](../usage/disk.en.md#update-sb)
+with an OSD restart or, for some of them, even without restarting by updating configuration in etcd.

docs/config/src/osd.ru.md

@@ -2,5 +2,5 @@
 
 Данные параметры используются только OSD, но, в отличие от дисковых параметров,
 не фиксируются в момент инициализации дисков OSD и могут быть изменены в любой
-момент с помощью перезапуска OSD, а некоторые и без перезапуска, с помощью
-изменения конфигурации в etcd.
+момент с перезапуском OSD в /etc/vitastor/vitastor.conf или [vitastor-disk update-sb](../usage/disk.ru.md#update-sb),
+а некоторые и без перезапуска, с помощью изменения конфигурации в etcd.

docs/config/src/osd.yml

@@ -1,3 +1,26 @@
+- name: bind_address
+  type: string or array of strings
+  type_ru: строка или массив строк
+  info: |
+    Instead of the network masks ([osd_network](network.en.md#osd_network) and
+    [osd_cluster_network](network.en.md#osd_cluster_network)), you can also set
+    OSD listen addresses explicitly using this parameter. May be useful if you
+    want to start OSDs on interfaces that are not UP + RUNNING.
+  info_ru: |
+    Вместо использования масок подсети ([osd_network](network.ru.md#osd_network) и
+    [osd_cluster_network](network.ru.md#osd_cluster_network)), вы также можете явно
+    задать адрес(а), на которых будут ожидать соединений OSD, с помощью данного
+    параметра. Это может быть полезно, например, чтобы запускать OSD на неподнятых
+    интерфейсах (не UP + RUNNING).
+- name: bind_port
+  type: int
+  info: |
+    By default, OSDs pick random ports to use for incoming connections
+    automatically. With this option you can set a specific port for a specific
+    OSD by hand.
+  info_ru: |
+    По умолчанию OSD сами выбирают случайные порты для входящих подключений.
+    С помощью данной опции вы можете задать порт для отдельного OSD вручную.
 - name: osd_iothread_count
   type: int
   default: 0
@@ -56,44 +79,6 @@
     реализовать дополнительный режим для монитора, который позволит отделять
     первичные OSD от вторичных, но пока не понятно, зачем это может кому-то
     понадобиться, поэтому это не реализовано.
-- name: osd_network
-  type: string or array of strings
-  type_ru: строка или массив строк
-  info: |
-    Network mask of the network (IPv4 or IPv6) to use for OSDs. Note that
-    although it's possible to specify multiple networks here, this does not
-    mean that OSDs will create multiple listening sockets - they'll only
-    pick the first matching address of an UP + RUNNING interface. Separate
-    networks for cluster and client connections are also not implemented, but
-    they are mostly useless anyway, so it's not a big deal.
-  info_ru: |
-    Маска подсети (IPv4 или IPv6) для использования для соединений с OSD.
-    Имейте в виду, что хотя сейчас и можно передать в этот параметр несколько
-    подсетей, это не означает, что OSD будут создавать несколько слушающих
-    сокетов - они лишь будут выбирать адрес первого поднятого (состояние UP +
-    RUNNING), подходящий под заданную маску. Также не реализовано разделение
-    кластерной и публичной сетей OSD. Правда, от него обычно всё равно довольно
-    мало толку, так что особенной проблемы в этом нет.
-- name: bind_address
-  type: string
-  default: "0.0.0.0"
-  info: |
-    Instead of the network mask, you can also set OSD listen address explicitly
-    using this parameter. May be useful if you want to start OSDs on interfaces
-    that are not UP + RUNNING.
-  info_ru: |
-    Этим параметром можно явным образом задать адрес, на котором будет ожидать
-    соединений OSD (вместо использования маски подсети). Может быть полезно,
-    например, чтобы запускать OSD на неподнятых интерфейсах (не UP + RUNNING).
-- name: bind_port
-  type: int
-  info: |
-    By default, OSDs pick random ports to use for incoming connections
-    automatically. With this option you can set a specific port for a specific
-    OSD by hand.
-  info_ru: |
-    По умолчанию OSD сами выбирают случайные порты для входящих подключений.
-    С помощью данной опции вы можете задать порт для отдельного OSD вручную.
 - name: autosync_interval
   type: sec
   default: 5
@@ -315,7 +300,7 @@
     decrease write performance for fast disks because page cache is an overhead
     itself.
 
-    Choose "directsync" to use [immediate_commit](layout-cluster.ru.md#immediate_commit)
+    Choose "directsync" to use [immediate_commit](layout-cluster.en.md#immediate_commit)
     (which requires disable_data_fsync) with drives having write-back cache
     which can't be turned off, for example, Intel Optane. Also note that *some*
     desktop SSDs (for example, HP EX950) may ignore O_SYNC thus making
@@ -765,3 +750,54 @@
     Максимальное возможное значение авто-подстроенного recovery_sleep_us.
     Большие значения считаются случайными выбросами и игнорируются в
     усреднении.
+- name: discard_on_start
+  type: bool
+  info: Discard (SSD TRIM) unused data device blocks on every OSD startup.
+  info_ru: Освобождать (SSD TRIM) неиспользуемые блоки диска данных при каждом запуске OSD.
+- name: min_discard_size
+  type: int
+  default: 1048576
+  info: Minimum consecutive block size to TRIM it.
+  info_ru: Минимальный размер последовательного блока данных, чтобы освобождать его через TRIM.
+- name: allow_net_split
+  type: bool
+  default: false
+  info: |
+    Allow "safe" cases of network splits/partitions - allow to start PGs without
+    connections to some OSDs currently registered as alive in etcd, if the number
+    of actually connected PG OSDs is at least pg_minsize. That is, allow some OSDs to lose
+    connectivity with some other OSDs as long as it doesn't break pg_minsize guarantees.
+    The downside is that it increases the probability of writing data into just pg_minsize
+    OSDs during failover which can lead to PGs becoming incomplete after additional outages.
+
+    The old behaviour in versions up to 2.0.0 was equal to enabled allow_net_split.
+  info_ru: |
+    Разрешить "безопасные" случаи разделений сети - разрешить активировать PG без
+    соединений к некоторым OSD, помеченным активными в etcd, если общее число активных
+    OSD в PG составляет как минимум pg_minsize. То есть, разрешать некоторым OSD терять
+    соединения с некоторыми другими OSD, если это не нарушает гарантий pg_minsize.
+    Минус такого разрешения в том, что оно повышает вероятность записи данных ровно в
+    pg_minsize OSD во время переключений, что может потом привести к тому, что PG станут
+    неполными (incomplete), если упадут ещё какие-то OSD.
+
+    Старое поведение в версиях до 2.0.0 было идентично включённому allow_net_split.
+- name: enable_pg_locks
+  type: bool
+  info: |
+    Vitastor 2.2.0 introduces a new layer of split-brain prevention mechanism in
+    addition to etcd: PG locks. They prevent split-brain even in abnormal theoretical cases
+    when etcd is extremely laggy. As a new feature, by default, PG locks are only enabled
+    for pools where they're required - pools with [localized reads](pool.en.md#local_reads).
+    Use this parameter to enable or disable this function for all pools.
+  info_ru: |
+    В Vitastor 2.2.0 появился новый слой защиты от сплитбрейна в дополнение к etcd -
+    блокировки PG. Они гарантируют порядок даже в теоретических ненормальных случаях,
+    когда etcd очень сильно тормозит. Так как функция новая, по умолчанию она включается
+    только для пулов, в которых она необходима - а именно, в пулах с включёнными
+    [локальными чтениями](pool.ru.md#local_reads). Ну а с помощью данного параметра
+    можно включить блокировки PG для всех пулов.
+- name: pg_lock_retry_interval_ms
+  type: ms
+  default: 100
+  info: Retry interval for failed PG lock attempts.
+  info_ru: Интервал повтора неудачных попыток блокировки PG.

docs/gen-docs.js

@@ -1,55 +0,0 @@
-#!/usr/bin/nodejs
-
-const fs = require('fs');
-const yaml = require('yaml');
-
-const L = {
-    en: {},
-    ru: {
-        Type: 'Тип',
-        Default: 'Значение по умолчанию',
-        Minimum: 'Минимальное значение',
-    },
-};
-const types = {
-    en: {
-        string: 'string',
-        bool: 'boolean',
-        int: 'integer',
-        sec: 'seconds',
-        ms: 'milliseconds',
-        us: 'microseconds',
-    },
-    ru: {
-        string: 'строка',
-        bool: 'булево (да/нет)',
-        int: 'целое число',
-        sec: 'секунды',
-        ms: 'миллисекунды',
-        us: 'микросекунды',
-    },
-};
-const params_files = fs.readdirSync(__dirname+'/params')
-    .filter(f => f.substr(-4) == '.yml')
-    .map(f => f.substr(0, f.length-4));
-
-for (const file of params_files)
-{
-    const cfg = yaml.parse(fs.readFileSync(__dirname+'/params/'+file+'.yml', { encoding: 'utf-8' }));
-    for (const lang in types)
-    {
-        let out = '\n\n{{< toc >}}';
-        for (const c of cfg)
-        {
-            out += `\n\n## ${c.name}\n\n`;
-            out += `- ${L[lang]['Type'] || 'Type'}: ${c["type_"+lang] || types[lang][c.type] || c.type}\n`;
-            if (c.default !== undefined)
-                out += `- ${L[lang]['Default'] || 'Default'}: ${c.default}\n`;
-            if (c.min !== undefined)
-                out += `- ${L[lang]['Minimum'] || 'Minimum'}: ${c.min}\n`;
-            out += `\n`+(c["info_"+lang] || c["info"]).replace(/\s+$/, '');
-        }
-        const head = fs.readFileSync(__dirname+'/params/head/'+file+'.'+lang+'.md', { encoding: 'utf-8' });
-        fs.writeFileSync(__dirname+'/hugo/content/config/'+file+'.'+lang+'.md', head.replace(/\s+$/, '')+out+"\n");
-    }
-}

docs/installation/docker.en.md

@@ -0,0 +1,60 @@
+[Documentation](../../README.md#documentation) → Installation → Dockerized Installation
+
+-----
+
+[Читать на русском](docker.ru.md)
+
+# Dockerized Installation
+
+Vitastor may be installed in Docker/Podman. In such setups etcd, monitors and OSD
+all run in containers, but everything else looks as close as possible to a usual
+setup with packages:
+- host network is used
+- auto-start is implemented through udev and systemd
+- logs are written to journald (not docker json log files)
+- command-line wrapper scripts are installed to the host system to call vitastor-disk,
+  vitastor-cli and others through the container
+
+Such installations may be useful when it's impossible or inconvenient to install
+Vitastor from packages, for example, in exotic Linux distributions.
+
+If you don't want just a simple containerized installation, you can also take a look
+at Vitastor Kubernetes operator: https://github.com/Antilles7227/vitastor-operator
+
+## Installing Containers
+
+The instruction is very simple.
+
+1. Download a Docker image of the desired version: \
+   `docker pull vitastor:v2.2.2`
+2. Install scripts to the host system: \
+   `docker run --rm -it -v /etc:/host-etc -v /usr/bin:/host-bin vitastor:v2.2.2 install.sh`
+3. Reload udev rules: \
+   `udevadm control --reload-rules`
+
+And you can return to [Quick Start](../intro/quickstart.en.md).
+
+## Upgrading Containers
+
+First make sure to check the topic [Upgrading Vitastor](../usage/admin.en.md#upgrading-vitastor)
+to figure out if you need any additional steps.
+
+Then, to upgrade a containerized installation, you just need to change the `VITASTOR_VERSION`
+option in `/etc/vitastor/docker.conf` and restart all Vitastor services:
+
+`systemctl restart vitastor.target`
+
+## QEMU
+
+Vitastor Docker image also contains QEMU, qemu-img and qemu-storage-daemon built with Vitastor support.
+
+However, running QEMU in Docker is harder to setup and it depends on the used virtualization UI
+(OpenNebula, Proxmox and so on). Some of them also required patched Libvirt.
+
+That's why containerized installation of Vitastor doesn't contain a ready-made QEMU setup and it's
+recommended to install QEMU from packages or build it manually.
+
+## fio
+
+Vitastor Docker image also contains fio and installs a wrapper called `vitastor-fio` to use it from
+the host system.

docs/installation/docker.ru.md

@@ -0,0 +1,60 @@
+[Документация](../../README-ru.md#документация) → Установка → Установка в Docker
+
+-----
+
+[Read in English](docker.en.md)
+
+# Установка в Docker
+
+Vitastor можно установить в Docker/Podman. При этом etcd, мониторы и OSD запускаются
+в контейнерах, но всё остальное выглядит максимально приближенно к установке из пакетов:
+- используется сеть хост-системы
+- для автозапуска используются udev и systemd
+- журналы записываются в journald (не в json-файлы журналов docker)
+- в хост-систему устанавливаются обёртки для вызова консольных инструментов vitastor-disk,
+  vitastor-cli и других через контейнер
+
+Такая установка полезна тогда, когда установка из пакетов невозможна или неудобна,
+например, в нестандартных Linux-дистрибутивах.
+
+Если вам нужна не просто контейнеризованная инсталляция, вы также можете обратить внимание
+на Vitastor Kubernetes-оператор: https://github.com/Antilles7227/vitastor-operator
+
+## Установка контейнеров
+
+Инструкция по установке максимально простая.
+
+1. Скачайте Docker-образ желаемой версии: \
+   `docker pull vitastor:v2.2.2`
+2. Установите скрипты в хост-систему командой: \
+   `docker run --rm -it -v /etc:/host-etc -v /usr/bin:/host-bin vitastor:v2.2.2 install.sh`
+3. Перезагрузите правила udev: \
+   `udevadm control --reload-rules`
+
+После этого вы можете возвращаться к разделу [Быстрый старт](../intro/quickstart.ru.md).
+
+## Обновление контейнеров
+
+Сначала обязательно проверьте раздел [Обновление Vitastor](../usage/admin.ru.md#обновление-vitastor),
+чтобы понять, не требуются ли вам какие-то дополнительные действия.
+
+После этого для обновления Docker-инсталляции вам нужно просто поменять опцию `VITASTOR_VERSION`
+в файле `/etc/vitastor/docker.conf` и перезапустить все сервисы Vitastor командой:
+
+`systemctl restart vitastor.target`
+
+## QEMU
+
+В Docker-образ также входят QEMU, qemu-img и qemu-storage-daemon, собранные с поддержкой Vitastor.
+
+Однако настроить запуск QEMU в Docker сложнее и способ запуска зависит от используемого интерфейса
+виртуализации (OpenNebula, Proxmox и т.п.). Также для OpenNebula, например, требуется патченый
+Libvirt.
+
+Поэтому по умолчанию Docker-сборка пока что не включает в себя готового способа запуска QEMU
+и QEMU рекомендуется устанавливать из пакетов или собирать самостоятельно.
+
+## fio
+
+fio также входит в Docker-контейнер vitastor, и в хост-систему устанавливается обёртка `vitastor-fio`
+для запуска fio в контейнер.

docs/installation/kubernetes.en.md

@@ -6,9 +6,18 @@
 
 # Kubernetes CSI
 
-Vitastor has a CSI plugin for Kubernetes which supports RWO (and block RWX) volumes.
+Vitastor has a CSI plugin for Kubernetes which supports block-based and VitastorFS-based volumes.
 
-To deploy it, take manifests from [csi/deploy/](../../csi/deploy/) directory, put your
+Block-based volumes may be formatted and mounted with a normal FS (ext4 or xfs). Such volumes
+only support RWO (ReadWriteOnce) mode.
+
+Block-based volumes may also be left without FS and attached into the container as a block
+device. Such volumes also support RWX (ReadWriteMany) mode.
+
+VitastorFS-based volumes use a clustered file system and support FS-based RWX (ReadWriteMany)
+mode. However, such volumes don't support quotas and snapshots.
+
+To deploy the CSI plugin, take manifests from [csi/deploy/](../../csi/deploy/) directory, put your
 Vitastor configuration in [001-csi-config-map.yaml](../../csi/deploy/001-csi-config-map.yaml),
 configure storage class in [009-storage-class.yaml](../../csi/deploy/009-storage-class.yaml)
 and apply all `NNN-*.yaml` manifests to your Kubernetes installation:
@@ -23,16 +32,16 @@ After that you'll be able to create PersistentVolumes.
 kernel modules enabled (vdpa, vduse, virtio-vdpa). If your distribution doesn't
 have them pre-built - build them yourself ([instructions](../usage/qemu.en.md#vduse)),
 I promise it's worth it :-). When VDUSE is unavailable, CSI driver uses [NBD](../usage/nbd.en.md)
-to map Vitastor devices. NBD is slower and prone to timeout issues: if Vitastor
-cluster becomes unresponsible for more than [nbd_timeout](../config/client.en.md#nbd_timeout),
-the NBD device detaches and breaks pods using it.
+to map Vitastor devices. NBD is slower and, with kernels older than 5.19, unmountable
+if the cluster becomes unresponsible.
 
 ## Features
 
 Vitastor CSI supports:
 - Kubernetes starting with 1.20 (or 1.17 for older vitastor-csi <= 1.1.0)
-- Filesystem RWO (ReadWriteOnce) volumes. Example: [PVC](../../csi/deploy/example-pvc.yaml), [pod](../../csi/deploy/example-test-pod.yaml)
+- Block-based FS-formatted RWO (ReadWriteOnce) volumes. Example: [PVC](../../csi/deploy/example-pvc.yaml), [pod](../../csi/deploy/example-test-pod.yaml)
 - Raw block RWX (ReadWriteMany) volumes. Example: [PVC](../../csi/deploy/example-pvc-block.yaml), [pod](../../csi/deploy/example-test-pod-block.yaml)
+- VitastorFS-based volumes RWX (ReadWriteMany) volumes. Example: [storage class](../../csi/deploy/example-storage-class-fs.yaml)
 - Volume expansion
 - Volume snapshots. Example: [snapshot class](../../csi/deploy/example-snapshot-class.yaml), [snapshot](../../csi/deploy/example-snapshot.yaml), [clone](../../csi/deploy/example-snapshot-clone.yaml)
 - [VDUSE](../usage/qemu.en.md#vduse) (preferred) and [NBD](../usage/nbd.en.md) device mapping methods

docs/installation/kubernetes.ru.md

@@ -6,7 +6,17 @@
 
 # Kubernetes CSI
 
-У Vitastor есть CSI-плагин для Kubernetes, поддерживающий RWO, а также блочные RWX, тома.
+У Vitastor есть CSI-плагин для Kubernetes, поддерживающий блочные тома и тома на основе
+кластерной ФС VitastorFS.
+
+Блочные тома могут быть отформатированы и примонтированы со стандартной ФС (ext4 или xfs).
+Такие тома поддерживают только режим RWO (ReadWriteOnce, одновременный доступ с одного узла).
+
+Блочные тома также могут не форматироваться и подключаться в контейнер в виде блочного устройства.
+В таком случае их можно подключать в режиме RWX (ReadWriteMany, одновременный доступ с многих узлов).
+
+Тома на основе VitastorFS используют кластерную ФС и поэтому также поддерживают режим RWX
+(ReadWriteMany). Однако, такие тома не поддерживают ограничение размера и снимки.
 
 Для установки возьмите манифесты из директории [csi/deploy/](../../csi/deploy/), поместите
 вашу конфигурацию подключения к Vitastor в [csi/deploy/001-csi-config-map.yaml](../../csi/deploy/001-csi-config-map.yaml),
@@ -33,6 +43,7 @@ CSI-плагин Vitastor поддерживает:
 - Версии Kubernetes, начиная с 1.20 (или с 1.17 для более старых vitastor-csi <= 1.1.0)
 - Файловые RWO (ReadWriteOnce) тома. Пример: [PVC](../../csi/deploy/example-pvc.yaml), [под](../../csi/deploy/example-test-pod.yaml)
 - Сырые блочные RWX (ReadWriteMany) тома. Пример: [PVC](../../csi/deploy/example-pvc-block.yaml), [под](../../csi/deploy/example-test-pod-block.yaml)
+- Основанные на VitastorFS RWX (ReadWriteMany) тома. Пример: [класс хранения](../../csi/deploy/example-storage-class-fs.yaml)
 - Расширение размера томов
 - Снимки томов. Пример: [класс снимков](../../csi/deploy/example-snapshot-class.yaml), [снимок](../../csi/deploy/example-snapshot.yaml), [клон снимка](../../csi/deploy/example-snapshot-clone.yaml)
 - Способы подключения устройств [VDUSE](../usage/qemu.ru.md#vduse) (предпочитаемый) и [NBD](../usage/nbd.ru.md)

docs/installation/opennebula.en.md

@@ -4,6 +4,8 @@
 
 [Читать на русском](opennebula.ru.md)
 
+# OpenNebula
+
 ## Automatic Installation
 
 OpenNebula plugin is packaged as `vitastor-opennebula` Debian and RPM package since Vitastor 1.9.0. So:

docs/installation/opennebula.ru.md

@@ -4,6 +4,8 @@
 
 [Read in English](opennebula.en.md)
 
+# OpenNebula
+
 ## Автоматическая установка
 
 Плагин OpenNebula Vitastor распространяется как Debian и RPM пакет `vitastor-opennebula`, начиная с версии Vitastor 1.9.0. Так что:

docs/installation/packages.en.md

@@ -14,6 +14,7 @@
   - Debian 12 (Bookworm/Sid): `deb https://vitastor.io/debian bookworm main`
   - Debian 11 (Bullseye): `deb https://vitastor.io/debian bullseye main`
   - Debian 10 (Buster): `deb https://vitastor.io/debian buster main`
+  - Ubuntu 22.04 (Jammy): `deb https://vitastor.io/debian jammy main`
   - Add `-oldstable` to bookworm/bullseye/buster in this line to install the last
     stable version from 0.9.x branch instead of 1.x
 - Install packages: `apt update; apt install vitastor lp-solve etcd linux-image-amd64 qemu-system-x86`

docs/installation/packages.ru.md

@@ -14,6 +14,7 @@
   - Debian 12 (Bookworm/Sid): `deb https://vitastor.io/debian bookworm main`
   - Debian 11 (Bullseye): `deb https://vitastor.io/debian bullseye main`
   - Debian 10 (Buster): `deb https://vitastor.io/debian buster main`
+  - Ubuntu 22.04 (Jammy): `deb https://vitastor.io/debian jammy main`
   - Добавьте `-oldstable` к слову bookworm/bullseye/buster в этой строке, чтобы
     установить последнюю стабильную версию из ветки 0.9.x вместо 1.x
 - Установите пакеты: `apt update; apt install vitastor lp-solve etcd linux-image-amd64 qemu-system-x86`

docs/installation/proxmox.en.md

@@ -6,10 +6,10 @@
 
 # Proxmox VE
 
-To enable Vitastor support in Proxmox Virtual Environment (6.4-8.1 are supported):
+To enable Vitastor support in Proxmox Virtual Environment (6.4-8.x are supported):
 
 - Add the corresponding Vitastor Debian repository into sources.list on Proxmox hosts:
-  bookworm for 8.1, pve8.0 for 8.0, bullseye for 7.4, pve7.3 for 7.3, pve7.2 for 7.2, pve7.1 for 7.1, buster for 6.4
+  bookworm for 8.1+, pve8.0 for 8.0, bullseye for 7.4, pve7.3 for 7.3, pve7.2 for 7.2, pve7.1 for 7.1, buster for 6.4
 - Install vitastor-client, pve-qemu-kvm, pve-storage-vitastor (* or see note) packages from Vitastor repository
 - Define storage in `/etc/pve/storage.cfg` (see below)
 - Block network access from VMs to Vitastor network (to OSDs and etcd),

docs/installation/proxmox.ru.md

@@ -6,10 +6,10 @@
 
 # Proxmox VE
 
-Чтобы подключить Vitastor к Proxmox Virtual Environment (поддерживаются версии 6.4-8.1):
+Чтобы подключить Vitastor к Proxmox Virtual Environment (поддерживаются версии 6.4-8.x):
 
 - Добавьте соответствующий Debian-репозиторий Vitastor в sources.list на хостах Proxmox:
-  bookworm для 8.1, pve8.0 для 8.0, bullseye для 7.4, pve7.3 для 7.3, pve7.2 для 7.2, pve7.1 для 7.1, buster для 6.4
+  bookworm для 8.1+, pve8.0 для 8.0, bullseye для 7.4, pve7.3 для 7.3, pve7.2 для 7.2, pve7.1 для 7.1, buster для 6.4
 - Установите пакеты vitastor-client, pve-qemu-kvm, pve-storage-vitastor (* или см. сноску) из репозитория Vitastor
 - Определите тип хранилища в `/etc/pve/storage.cfg` (см. ниже)
 - Обязательно заблокируйте доступ от виртуальных машин к сети Vitastor (OSD и etcd), т.к. Vitastor (пока) не поддерживает аутентификацию

docs/installation/s3.en.md

@@ -0,0 +1,191 @@
+[Documentation](../../README.md#documentation) → Installation → S3 for Vitastor
+
+-----
+
+[Читать на русском](s3.ru.md)
+
+# S3 for Vitastor
+
+The moment has come - Vitastor S3 implementation based on Zenko CloudServer is released.
+
+## Highlights
+
+- Zenko CloudServer is implemented in node.js.
+- Object metadata is stored in MongoDB.
+- Modified Zenko CloudServer version is used for Vitastor. It is slightly different from
+  the original, has an optimised build and unneeded dependencies are stripped off.
+- Object data is stored in Vitastor block volumes, but the volume metadata is stored in
+  the same MongoDB, not in Vitastor etcd.
+- Objects are written to volumes sequentially one after another. The space is allocated
+  with rounding to the sector size (4 KB), so each object takes at least 4 KB.
+- An important property of such storage scheme is that small objects aren't chunked into
+  parts in Vitastor EC N+K pools and thus don't require reads from all N disks when
+  downloading.
+- Deleted objects are marked as deleted, but the space is only actually freed during
+  asynchronously executed "defragmentation" process. Defragmentation runs automatically
+  in the background when a volume reaches configured amount of "garbage" (20% by default).
+  Defragmentation copies actual objects to new volume(s) and then removes the old volume.
+  Defragmentation can be configured in locationConfig.json.
+
+## Plans for future development
+
+- User account storage in the DB instead of a static file. Original Zenko uses
+  a separate closed-source "Scality Vault" service for it, that's why we use
+  a static file for now.
+- More detailed documentation.
+- Support for other (and faster) key-value DBMS for object metadata storage.
+- Other performance optimisations, for example, related to the used hash function -
+  MD5 used for Amazon compatibility purposes is relatively slow.
+- Object Lifecycle support. There is a Lifecycle implementation for Zenko called
+  [Backbeat](https://github.com/scality/backbeat) but it's not adapted for Vitastor yet.
+- Quota support. Original Zenko uses a separate "SCUBA" service for quotas, but
+  it's also proprietary and not available publicly.
+
+## Installation
+
+In a few words:
+
+- Install MongoDB, create a user for S3 metadata DB.
+- Create a Vitastor pool for S3 data.
+- Download and setup the Docker container `vitalif/vitastor-zenko`.
+
+### Setup MongoDB
+
+You can setup MongoDB yourself, following the [MongoDB manual](https://www.mongodb.com/docs/manual/installation/).
+
+Or you can follow the instructions below - it describes a simple example of MongoDB setup
+in Docker (through docker-compose) with 3 replicas.
+
+1. On each host, create a file `docker-compose.yml` with the content listed below.
+   Replace `<YOUR_PASSWORD>` with your future mongodb administrator password, and optionally
+   replace `0.0.0.0` with `localhost,<server_IP>`. It's recommended to either use a private IP
+   or [setup TLS](https://www.mongodb.com/docs/manual/tutorial/configure-ssl/) afterwards.
+
+```
+version: '3.1'
+
+services:
+
+  mongo:
+    container_name: mongo
+    image: mongo:7-jammy
+    restart: always
+    environment:
+      MONGO_INITDB_ROOT_USERNAME: root
+      MONGO_INITDB_ROOT_PASSWORD: <YOUR_PASSWORD>
+    network_mode: host
+    volumes:
+      - ./keyfile:/opt/keyfile
+      - ./mongo-data/db:/data/db
+      - ./mongo-data/configdb:/data/configdb
+    entrypoint: /bin/bash -c
+    command: [ "chown mongodb /opt/keyfile && chmod 600 /opt/keyfile && . /usr/local/bin/docker-entrypoint.sh mongod --replSet rs0 --keyFile /opt/keyfile --bind_ip 0.0.0.0" ]
+```
+
+2. Generate a shared cluster key using `openssl rand -base64 756 > ./keyfile` and copy
+   that `keyfile` to all hosts.
+
+3. Start MongoDB on all hosts with `docker compose up -d mongo`.
+
+4. Enter Mongo Shell with `docker exec -it mongo mongosh -u root -p <YOUR_PASSWORD> localhost/admin`
+   and execute the following command (replace IP addresses `10.10.10.{1,2,3}` with your host IPs):
+
+`rs.initiate({ _id: 'rs0', members: [
+  { _id: 1, host: '10.10.10.1:27017' },
+  { _id: 2, host: '10.10.10.2:27017' },
+  { _id: 3, host: '10.10.10.3:27017' }
+] })`
+
+5. Stay in Mongo Shell and create a user for the future S3 database:
+
+`db.createUser({ user: 's3', pwd: '<YOUR_S3_PASSWORD>', roles: [
+  { role: 'readWrite', db: 's3' },
+  { role: 'dbAdmin', db: 's3' },
+  { role: 'readWrite', db: 'vitastor' },
+  { role: 'dbAdmin', db: 'vitastor' }
+] })`
+
+### Setup Vitastor
+
+Create a pool in Vitastor for S3 object data, for example:
+
+`vitastor-cli create-pool --ec 2+1 -n 512 s3-data --used_for_app s3:standard`
+
+The `--used_for_app` options works as fool-proofing and prevents you from
+accidentally creating a regular block volume in the S3 pool and overwriting some S3 data.
+Also it hides inode space statistics from Vitastor etcd.
+
+Retrieve the ID of your pool with `vitastor-cli ls-pools s3-data --detail`.
+
+### Setup Vitastor S3
+
+1. Add the following lines to `docker-compose.yml` (instead of `network_mode: host`,
+   you can use `ports: [ "8000:8000", "8002:8002" ]`):
+
+```
+  zenko:
+    container_name: zenko
+    image: vitalif/vitastor-zenko
+    restart: always
+    security_opt:
+      - seccomp:unconfined
+    ulimits:
+      memlock: -1
+    network_mode: host
+    volumes:
+      - /etc/vitastor:/etc/vitastor
+      - /etc/vitastor/s3:/conf
+```
+
+2. Download Docker image: `docker pull vitalif/vitastor-zenko`
+
+3. Extract configuration file examples from the Docker image:
+   ```
+   docker run --rm -it -v /etc/vitastor:/etc/vitastor -v /etc/vitastor/s3:/conf vitalif/vitastor-zenko configure.sh
+   ```
+
+4. Edit configuration files in `/etc/vitastor/s3/`:
+   - `config.json` - common settings.
+   - `authdata.json` - user accounts and access keys.
+   - `locationConfig.json` - S3 storage class list with placement settings.
+     Note: it actually contains storage classes (like STANDARD, COLD, etc)
+     instead of "locations" (zones like us-east-1) as in the original Zenko CloudServer.
+   - Put your MongoDB connection data into `config.json` and `locationConfig.json`.
+   - Put your Vitastor pool ID into `locationConfig.json`.
+   - For now, the complete list of Vitastor backend settings is only available [in the code](https://git.yourcmc.ru/vitalif/zenko-arsenal/src/branch/master/lib/storage/data/vitastor/VitastorBackend.ts#L94).
+
+### Start Zenko
+
+Start the S3 server with:
+
+```
+docker run --restart always --security-opt seccomp:unconfined --ulimit memlock=-1 --network=host \
+    -v /etc/vitastor:/etc/vitastor -v /etc/vitastor/s3:/conf --name zenko vitalif/vitastor-zenko
+```
+
+If you use default settings, Zenko CloudServer starts on port 8000.
+The default access key is `accessKey1` with a secret key of `verySecretKey1`.
+
+Now you can access your S3 with, for example, [s3cmd](https://s3tools.org/s3cmd):
+
+```
+s3cmd --access_key=accessKey1 --secret_key=verySecretKey1 --host=http://localhost:8000 mb s3://testbucket
+```
+
+Or even mount it with [GeeseFS](https://github.com/yandex-cloud/geesefs):
+
+```
+AWS_ACCESS_KEY_ID=accessKey1 \
+    AWS_SECRET_ACCESS_KEY=verySecretKey1 \
+    geesefs --endpoint http://localhost:8000 testbucket mountdir
+```
+
+## Author & License
+
+- [Zenko CloudServer](https://s3-server.readthedocs.io/en/latest/) author is Scality,
+  licensed under [Apache License, version 2.0](https://www.apache.org/licenses/LICENSE-2.0)
+- [Vitastor](https://git.yourcmc.ru/vitalif/vitastor/) and Zenko Vitastor backend author is
+  Vitaliy Filippov, licensed under [VNPL-1.1](https://git.yourcmc.ru/vitalif/vitastor/src/branch/master/VNPL-1.1.txt)
+  (a "network copyleft" license based on AGPL/SSPL, but worded in a better way)
+- Vitastor S3 repository: https://git.yourcmc.ru/vitalif/zenko-cloudserver-vitastor
+- Vitastor S3 backend code: https://git.yourcmc.ru/vitalif/zenko-arsenal/src/branch/master/lib/storage/data/vitastor/VitastorBackend.ts

docs/installation/s3.ru.md

@@ -0,0 +1,171 @@
+[Документация](../../README-ru.md#документация) → Установка → S3 на базе Vitastor
+
+-----
+
+[Read in English](s3.en.md)
+
+# S3 на базе Vitastor
+
+Итак, свершилось - реализация Vitastor S3 на базе Zenko CloudServer достигла
+состояния готовности к публикации и использованию.
+
+## Ключевые особенности
+
+- Zenko CloudServer реализован на node.js.
+- Метаданные объектов хранятся в MongoDB.
+- Поставляется модифицированная версия Zenko CloudServer, отвязанная от лишних зависимостей,
+  с оптимизированной сборкой и немного отличающаяся от оригинала.
+- Данные объектов хранятся в блочных томах Vitastor, однако информация о самих томах
+  сохраняется не в etcd Vitastor, а тоже в БД на основе MongoDB.
+- Объекты записываются в тома последовательно друг за другом. Место выделяется с округлением
+  до размера сектора (до 4 килобайт), поэтому каждый объект занимает как минимум 4 КБ.
+- Благодаря такой схеме записи объектов мелкие объекты не нарезаются на части и поэтому не
+  требуют чтения с N дисков данных в EC N+K пулах Vitastor.
+- При удалении объекты помечаются удалёнными, но место освобождается не сразу, а при
+  запускаемой асинхронно "дефрагментации". Дефрагментация запускается автоматически в фоне
+  при достижении заданного объёма "мусора" в томе (по умолчанию 20%), копирует актуальные
+  объекты в новые тома, после чего очищает старый том полностью. Дефрагментацию можно
+  настраивать в locationConfig.json.
+
+## Планы развития
+
+- Хранение учётных записей в БД, а не в статическом файле (в оригинальном Zenko для
+  этого используется отдельный закрытый сервис "Scality Vault").
+- Более подробная документация.
+- Поддержка других (и более производительных) key-value СУБД для хранения метаданных.
+- Другие оптимизации производительности, например, в области используемой хеш-функции
+  (хеш MD5, используемый в целях совместимости, относительно медленный).
+- Поддержка Object Lifecycle. Реализация Lifecycle для Zenko существует и называется
+  [Backbeat](https://github.com/scality/backbeat), но она ещё не адаптирована для Vitastor.
+- Квоты. В оригинальном Zenko для этого используется отдельный сервис "SCUBA", однако
+  он тоже является закрытым и недоступен для публичного использования.
+
+## Установка
+
+Кратко:
+
+- Установите MongoDB, создайте пользователя для БД метаданных S3.
+- Создайте в Vitastor пул для хранения данных объектов.
+- Скачайте и настройте Docker-контейнер `vitalif/vitastor-zenko`.
+
+### Установка MongoDB
+
+Вы можете установить MongoDB сами, следуя [официальному руководству MongoDB](https://www.mongodb.com/docs/manual/installation/).
+
+Либо вы можете последовать инструкции, приведённой ниже - здесь описан простейший пример
+установки MongoDB в Docker (docker-compose) в конфигурации с 3 репликами.
+
+1. На всех 3 серверах создайте файл `docker-compose.yml`, заменив `<ВАШ_ПАРОЛЬ>`
+   на собственный будущий пароль администратора mongodb, а `0.0.0.0` по желанию
+   заменив на на `localhost,<IP_сервера>` - желательно либо использовать публично не доступный IP,
+   либо потом [настроить TLS](https://www.mongodb.com/docs/manual/tutorial/configure-ssl/).
+
+```
+version: '3.1'
+
+services:
+
+  mongo:
+    container_name: mongo
+    image: mongo:7-jammy
+    restart: always
+    environment:
+      MONGO_INITDB_ROOT_USERNAME: root
+      MONGO_INITDB_ROOT_PASSWORD: <ВАШ_ПАРОЛЬ>
+    network_mode: host
+    volumes:
+      - ./keyfile:/opt/keyfile
+      - ./mongo-data/db:/data/db
+      - ./mongo-data/configdb:/data/configdb
+    entrypoint: /bin/bash -c
+    command: [ "chown mongodb /opt/keyfile && chmod 600 /opt/keyfile && . /usr/local/bin/docker-entrypoint.sh mongod --replSet rs0 --keyFile /opt/keyfile --bind_ip 0.0.0.0" ]
+```
+
+2. В той же директории сгенерируйте общий ключ кластера командой `openssl rand -base64 756 > ./keyfile`
+   и скопируйте этот файл на все 3 сервера.
+
+3. На всех 3 серверах запустите MongoDB командой `docker compose up -d mongo`.
+
+4. Зайдите в Mongo Shell с помощью команды `docker exec -it mongo mongosh -u root -p <ВАШ_ПАРОЛЬ> localhost/admin`
+   и там выполните команду (заменив IP-адреса `10.10.10.{1,2,3}` на адреса своих серверов):
+
+`rs.initiate({ _id: 'rs0', members: [
+  { _id: 1, host: '10.10.10.1:27017' },
+  { _id: 2, host: '10.10.10.2:27017' },
+  { _id: 3, host: '10.10.10.3:27017' }
+] })`
+
+5. Находясь там же, в Mongo Shell, создайте пользователя с доступом к будущей базе данных S3:
+
+`db.createUser({ user: 's3', pwd: '<ВАШ_ПАРОЛЬ_S3>', roles: [
+  { role: 'readWrite', db: 's3' },
+  { role: 'dbAdmin', db: 's3' },
+  { role: 'readWrite', db: 'vitastor' },
+  { role: 'dbAdmin', db: 'vitastor' }
+] })`
+
+### Настройка Vitastor
+
+Создайте в Vitastor отдельный пул для данных объектов S3, например:
+
+`vitastor-cli create-pool --ec 2+1 -n 512 s3-data --used_for_app s3:standard`
+
+Опция `--used_for_app` работает как "защита от дурака" и не даёт вам случайно создать
+в этом пуле обычный блочный том и перезаписать им какие-то данные S3, а также скрывает
+статистику занятого места по томам S3 из etcd.
+
+Получите ID своего пула с помощью команды `vitastor-cli ls-pools --detail`.
+
+### Установка Vitastor S3
+
+1. Добавьте в `docker-compose.yml` строки (альтернативно вместо `network_mode: host`
+   можно использовать `ports: [ "8000:8000", "8002:8002" ]`):
+
+```
+  zenko:
+    container_name: zenko
+    image: vitalif/vitastor-zenko
+    restart: always
+    security_opt:
+      - seccomp:unconfined
+    ulimits:
+      memlock: -1
+    network_mode: host
+    volumes:
+      - /etc/vitastor:/etc/vitastor
+      - /etc/vitastor/s3:/conf
+```
+
+2. Извлеките из Docker-образа Vitastor примеры файлов конфигурации:
+   `docker run --rm -it -v /etc/vitastor:/etc/vitastor -v /etc/vitastor/s3:/conf vitalif/vitastor-zenko configure.sh`
+
+3. Отредактируйте файлы конфигурации в `/etc/vitastor/s3/`:
+   - `config.json` - общие настройки.
+   - `authdata.json` - учётные записи и ключи доступа.
+   - `locationConfig.json` - список классов хранения S3 с настройками расположения.
+     Внимание: в данной версии это именно список S3 storage class-ов (STANDARD, COLD и т.п.),
+     а не зон (подобных us-east-1), как в оригинальном Zenko CloudServer.
+   - В `config.json` и в `locationConfig.json` пропишите свои данные подключения к MongoDB.
+   - В `locationConfig.json` укажите ID пула Vitastor для хранения данных.
+   - Полный перечень настроек Vitastor-бэкенда пока можно посмотреть [в коде](https://git.yourcmc.ru/vitalif/zenko-arsenal/src/branch/master/lib/storage/data/vitastor/VitastorBackend.ts#L94).
+
+### Запуск
+
+Запустите S3-сервер: `docker-compose up -d zenko`
+
+Готово! Вы получили S3-сервер, работающий на порту 8000.
+
+Можете попробовать обратиться к нему с помощью, например, [s3cmd](https://s3tools.org/s3cmd):
+
+`s3cmd --host-bucket= --no-ssl --access_key=accessKey1 --secret_key=verySecretKey1 --host=http://localhost:8000 mb s3://testbucket`
+
+Или смонтировать его с помощью [GeeseFS](https://github.com/yandex-cloud/geesefs):
+
+`AWS_ACCESS_KEY_ID=accessKey1 AWS_SECRET_ACCESS_KEY=verySecretKey1 geesefs --endpoint http://localhost:8000 testbucket /mnt/geesefs`
+
+## Лицензия
+
+- Автор [Zenko CloudServer](https://s3-server.readthedocs.io/en/latest/) - Scality, лицензия [Apache 2.0](https://www.apache.org/licenses/LICENSE-2.0)
+- Vitastor-бэкенд для S3, как и сам Vitastor, лицензируется на условиях [VNPL 1.1](https://git.yourcmc.ru/vitalif/vitastor/src/branch/master/VNPL-1.1.txt)
+- Репозиторий сборки: https://git.yourcmc.ru/vitalif/zenko-cloudserver-vitastor
+- Бэкенд хранения данных: https://git.yourcmc.ru/vitalif/zenko-arsenal/src/branch/master/lib/storage/data/vitastor/VitastorBackend.ts

docs/installation/source.en.md

@@ -16,7 +16,7 @@
   designated initializers support from C++20
 - CMake
 - liburing, jerasure headers and libraries
-- ISA-L, libibverbs headers and libraries (optional)
+- ISA-L, libibverbs and librdmacm headers and libraries (optional)
 - tcmalloc (google-perftools-dev)
 
 ## Basic instructions

docs/installation/source.ru.md

@@ -16,7 +16,7 @@
   назначенных инициализаторов (designated initializers) из C++20
 - CMake
 - Заголовки и библиотеки liburing, jerasure
-- Опционально - заголовки и библиотеки ISA-L, libibverbs
+- Опционально - заголовки и библиотеки ISA-L, libibverbs, librdmacm
 - tcmalloc (google-perftools-dev)
 
 ## Базовая инструкция

docs/intro/architecture.en.md

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

docs/intro/architecture.ru.md

@@ -11,6 +11,7 @@
 - [Серверные компоненты](#серверные-компоненты)
 - [Базовые понятия](#базовые-понятия)
 - [Клиентские компоненты](#клиентские-компоненты)
+- [Дополнительные утилиты](#дополнительные-утилиты)
 - [Общий процесс записи и чтения](#общий-процесс-записи-и-чтения)
   - [Особенности обработки запросов](#особенности-обработки-запросов)
 - [Схожесть с Ceph](#схожесть-с-ceph)
@@ -23,8 +24,8 @@
   Один OSD управляет одним диском (или разделом). OSD общаются с etcd и друг с другом — от etcd они
   получают состояние кластера, а друг другу передают запросы записи и чтения вторичных копий данных.
 - **etcd** — кластерная key/value база данных, используется для хранения настроек и верхнеуровневого
-  состояния кластера, а также предотвращения разделения сознания. Блоки данных в etcd не хранятся,
-  в обработке клиентских запросов чтения и записи etcd не участвует.
+  состояния кластера, а также предотвращения разделения сознания (splitbrain). Блоки данных в etcd не
+  хранятся, в обработке клиентских запросов чтения и записи etcd не участвует.
 - **Монитор** — отдельный демон на node.js, рассчитывающий необходимые изменения в конфигурацию
   кластера, сохраняющий эту информацию в etcd и таким образом командующий OSD применить эти изменения.
   Также агрегирует статистику. Контактирует только с etcd, OSD с монитором не общаются.
@@ -34,40 +35,56 @@
 - **Пул (Pool)** — контейнер для данных, имеющих одну и ту же схему избыточности и правила распределения по OSD.
 - **PG (Placement Group)** — "шард", единица деления пулов в кластере, которой назначается свой набор
   OSD для хранения данных (копий или частей объектов).
-- **Домен отказа (Failure Domain)** — группа OSD, одновременное падение которых рассматривается
-  как вероятное. По умолчанию это "host" (сервер).
+- **Домен отказа (Failure Domain)** — группа OSD, от одновременного падения которых должен защищать
+  Vitastor. По умолчанию домен отказа — "host" (сервер), но вы можете установить для пула как больший
+  домен отказа (например, стойку серверов), так и меньший (например, отдельный диск).
 - **Дерево распределения** (Placement Tree, в Ceph CRUSH Tree) — иерархическая группировка OSD
   в узлы, которые далее можно использовать как домены отказа.
 
 ## Клиентские компоненты
 
-- **Клиентская библиотека** — инкапсулирует логику на стороне клиента. Соединяются с etcd и со всеми OSD,
-  от etcd получают состояние кластера, команды чтения и записи отправляют на все OSD напрямую.
+- **Клиентская библиотека** — инкапсулирует логику на стороне клиента. Соединяется с etcd и со всеми OSD,
+  от etcd получает состояние кластера, команды чтения и записи отправляет на все OSD напрямую.
   В силу архитектуры все отдельные блоки данных (по умолчанию по 128 КБ) располагается на разных
   OSD, но клиент устроен так, что всегда точно знает, к какому OSD обращаться, и подключается
   к нему напрямую.
 
 На базе клиентской библиотеки реализованы все остальные клиенты:
 
-- **vitastor-cli** — утилита командной строки для управления кластером. В данный момент позволяет
-  просматривать общее состояние кластера и управлять образами — т.е. создавать, менять и удалять
-  виртуальные диски, их снимки и клоны.
-- **Драйвер QEMU** — подключаемый модуль QEMU, позволяющий QEMU/KVM виртуальным машинам работать
-  с виртуальными дисками Vitastor напрямую из пространства пользователя с помощью клиентской
-  библиотеки, без необходимости отображения дисков в виде блочных устройств. Тот же драйвер
-  позволяет подключать диски в систему через [VDUSE](../usage/qemu.ru.md#vduse).
-- **vitastor-nbd** — утилита, позволяющая монтировать образы Vitastor в виде блочных устройств
-  с помощью NBD (Network Block Device), на самом деле скорее работающего как "BUSE"
-  (Block Device In Userspace). Модуля ядра Linux для выполнения той же задачи в Vitastor нет
-  (по крайней мере, пока).
-- **CSI драйвер** — драйвер для подключения Vitastor-образов в виде персистентных томов (PV) Kubernetes.
-  Работает через vitastor-nbd — образы отражаются в виде блочных устройств и монтируются
-  в контейнеры.
+- **[vitastor-cli](../usage/cli.ru.md)** — утилита командной строки для управления кластером.
+  Позволяет просматривать общее состояние кластера, управлять пулами и образами — то есть
+  создавать, менять и удалять виртуальные диски, их снимки и клоны.
+- **[Драйвер QEMU](../usage/qemu.ru.md)** — подключаемый модуль QEMU, позволяющий QEMU/KVM
+  виртуальным машинам работать с виртуальными дисками Vitastor напрямую из пространства пользователя
+  с помощью клиентской библиотеки, без необходимости подключения дисков в виде блочных устройств
+  Linux. Если, однако, вы хотите подключать диски в виде блочных устройств, то вы тоже можете
+  сделать это с помощью того же самого драйвера и [VDUSE](../usage/qemu.ru.md#vduse).
+- **[vitastor-nbd](../usage/nbd.ru.md)** — утилита, позволяющая монтировать образы Vitastor
+  в виде блочных устройств с помощью NBD (Network Block Device), на самом деле скорее работающего
+  как "BUSE" (Block Device In Userspace). Модуля ядра Linux для выполнения той же задачи в
+  Vitastor нет (по крайней мере, пока). NBD — более старый и нерекомендуемый способ подключения
+  дисков — вам следует использовать VDUSE всегда, когда это возможно.
+- **[CSI драйвер](../installation/kubernetes.ru.md)** — драйвер для подключения Vitastor-образов
+  и поддиректорий VitastorFS в виде персистентных томов (PV) Kubernetes. Блочный CSI работает через
+  VDUSE (когда это возможно) или через NBD — образы отражаются в виде блочных устройств и монтируются
+  в контейнеры. Файловый CSI использует **[vitastor-nfs](../usage/nfs.ru.md)**.
 - **Драйвера Proxmox, OpenStack и т.п.** — подключаемые модули для соответствующих систем,
   позволяющие использовать Vitastor как хранилище в оных.
-- **vitastor-nfs** — утилита, предоставляющая файловый доступ к образам в кластере Vitastor
-  по протоколу NFS 3.0. Предназначена для гипервизоров, не основанных на QEMU и Linux, но при
-  этом поддерживающих NFS.
+- **[vitastor-nfs](../usage/nfs.ru.md)** — NFS 3.0 сервер, предоставляющий два варианта файловой системы:
+  первая — упрощённая для файлового доступа к блочным образам (для не-QEMU гипервизоров, поддерживающих NFS),
+  вторая — VitastorFS, полноценная кластерная POSIX ФС. Оба варианта поддерживают параллельный
+  доступ с нескольких vitastor-nfs серверов. На самом деле можно вообще не выделять
+  отдельные NFS-серверы, а вместо этого использовать команду vitastor-nfs mount, запускающую
+  NFS-сервер прямо на клиентской машине и монтирующую ФС локально.
+- **[Драйвер fio](../usage/fio.ru.md)** — подключаемый модуль для утилиты тестирования
+  производительности дисков fio, позволяющий тестировать Vitastor-кластеры.
+- **vitastor-kv** — клиент для key-value базы данных, работающей поверх разделяемого блочного
+  образа (обычного блочного образа vitastor). Метаданные VitastorFS хранятся именно в vitastor-kv.
+
+## Дополнительные утилиты
+
+- **vitastor-disk** — утилита для разметки дисков под Vitastor OSD. С её помощью можно
+  создавать, удалять, менять размеры или перемещать разделы OSD.
 
 ## Общий процесс записи и чтения
 
@@ -98,16 +115,28 @@
   находиться на других OSD, если эти объекты деградированы или перемещены, или идёт процесс
   ребаланса. Запросы для проверки по сети не отправляются, информация о местоположении всех
   объектов рассчитывается первичным OSD при активации PG и хранится в памяти.
-- Первичный OSD соединяется (если ещё не соединён) с вторичными OSD, на которых располагаются
-  части объекта, и отправляет им запросы чтения/записи, а также читает/пишет из/в своё локальное
-  хранилище, если сам входит в набор.
+- Когда это возможно, первичный OSD обрабатывает запрос локально. Например, так происходит
+  при чтениях объектов из пулов с репликацией или при чтении из EC пула, затрагивающего
+  только часть, хранимую на диске самого первичного OSD.
+- Когда запрос требует записи или чтения с вторичных OSD, первичный OSD использует заранее
+  установленные соединения с ними для выполнения этих запросов. Это происходит параллельно
+  локальным операциям чтения/записи с диска самого OSD. Так как соединения к вторичным OSD PG
+  устанавливаются при её запуске, то они уже гарантированно установлены, когда PG активна,
+  и если любое из этих соединений отключается, PG перезапускается, а все текущие запросы чтения
+  и записи в неё завершаются с ошибкой EPIPE, после чего повторяются клиентами.
 - После завершения всех вторичных операций чтения/записи первичный OSD отправляет ответ клиенту.
+- Если в реплицированном пуле включены [локализованные чтения](../config/pool.ru.md#local_reads),
+  а PG находится в чистом активном состоянии (active или active+left_on_dead), клиент может
+  послать запрос к одному из вторичных OSD вместо первичного. Вторичный OSD проверяет
+  [блокировку PG](../config/osd.ru.md#enable_pg_locks) и обрабатывает запрос локально, не
+  обращаясь к первичному. Блокировка PG здесь нужна, чтобы вторичный OSD мог точно знать,
+  что PG находится в чистом состоянии и не переключается на другой первичный OSD.
 
 ### Особенности обработки запросов
 
 - Если в пуле используются коды коррекции ошибок и при этом часть OSD недоступна, первичный
   OSD при чтении восстанавливает данные из оставшихся частей.
-- Каждый объект имеет номер версии. При записи объекта первичный OSD сначала читает из номер
+- Каждый объект имеет номер версии. При записи объекта первичный OSD сначала получает номер
   версии объекта. Так как первичный OSD обычно сам хранит копию или часть объекта, номер
   версии обычно читается из памяти самого OSD. Однако, если ни одна часть обновляемого объекта
   не находится на первичном OSD, для получения номера версии он обращается к одному из вторичных
@@ -115,20 +144,20 @@
   так как метаданные объектов, включая номер версии, все OSD хранят в памяти.
 - Если в пуле используются коды коррекции ошибок, перед частичной записью объекта для вычисления
   чётности зачастую требуется чтение частей объекта с вторичных OSD или с локального диска
-  самого первичного OSD.
-- Также, если в пуле используются коды коррекции ошибок, для закрытия Write Hole применяется
+  самого первичного OSD. Это называется процессом "чтение-модификация-запись" (read-modify-write).
+- Если в пуле используются коды коррекции ошибок, для закрытия Write Hole применяется
   двухфазный алгоритм записи: сначала на все вторичные OSD записывается новая версия частей
   объекта, но при этом старая версия не удаляется, а потом, после получения подтверждения
   успешной записи от всех вторичных OSD, новая версия фиксируется и разрешается удаление старой.
-- Если в кластере не включён режим immediate_commit, то запросы записи, отправляемые клиентами,
+- Если в пуле не включён режим immediate_commit, то запросы записи, отправляемые клиентами,
   не считаются зафиксированными на физических накопителях сразу. Для фиксации данных клиенты
   должны отдельно отправлять запросы SYNC (отдельный от чтения и записи вид запроса),
   а пока такой запрос не отправлен, считается, что записанные данные могут исчезнуть,
   если соответствующий OSD упадёт. Поэтому, когда режим immediate_commit отключён, все
   запросы записи клиенты копируют в памяти и при потере соединения и повторном соединении
-  с OSD повторяют из памяти. Скопированные в память данные удаляются при успешном fsync,
+  с OSD повторяют из памяти. Скопированные в память данные удаляются при успешном SYNC,
   а чтобы хранение этих данных не приводило к чрезмерному потреблению памяти, клиенты
-  автоматически выполняют fsync каждые [client_dirty_limit](../config/network.ru.md#client_dirty_limit)
+  автоматически выполняют SYNC каждые [client_dirty_limit](../config/network.ru.md#client_dirty_limit)
   записанных байт.
 
 ## Схожесть с Ceph
@@ -205,5 +234,5 @@
 - Удаление образов в деградированном кластере может в данный момент приводить к повторному
   "появлению" удалённых объектов после поднятия отключённых OSD, причём в случае EC-пулов,
   объекты могут появиться в виде "неполных". Если вы столкнётесь с такой ситуацией, просто
-  повторите запрос удаления. Исправление этой проблемы уже реализовано в ветке "epoch-deletions"
-  и вскоре будет включено в релиз.
+  повторите запрос удаления. Данная проблема будет исправлена в будущем вместе с обновлением
+  дискового формата хранения метаданных.

docs/intro/author.en.md

@@ -10,8 +10,17 @@ Copyright (c) Vitaliy Filippov (vitalif [at] yourcmc.ru), 2019+
 
 Join Vitastor Telegram Chat: https://t.me/vitastor
 
-All server-side code (OSD, Monitor and so on) is licensed under the terms of
-Vitastor Network Public License 1.1 (VNPL 1.1), a copyleft license based on
+License: VNPL 1.1 for server-side code and dual VNPL 1.1 + GPL 2.0+ for client tools.
+
+Server-side code is licensed only under the terms of VNPL.
+
+Client libraries (cluster_client and so on) are dual-licensed under the same
+VNPL 1.1 and also GNU GPL 2.0 or later to allow for compatibility with GPLed
+software like QEMU and fio.
+
+## VNPL
+
+Vitastor Network Public License 1.1 (VNPL 1.1) is a copyleft license based on
 GNU GPLv3.0 with the additional "Network Interaction" clause which requires
 opensourcing all programs directly or indirectly interacting with Vitastor
 through a computer network and expressly designed to be used in conjunction
@@ -20,18 +29,83 @@ the terms of the same license, but also under the terms of any GPL-Compatible
 Free Software License, as listed by the Free Software Foundation.
 This is a stricter copyleft license than the Affero GPL.
 
-Please note that VNPL doesn't require you to open the code of proprietary
-software running inside a VM if it's not specially designed to be used with
-Vitastor.
+The idea of VNPL is, in addition to modules linked to Vitastor code in a single
+binary file, to extend copyleft action to micro-service modules only interacting
+with it over the network.
 
 Basically, you can't use the software in a proprietary environment to provide
 its functionality to users without opensourcing all intermediary components
 standing between the user and Vitastor or purchasing a commercial license
 from the author 😀.
 
-Client libraries (cluster_client and so on) are dual-licensed under the same
-VNPL 1.1 and also GNU GPL 2.0 or later to allow for compatibility with GPLed
-software like QEMU and fio.
+At the same time, VNPL doesn't impose any restrictions on software *not specially designed*
+to be used with Vitastor, for example, on Windows running inside a VM with a Vitastor disk.
 
-You can find the full text of VNPL-1.1 in the file [VNPL-1.1.txt](../../VNPL-1.1.txt).
-GPL 2.0 is also included in this repository as [GPL-2.0.txt](../../GPL-2.0.txt).
+## Explanation
+
+Network copyleft is governed by the clause **13. Remote Network Interaction** of VNPL.
+
+A program is considered to be a "Proxy Program" if it meets both conditions:
+- It is specially designed to be used with Vitastor. Basically, it means that the program
+  has any functionality specific to Vitastor and thus "knows" that it works with Vitastor,
+  not with something random.
+- It interacts with Vitastor directly or indirectly through any programming interface,
+  including API, CLI, network or any wrapper (also considered a Proxy Program itself).
+
+If, in addition to that:
+- You give any user an apportunity to interact with Vitastor directly or indirectly through
+  any computer interface including the network or any number of wrappers (Proxy Programs).
+
+Then VNPL requires you to publish the code of all above Proxy Programs to all above users
+under the terms of any GPL-compatible license - that is, GPL, LGPL, MIT/BSD or Apache 2,
+because "GPL compatibility" is treated as an ability to legally include licensed code in
+a GPL application.
+
+So, if you have a "Proxy Program", but it's not open to the user who directly or indirectly
+interacts with Vitastor - you are forbidden to use Vitastor under the terms of VNPL and you
+need a commercial license which doesn't contain open-source requirements.
+
+## Examples
+
+- Vitastor Kubernetes CSI driver which creates PersistentVolumes by calling `vitastor-cli create`.
+  - Yes, it interacts with Vitastor through vitastor-cli.
+  - Yes, it is designed specially for use with Vitastor (it has no sense otherwise).
+  - So, CSI driver **definitely IS** a Proxy Program and must be published under the terms of
+    a free software license.
+- Windows, installed in a VM with the system disk on Vitastor storage.
+  - Yes, it interacts with Vitastor indirectly - it reads and writes data through the block
+    device interface, emulated by QEMU.
+  - No, it definitely isn't designed specially for use with Vitastor - Windows was created long
+    ago before Vitastor and doesn't know anything about it.
+  - So, Windows **definitely IS NOT** a Proxy Program and VNPL doesn't require to open it.
+- Cloud control panel which makes requests to Vitastor Kubernetes CSI driver.
+  - Yes, it interacts with Vitastor indirectly through the CSI driver, which is a Proxy Program.
+  - May or may not be designed specially for use with Vitastor. How to determine exactly?
+    Imagine that Vitastor is replaced with any other storage (for example, with a proprietary).
+    Do control panel functions change in any way? If they do (for example, if snapshots stop working),
+    then the panel contains specific functionality and thus is designed specially for use with Vitastor.
+    Otherwise, the panel is universal and isn't designed specially for Vitastor.
+  - So, whether you are required to open-source the panel also **depends** on whether it
+    contains specific functionality or not.
+
+## Why?
+
+Because I believe into the spirit of copyleft (Linux wouldn't become so popular without GPL!)
+and, at the same time, I want to have a way to monetize the product.
+
+Existing licenses including AGPL are useless for it with an SDS - SDS is a very deeply
+internal software which is almost definitely invisible to the user and thus AGPL doesn't
+require anyone to open the code even if they make a proprietary fork.
+
+And, in fact, the current situation in the world where GPL is though to only restrict direct
+linking of programs into a single executable file, isn't much correct. Nowadays, programs
+are more often linked with network API calls, not with /usr/bin/ld, and a software product
+may consist of dozens of microservices interacting with each other over the network.
+
+That's why we need VNPL to keep the license sufficiently copyleft.
+
+## License Texts
+
+- VNPL 1.1 in English: [VNPL-1.1.txt](../../VNPL-1.1.txt)
+- VNPL 1.1 in Russian: [VNPL-1.1-RU.txt](../../VNPL-1.1-RU.txt)
+- GPL 2.0: [GPL-2.0.txt](../../GPL-2.0.txt)

docs/intro/author.ru.md

@@ -12,6 +12,14 @@
 
 Лицензия: VNPL 1.1 на серверный код и двойная VNPL 1.1 + GPL 2.0+ на клиентский.
 
+Серверные компоненты распространяются только на условиях VNPL.
+
+Клиентские библиотеки распространяются на условиях двойной лицензии VNPL 1.0
+и также на условиях GNU GPL 2.0 или более поздней версии. Так сделано в целях
+совместимости с таким ПО, как QEMU и fio.
+
+## VNPL
+
 VNPL - "сетевой копилефт", собственная свободная копилефт-лицензия
 Vitastor Network Public License 1.1, основанная на GNU GPL 3.0 с дополнительным
 условием "Сетевого взаимодействия", требующим распространять все программы,
@@ -29,9 +37,70 @@ Vitastor Network Public License 1.1, основанная на GNU GPL 3.0 с д
 На Windows и любое другое ПО, не разработанное *специально* для использования
 вместе с Vitastor, никакие ограничения не накладываются.
 
-Клиентские библиотеки распространяются на условиях двойной лицензии VNPL 1.0
-и также на условиях GNU GPL 2.0 или более поздней версии. Так сделано в целях
-совместимости с таким ПО, как QEMU и fio.
+## Пояснение
 
-Вы можете найти полный текст VNPL 1.1 на английском языке в файле [VNPL-1.1.txt](../../VNPL-1.1.txt),
-VNPL 1.1 на русском языке в файле [VNPL-1.1-RU.txt](../../VNPL-1.1-RU.txt), а GPL 2.0 в файле [GPL-2.0.txt](../../GPL-2.0.txt).
+Сетевой копилефт регулируется пунктом лицензии **13. Удалённое сетевое взаимодействие**.
+
+Программа считается "прокси-программой", если верны оба условия:
+- Она создана специально для работы вместе с Vitastor. По сути это означает, что программа
+  должна иметь специфичный для Vitastor функционал, то есть, "знать", что она взаимодействует
+  именно с Vitastor.
+- Она прямо или косвенно взаимодействует с Vitastor через абсолютно любой программный
+  интерфейс, включая любые способы вызова: API, CLI, сеть или через какую-то обёртку (в
+  свою очередь тоже являющуюся прокси-программой).
+
+Если в дополнение к этому также:
+- Вы предоставляете любому пользователю возможность взаимодействовать с Vitastor по сети,
+  опять-таки, через любой интерфейс или любую серию "обёрток" (прокси-программ)
+
+То, согласно VNPL, вы должны открыть код "прокси-программ" **таким пользователям** на условиях
+любой GPL-совместимой лицензии - то есть, GPL, LGPL, MIT/BSD или Apache 2 - "совместимость с GPL"
+понимается как возможность включать лицензируемый код в GPL-приложение.
+
+Соответственно, если у вас есть "прокси-программа", но её код не открыт пользователю,
+который прямо или косвенно взаимодействует с Vitastor - вам запрещено использовать Vitastor
+на условиях VNPL и вам нужна коммерческая лицензия, не содержащая требований об открытии кода.
+
+## Примеры
+
+- Kubernetes CSI-драйвер Vitastor, создающий PersistentVolume с помощью вызова `vitastor-cli create`.
+  - Да, взаимодействует с Vitastor через vitastor-cli.
+  - Да, создавался специально для работы с Vitastor (иначе в чём же ещё его смысл).
+  - Значит, CSI-драйвер **точно считается** "прокси-программой" и должен быть открыт под свободной
+    лицензией.
+- Windows, установленный в виртуальную машину на диске Vitastor.
+  - Да, взаимодействует с Vitastor "прямо или косвенно" - пишет и читает данные через интерфейс
+    блочного устройства, эмулируемый QEMU.
+  - Нет, точно не создан *специально для работы с Vitastor* - когда его создавали, никакого
+    Vitastor ещё и в помине не было.
+  - Значит, Windows **точно не считается** "прокси-программой" и на него требования VNPL не распространяются.
+- Панель управления облака, делающая запросы к Kubernetes CSI-драйверу Vitastor.
+  - Да, взаимодействует с Vitastor косвенно через CSI-драйвер, являющийся "прокси-программой".
+  - Сходу не известно, создавалась ли конкретно для работы с Vitastor. Как понять, да или нет?
+    Представьте, что Vitastor заменён на любую другую систему хранения (например, на проприетарную).
+    Работа панели управления изменится? Если да (например, перестанут работать снапшоты) - значит,
+    панель содержит специфичный функционал и "создана специально для работы с Vitastor".
+    Если нет - значит, специфичного функционала панель не содержит и в принципе она универсальна.
+  - Нужно ли открывать панель - **зависит** от того, содержит она специфичный функционал или нет.
+
+## Почему так?
+
+Потому что я одновременно верю в дух копилефт-лицензий (Linux не стал бы так популярен,
+если бы не GPL!) и хочу иметь возможность монетизации продукта.
+
+При этом использовать даже AGPL для программной СХД бессмысленно - это глубоко внутреннее
+ПО, которое пользователь почти наверняка не увидит вообще, поэтому и открывать код никому
+никогда не придётся, даже при создании производного продукта.
+
+Да и в целом сложившаяся в мире ситуация, при которой действие GPL ограничивается только
+прямым связыванием в один исполняемый файл, не очень корректна. В настоящее время программы
+гораздо чаще интегрируют сетевыми вызовами, а не с помощью /usr/bin/ld, и общий программный
+продукт может состоять из нескольких десятков микросервисов, взаимодействующих по сети.
+
+Поэтому для сохранения достаточной "копилефтности" и придумана VNPL.
+
+## Тексты лицензий
+
+- 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)

docs/intro/features.en.md

@@ -25,10 +25,11 @@
 - Recovery of degraded blocks
 - Rebalancing (data movement between OSDs)
 - [Lazy fsync support](../config/layout-cluster.en.md#immediate_commit)
+- [Localized read support](../config/pool.en.md#local_reads) for cross-datacenter setup optimization
 - Per-OSD and per-image I/O and space usage statistics in etcd
 - Snapshots and copy-on-write image clones
 - [Write throttling to smooth random write workloads in SSD+HDD configurations](../config/osd.en.md#throttle_small_writes)
-- [RDMA/RoCEv2 support via libibverbs](../config/network.en.md#rdma_device)
+- RDMA/RoCEv2 support [via libibverbs](../config/network.en.md#use_rdma) or [RDMA-CM](../config/network.en.md#use_rdmacm)
 - [Scrubbing](../config/osd.en.md#auto_scrub) (verification of copies)
 - [Checksums](../config/layout-osd.en.md#data_csum_type)
 - [Client write-back cache](../config/client.en.md#client_enable_writeback)
@@ -36,6 +37,8 @@
 - [Clustered file system](../usage/nfs.en.md#vitastorfs)
 - [Experimental internal etcd replacement - antietcd](../config/monitor.en.md#use_antietcd)
 - [Built-in Prometheus metric exporter](../config/monitor.en.md#enable_prometheus)
+- [NFS RDMA support](../usage/nfs.en.md#rdma) (probably also usable for GPUDirect)
+- [S3](../installation/s3.en.md)
 
 ## Plugins and tools
 
@@ -62,7 +65,6 @@ The following features are planned for the future:
 - iSCSI and NVMeoF gateways
 - Multi-threaded client
 - Faster failover
-- S3
 - Tiered storage (SSD caching)
 - NVDIMM support
 - Compression (possibly)

docs/intro/features.ru.md

@@ -25,12 +25,13 @@
 - Восстановление деградированных блоков
 - Ребаланс, то есть перемещение данных между OSD (дисками)
 - [Поддержка "ленивого" fsync (fsync не на каждую операцию)](../config/layout-cluster.ru.md#immediate_commit)
+- [Локальные чтения](../config/pool.ru.md#local_reads) для оптимизации при нескольких датацентрах
 - Сбор статистики ввода/вывода в etcd
 - Статистика операций ввода/вывода и занятого места в разрезе инодов
 - Именование инодов через хранение их метаданных в etcd
 - Снапшоты и copy-on-write клоны
 - [Сглаживание производительности случайной записи в SSD+HDD конфигурациях](../config/osd.ru.md#throttle_small_writes)
-- [Поддержка RDMA/RoCEv2 через libibverbs](../config/network.ru.md#rdma_device)
+- Поддержка RDMA/RoCEv2 [через libibverbs](../config/network.ru.md#use_rdma) или [RDMA-CM](../config/network.ru.md#use_rdmacm)
 - [Фоновая проверка целостности](../config/osd.ru.md#auto_scrub) (сверка копий)
 - [Контрольные суммы](../config/layout-osd.ru.md#data_csum_type)
 - [Буферизация записи на стороне клиента](../config/client.ru.md#client_enable_writeback)
@@ -38,6 +39,8 @@
 - [Кластерная файловая система](../usage/nfs.ru.md#vitastorfs)
 - [Экспериментальная встроенная замена etcd - antietcd](../config/monitor.ru.md#use_antietcd)
 - [Встроенный Prometheus-экспортер метрик](../config/monitor.ru.md#enable_prometheus)
+- [Поддержка NFS RDMA](../usage/nfs.ru.md#rdma) (вероятно, также подходящая для GPUDirect)
+- [S3](../installation/s3.ru.md)
 
 ## Драйверы и инструменты
 
@@ -62,7 +65,6 @@
 - iSCSI и NVMeoF прокси
 - Многопоточный клиент
 - Более быстрое переключение при отказах
-- S3
 - Поддержка SSD-кэширования (tiered storage)
 - Поддержка NVDIMM
 - Возможно, сжатие

docs/intro/quickstart.en.md

@@ -26,13 +26,13 @@
   you also need small SSDs for journal and metadata (even 2 GB per 1 TB of HDD space is enough).
 - Get a fast network (at least 10 Gbit/s). Something like Mellanox ConnectX-4 with RoCEv2 is ideal.
 - Disable CPU powersaving: `cpupower idle-set -D 0 && cpupower frequency-set -g performance`.
-- [Install Vitastor packages](../installation/packages.en.md).
+- Either [install Vitastor packages](../installation/packages.en.md) or [install Vitastor in Docker](../installation/docker.en.md).
 
 ## Recommended drives
 
 - SATA SSD: Micron 5100/5200/5300/5400, Samsung PM863/PM883/PM893, Intel D3-S4510/4520/4610/4620, Kingston DC500M
 - NVMe: Micron 9100/9200/9300/9400, Micron 7300/7450, Samsung PM983/PM9A3, Samsung PM1723/1735/1743,
-  Intel DC-P3700/P4500/P4600, Intel D7-P5500/P5600, Intel Optane, Kingston DC1000B/DC1500M
+  Intel DC-P3700/P4500/P4600, Intel D5-P4320/P5530, Intel D7-P5500/P5600, Intel Optane, Kingston DC1000B/DC1500M
 - HDD: HGST Ultrastar, Toshiba MG, Seagate EXOS
 
 ## Configure monitors
@@ -45,11 +45,12 @@ On the monitor hosts:
   }
   ```
 - Create systemd units for etcd by running: `/usr/lib/vitastor/mon/make-etcd`
-- Start etcd and monitors: `systemctl enable --now etcd vitastor-mon`
+  Or, if you installed Vitastor in Docker, run `systemctl start vitastor-host; docker exec vitastor make-etcd`.
+- Start etcd and monitors: `systemctl enable --now vitastor-etcd vitastor-mon`
 
 ## Configure OSDs
 
-- Put etcd_address and osd_network into `/etc/vitastor/vitastor.conf`. Example:
+- Put etcd_address and [osd_network](../config/network.en.md#osd_network) into `/etc/vitastor/vitastor.conf`. Example:
   ```
   {
     "etcd_address": ["10.200.1.10:2379","10.200.1.11:2379","10.200.1.12:2379"],

docs/intro/quickstart.ru.md

@@ -22,18 +22,18 @@
   использовать и десктопные SSD, включив режим отложенного fsync, но производительность будет хуже.
   О конденсаторах читайте [здесь](../config/layout-cluster.ru.md#immediate_commit).
 - Если хотите использовать HDD, берите современные модели с Media или SSD кэшем - HGST Ultrastar,
-  Toshiba MG08, Seagate EXOS или что-то похожее. Если такого кэша у ваших дисков нет,
+  Toshiba MG, Seagate EXOS или что-то похожее. Если такого кэша у ваших дисков нет,
   обязательно возьмите SSD под метаданные и журнал (маленькие, буквально 2 ГБ на 1 ТБ HDD-места).
 - Возьмите быструю сеть, минимум 10 гбит/с. Идеал - что-то вроде Mellanox ConnectX-4 с RoCEv2.
 - Для лучшей производительности отключите энергосбережение CPU: `cpupower idle-set -D 0 && cpupower frequency-set -g performance`.
-- [Установите пакеты Vitastor](../installation/packages.ru.md).
+- Либо [установите пакеты Vitastor](../installation/packages.ru.md), либо [установите Vitastor в Docker](../installation/docker.ru.md).
 
 ## Рекомендуемые диски
 
 - SATA SSD: Micron 5100/5200/5300/5400, Samsung PM863/PM883/PM893, Intel D3-S4510/4520/4610/4620, Kingston DC500M
 - NVMe: Micron 9100/9200/9300/9400, Micron 7300/7450, Samsung PM983/PM9A3, Samsung PM1723/1735/1743,
-  Intel DC-P3700/P4500/P4600, Intel D7-P5500/P5600, Intel Optane, Kingston DC1000B/DC1500M
-- HDD: HGST Ultrastar, Toshiba MG06/MG07/MG08, Seagate EXOS
+  Intel DC-P3700/P4500/P4600, Intel D5-P4320/P5530, Intel D7-P5500/P5600, Intel Optane, Kingston DC1000B/DC1500M
+- HDD: HGST Ultrastar, Toshiba MG, Seagate EXOS
 
 ## Настройте мониторы
 
@@ -44,12 +44,13 @@
     "etcd_address": ["10.200.1.10:2379","10.200.1.11:2379","10.200.1.12:2379"]
   }
   ```
-- Инициализируйте сервисы etcd, запустив `/usr/lib/vitastor/mon/make-etcd`
-- Запустите etcd и мониторы: `systemctl enable --now etcd vitastor-mon`
+- Инициализируйте сервисы etcd, запустив `/usr/lib/vitastor/mon/make-etcd`.\
+  Либо, если вы установили Vitastor в Docker, запустите `systemctl start vitastor-host; docker exec vitastor make-etcd`.
+- Запустите etcd и мониторы: `systemctl enable --now vitastor-etcd vitastor-mon`
 
 ## Настройте OSD
 
-- Пропишите etcd_address и osd_network в `/etc/vitastor/vitastor.conf`. Например:
+- Пропишите etcd_address и [osd_network](../config/network.ru.md#osd_network) в `/etc/vitastor/vitastor.conf`. Например:
   ```
   {
     "etcd_address": ["10.200.1.10:2379","10.200.1.11:2379","10.200.1.12:2379"],

docs/params/head/common.en.md

@@ -1,6 +0,0 @@
----
-title: Common Parameters
-weight: 1
----
-
-These are the most common parameters which apply to all components of Vitastor.

docs/params/head/common.ru.md

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

docs/params/head/layout-cluster.en.md

@@ -1,7 +0,0 @@
----
-title: Cluster-Wide Disk Layout Parameters
-weight: 2
----
-
-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.

docs/params/head/layout-cluster.ru.md

@@ -1,7 +0,0 @@
----
-title: Дисковые параметры уровня кластера
-weight: 2
----
-
-Данные параметры используются клиентами и OSD, задаются в момент инициализации
-диска OSD и не могут быть изменены после этого без потери данных.

docs/params/head/layout-osd.en.md

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