WIP/experimental LRC matrix generator

2023-01-06 17:13:29 +03:00
273 changed files with 3861 additions and 20518 deletions
--- a/.gitea/workflows/buildenv.Dockerfile
+++ b/.gitea/workflows/buildenv.Dockerfile
@ -1,36 +0,0 @@
 FROM node:16-bullseye
 WORKDIR /root
 ADD ./docker/vitastor.gpg /etc/apt/trusted.gpg.d
 RUN echo 'deb http://deb.debian.org/debian bullseye-backports main' >> /etc/apt/sources.list; \
    echo 'deb http://vitastor.io/debian bullseye main' >> /etc/apt/sources.list; \
    echo >> /etc/apt/preferences; \
    echo 'Package: *' >> /etc/apt/preferences; \
    echo 'Pin: release a=bullseye-backports' >> /etc/apt/preferences; \
    echo 'Pin-Priority: 500' >> /etc/apt/preferences; \
    echo >> /etc/apt/preferences; \
    echo 'Package: *' >> /etc/apt/preferences; \
    echo 'Pin: origin "vitastor.io"' >> /etc/apt/preferences; \
    echo 'Pin-Priority: 1000' >> /etc/apt/preferences; \
    grep '^deb ' /etc/apt/sources.list | perl -pe 's/^deb/deb-src/' >> /etc/apt/sources.list; \
    echo 'APT::Install-Recommends false;' >> /etc/apt/apt.conf; \
    echo 'APT::Install-Suggests false;' >> /etc/apt/apt.conf
 RUN apt-get update
 RUN apt-get -y install etcd qemu-system-x86 qemu-block-extra qemu-utils fio libasan5 \
    liburing1 liburing-dev libgoogle-perftools-dev devscripts libjerasure-dev cmake libibverbs-dev libisal-dev
 RUN apt-get -y build-dep fio qemu=`dpkg -s qemu-system-x86|grep ^Version:|awk '{print $2}'`
 RUN apt-get -y install jq lp-solve sudo
 RUN apt-get --download-only source fio qemu=`dpkg -s qemu-system-x86|grep ^Version:|awk '{print $2}'`
 RUN set -ex; \
    mkdir qemu-build; \
    cd qemu-build; \
    dpkg-source -x /root/qemu*.dsc; \
    cd qemu*/; \
    debian/rules configure-qemu || debian/rules b/configure-stamp; \
    cd b/qemu; \
    make -j8 config-poison.h || true; \
    make -j8 qapi/qapi-builtin-types.h
--- a/.gitea/workflows/test.Dockerfile
+++ b/.gitea/workflows/test.Dockerfile
@ -1,19 +0,0 @@
 FROM git.yourcmc.ru/vitalif/vitastor/buildenv
 ADD . /root/vitastor
 RUN set -e -x; \
    mkdir -p /root/fio-build/; \
    cd /root/fio-build/; \
    dpkg-source -x /root/fio*.dsc; \
    cd /root/vitastor; \
    ln -s /root/fio-build/fio-*/ ./fio; \
    ln -s /root/qemu-build/qemu-*/ ./qemu; \
    ls /usr/include/linux/raw.h || cp ./debian/raw.h /usr/include/linux/raw.h; \
    cd mon; \
    npm install; \
    cd ..; \
    mkdir build; \
    cd build; \
    cmake .. -DWITH_ASAN=yes -DWITH_QEMU=yes; \
    make -j16
--- a/.gitea/workflows/test.yml
+++ b/.gitea/workflows/test.yml
@ -1,858 +0,0 @@
 name: Test
 on:
  push:
    branches:
    - '*'
    paths:
    - '.gitea/**'
    - 'src/**'
    - 'mon/**'
    - 'json11'
    - 'cpp-btree'
    - 'tests/**'
 env:
  BUILDENV_IMAGE: git.yourcmc.ru/vitalif/vitastor/buildenv
  TEST_IMAGE: git.yourcmc.ru/vitalif/vitastor/test
  OSD_ARGS: '--etcd_quick_timeout 2000'
 concurrency:
  group: ci-${{ github.ref }}
  cancel-in-progress: true
 jobs:
  buildenv:
    runs-on: ubuntu-latest
    container: git.yourcmc.ru/vitalif/gitea-ci-dind
    steps:
    - uses: actions/checkout@v3
    - name: Build and push
      run: |
        set -ex
        if ! docker manifest inspect $BUILDENV_IMAGE >/dev/null; then
          docker build -t $BUILDENV_IMAGE -f .gitea/workflows/buildenv.Dockerfile .
          docker login git.yourcmc.ru -u vitalif -p "${{secrets.TOKEN}}"
          docker push $BUILDENV_IMAGE
        fi
  build:
    runs-on: ubuntu-latest
    needs: buildenv
    container: git.yourcmc.ru/vitalif/gitea-ci-dind
    steps:
    - uses: actions/checkout@v3
      with:
        submodules: true
    - name: Build and push
      run: |
        set -ex
        if ! docker manifest inspect $TEST_IMAGE:$GITHUB_SHA >/dev/null; then
          docker build -t $TEST_IMAGE:$GITHUB_SHA -f .gitea/workflows/test.Dockerfile .
          docker login git.yourcmc.ru -u vitalif -p "${{secrets.TOKEN}}"
          docker push $TEST_IMAGE:$GITHUB_SHA
        fi
  make_test:
    runs-on: ubuntu-latest
    needs: build
    container: ${{env.TEST_IMAGE}}:${{github.sha}}
    steps:
    # leak sanitizer sometimes crashes
    - run: cd /root/vitastor/build && ASAN_OPTIONS=detect_leaks=0 make -j16 test
  test_add_osd:
    runs-on: ubuntu-latest
    needs: build
    container: ${{env.TEST_IMAGE}}:${{github.sha}}
    steps:
    - name: Run test
      id: test
      timeout-minutes: 10
      run: /root/vitastor/tests/test_add_osd.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_cas:
    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_cas.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_change_pg_count:
    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_change_pg_count.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_change_pg_count_ec:
    runs-on: ubuntu-latest
    needs: build
    container: ${{env.TEST_IMAGE}}:${{github.sha}}
    steps:
    - name: Run test
      id: test
      timeout-minutes: 3
      run: SCHEME=ec /root/vitastor/tests/test_change_pg_count.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_change_pg_size:
    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_change_pg_size.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_create_nomaxid:
    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_nomaxid.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_etcd_fail:
    runs-on: ubuntu-latest
    needs: build
    container: ${{env.TEST_IMAGE}}:${{github.sha}}
    steps:
    - name: Run test
      id: test
      timeout-minutes: 10
      run: /root/vitastor/tests/test_etcd_fail.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_interrupted_rebalance:
    runs-on: ubuntu-latest
    needs: build
    container: ${{env.TEST_IMAGE}}:${{github.sha}}
    steps:
    - name: Run test
      id: test
      timeout-minutes: 10
      run: /root/vitastor/tests/test_interrupted_rebalance.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_interrupted_rebalance_imm:
    runs-on: ubuntu-latest
    needs: build
    container: ${{env.TEST_IMAGE}}:${{github.sha}}
    steps:
    - name: Run test
      id: test
      timeout-minutes: 10
      run: IMMEDIATE_COMMIT=1 /root/vitastor/tests/test_interrupted_rebalance.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_interrupted_rebalance_ec:
    runs-on: ubuntu-latest
    needs: build
    container: ${{env.TEST_IMAGE}}:${{github.sha}}
    steps:
    - name: Run test
      id: test
      timeout-minutes: 10
      run: SCHEME=ec /root/vitastor/tests/test_interrupted_rebalance.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_interrupted_rebalance_ec_imm:
    runs-on: ubuntu-latest
    needs: build
    container: ${{env.TEST_IMAGE}}:${{github.sha}}
    steps:
    - name: Run test
      id: test
      timeout-minutes: 10
      run: SCHEME=ec IMMEDIATE_COMMIT=1 /root/vitastor/tests/test_interrupted_rebalance.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
    container: ${{env.TEST_IMAGE}}:${{github.sha}}
    steps:
    - name: Run test
      id: test
      timeout-minutes: 3
      run: /root/vitastor/tests/test_failure_domain.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:
    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.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_ec:
    runs-on: ubuntu-latest
    needs: build
    container: ${{env.TEST_IMAGE}}:${{github.sha}}
    steps:
    - name: Run test
      id: test
      timeout-minutes: 3
      run: SCHEME=ec /root/vitastor/tests/test_snapshot.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_minsize_1:
    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_minsize_1.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_move_reappear:
    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_move_reappear.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_rm:
    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.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
    container: ${{env.TEST_IMAGE}}:${{github.sha}}
    steps:
    - name: Run test
      id: test
      timeout-minutes: 3
      run: /root/vitastor/tests/test_snapshot_chain.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_ec:
    runs-on: ubuntu-latest
    needs: build
    container: ${{env.TEST_IMAGE}}:${{github.sha}}
    steps:
    - name: Run test
      id: test
      timeout-minutes: 6
      run: SCHEME=ec /root/vitastor/tests/test_snapshot_chain.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_down:
    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_down.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_down_ec:
    runs-on: ubuntu-latest
    needs: build
    container: ${{env.TEST_IMAGE}}:${{github.sha}}
    steps:
    - name: Run test
      id: test
      timeout-minutes: 3
      run: SCHEME=ec /root/vitastor/tests/test_snapshot_down.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_splitbrain:
    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_splitbrain.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_rebalance_verify:
    runs-on: ubuntu-latest
    needs: build
    container: ${{env.TEST_IMAGE}}:${{github.sha}}
    steps:
    - name: Run test
      id: test
      timeout-minutes: 10
      run: /root/vitastor/tests/test_rebalance_verify.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_rebalance_verify_imm:
    runs-on: ubuntu-latest
    needs: build
    container: ${{env.TEST_IMAGE}}:${{github.sha}}
    steps:
    - name: Run test
      id: test
      timeout-minutes: 10
      run: IMMEDIATE_COMMIT=1 /root/vitastor/tests/test_rebalance_verify.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_rebalance_verify_ec:
    runs-on: ubuntu-latest
    needs: build
    container: ${{env.TEST_IMAGE}}:${{github.sha}}
    steps:
    - name: Run test
      id: test
      timeout-minutes: 10
      run: SCHEME=ec /root/vitastor/tests/test_rebalance_verify.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_rebalance_verify_ec_imm:
    runs-on: ubuntu-latest
    needs: build
    container: ${{env.TEST_IMAGE}}:${{github.sha}}
    steps:
    - name: Run test
      id: test
      timeout-minutes: 10
      run: SCHEME=ec IMMEDIATE_COMMIT=1 /root/vitastor/tests/test_rebalance_verify.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_switch_primary:
    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_switch_primary.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:
    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_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_xor:
    runs-on: ubuntu-latest
    needs: build
    container: ${{env.TEST_IMAGE}}:${{github.sha}}
    steps:
    - name: Run test
      id: test
      timeout-minutes: 3
      run: SCHEME=xor /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
    container: ${{env.TEST_IMAGE}}:${{github.sha}}
    steps:
    - name: Run test
      id: test
      timeout-minutes: 3
      run: /root/vitastor/tests/test_write_no_same.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_pg_size_2:
    runs-on: ubuntu-latest
    needs: build
    container: ${{env.TEST_IMAGE}}:${{github.sha}}
    steps:
    - name: Run test
      id: test
      timeout-minutes: 10
      run: PG_SIZE=2 /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
    container: ${{env.TEST_IMAGE}}:${{github.sha}}
    steps:
    - name: Run test
      id: test
      timeout-minutes: 10
      run: SCHEME=ec /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_csum_32k_dmj:
    runs-on: ubuntu-latest
    needs: build
    container: ${{env.TEST_IMAGE}}:${{github.sha}}
    steps:
    - name: Run test
      id: test
      timeout-minutes: 10
      run: TEST_NAME=csum_32k_dmj OSD_ARGS="--data_csum_type crc32c --csum_block_size 32k --inmemory_metadata false --inmemory_journal false" OFFSET_ARGS=$OSD_ARGS /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_csum_32k_dj:
    runs-on: ubuntu-latest
    needs: build
    container: ${{env.TEST_IMAGE}}:${{github.sha}}
    steps:
    - name: Run test
      id: test
      timeout-minutes: 10
      run: TEST_NAME=csum_32k_dj  OSD_ARGS="--data_csum_type crc32c --csum_block_size 32k --inmemory_journal false" OFFSET_ARGS=$OSD_ARGS /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_csum_32k:
    runs-on: ubuntu-latest
    needs: build
    container: ${{env.TEST_IMAGE}}:${{github.sha}}
    steps:
    - name: Run test
      id: test
      timeout-minutes: 10
      run: TEST_NAME=csum_32k     OSD_ARGS="--data_csum_type crc32c --csum_block_size 32k" OFFSET_ARGS=$OSD_ARGS /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_csum_4k_dmj:
    runs-on: ubuntu-latest
    needs: build
    container: ${{env.TEST_IMAGE}}:${{github.sha}}
    steps:
    - name: Run test
      id: test
      timeout-minutes: 10
      run: TEST_NAME=csum_4k_dmj  OSD_ARGS="--data_csum_type crc32c --inmemory_metadata false --inmemory_journal false" OFFSET_ARGS=$OSD_ARGS /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_csum_4k_dj:
    runs-on: ubuntu-latest
    needs: build
    container: ${{env.TEST_IMAGE}}:${{github.sha}}
    steps:
    - name: Run test
      id: test
      timeout-minutes: 10
      run: TEST_NAME=csum_4k_dj   OSD_ARGS="--data_csum_type crc32c --inmemory_journal false" OFFSET_ARGS=$OSD_ARGS /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_csum_4k:
    runs-on: ubuntu-latest
    needs: build
    container: ${{env.TEST_IMAGE}}:${{github.sha}}
    steps:
    - name: Run test
      id: test
      timeout-minutes: 10
      run: TEST_NAME=csum_4k      OSD_ARGS="--data_csum_type crc32c" OFFSET_ARGS=$OSD_ARGS /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_scrub:
    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_scrub.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_scrub_zero_osd_2:
    runs-on: ubuntu-latest
    needs: build
    container: ${{env.TEST_IMAGE}}:${{github.sha}}
    steps:
    - name: Run test
      id: test
      timeout-minutes: 3
      run: ZERO_OSD=2 /root/vitastor/tests/test_scrub.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_scrub_xor:
    runs-on: ubuntu-latest
    needs: build
    container: ${{env.TEST_IMAGE}}:${{github.sha}}
    steps:
    - name: Run test
      id: test
      timeout-minutes: 3
      run: SCHEME=xor /root/vitastor/tests/test_scrub.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_scrub_pg_size_3:
    runs-on: ubuntu-latest
    needs: build
    container: ${{env.TEST_IMAGE}}:${{github.sha}}
    steps:
    - name: Run test
      id: test
      timeout-minutes: 3
      run: PG_SIZE=3 /root/vitastor/tests/test_scrub.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_scrub_pg_size_6_pg_minsize_4_osd_count_6_ec:
    runs-on: ubuntu-latest
    needs: build
    container: ${{env.TEST_IMAGE}}:${{github.sha}}
    steps:
    - name: Run test
      id: test
      timeout-minutes: 3
      run: PG_SIZE=6 PG_MINSIZE=4 OSD_COUNT=6 SCHEME=ec /root/vitastor/tests/test_scrub.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_scrub_ec:
    runs-on: ubuntu-latest
    needs: build
    container: ${{env.TEST_IMAGE}}:${{github.sha}}
    steps:
    - name: Run test
      id: test
      timeout-minutes: 3
      run: SCHEME=ec /root/vitastor/tests/test_scrub.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
--- a/.gitea/workflows/tests-to-yaml.pl
+++ b/.gitea/workflows/tests-to-yaml.pl
@ -1,79 +0,0 @@
 #!/usr/bin/perl
 use strict;
 for my $line (<>)
 {
    if ($line =~ /\.\/(test_[^\.]+)/s)
    {
        chomp $line;
        my $base_name = $1;
        my $test_name = $base_name;
        my $timeout = 3;
        if ($test_name eq 'test_etcd_fail' || $test_name eq 'test_heal' || $test_name eq 'test_add_osd' ||
            $test_name eq 'test_interrupted_rebalance' || $test_name eq 'test_rebalance_verify')
        {
            $timeout = 10;
        }
        while ($line =~ /([^\s=]+)=(\S+)/gs)
        {
            if ($1 eq 'TEST_NAME')
            {
                $test_name = $base_name.'_'.$2;
                last;
            }
            elsif ($1 eq 'SCHEME' && $2 eq 'ec')
            {
                $test_name .= '_ec';
            }
            elsif ($1 eq 'SCHEME' && $2 eq 'xor')
            {
                $test_name .= '_xor';
            }
            elsif ($1 eq 'IMMEDIATE_COMMIT')
            {
                $test_name .= '_imm';
            }
            else
            {
                $test_name .= '_'.lc($1).'_'.$2;
            }
        }
        if ($test_name eq 'test_snapshot_chain_ec')
        {
            $timeout = 6;
        }
        $line =~ s!\./test_!/root/vitastor/tests/test_!;
        # Gitea CI doesn't support artifacts yet, lol
        #- name: Upload results
        #  uses: actions/upload-artifact\@v3
        #  if: always()
        #  with:
        #    name: ${test_name}_result
        #    path: |
        #      /root/vitastor/testdata
        #      !/root/vitastor/testdata/*.bin
        #    retention-days: 5
        print <<"EOF"
  $test_name:
    runs-on: ubuntu-latest
    needs: build
    container: \${{env.TEST_IMAGE}}:\${{github.sha}}
    steps:
    - name: Run test
      id: test
      timeout-minutes: $timeout
      run: $line
    - name: Print logs
      if: always() && steps.test.outcome == 'failure'
      run: |
        for i in /root/vitastor/testdata/*.log /root/vitastor/testdata/*.txt; do
          echo "-------- \$i --------"
          cat \$i
          echo ""
        done
 EOF
 ;
    }
 }
--- a/CLA-en.md
+++ b/CLA-en.md
@ -1,115 +0,0 @@
 ## Contributor License Agreement
 > This Agreement is made in the Russian and English languages. **The English
 text of Agreement is for informational purposes only** and is not binding
 for the Parties.
 >
 > In the event of a conflict between the provisions of the Russian and
 English versions of this Agreement, the **Russian version shall prevail**.
 >
 > Russian version is published at https://git.yourcmc.ru/vitalif/vitastor/src/branch/master/CLA-ru.md
 This document represents the offer of Filippov Vitaliy Vladimirovich
 ("Author"), author and copyright holder of Vitastor software ("Program"),
 acknowledged by a certificate of Federal Service for Intellectual
 Property of Russian Federation (Rospatent) # 2021617829 dated 20 May 2021,
 to "Contributors" to conclude this license agreement as follows
 ("Agreement" or "Offer").
 In accordance with Art. 435, Art. 438 of the Civil Code of the Russian
 Federation, this Agreement is an offer and in case of acceptance of the
 offer, an agreement is considered concluded on the conditions specified
 in the offer.
 1. Applicable Terms. \
   1.1. "Official Repository" shall mean the computer storage, operated by
        the Author, containing all prior and future versions of the Source
        Code of the Program, at Internet addresses https://git.yourcmc.ru/vitalif/vitastor/
        or https://github.com/vitalif/vitastor/. \
   1.2. "Contributions" shall mean results of intellectual activity
        (including, but not limited to, source code, libraries, components,
        texts, documentation) which can be software or elements of the software
        and which are provided by Contributors to the Author for inclusion
        in the Program. \
   1.3. "Contributor" shall mean a person who provides Contributions to
        the Author and agrees with all provisions of this Agreement.
        A Сontributor can be: 1) an individual; or 2) a legal entity or an
        individual entrepreneur in case when an individual provides Contributions
        on behalf of third parties, including on behalf of his employer.
 2. Subject of the Agreement. \
   2.1. Subject of the Agreement shall be the Contributions sent to the Author by Contributors. \
   2.2. The Contributor grants to the Author the right to use Contributions at his own
        discretion and without any necessity to get a prior approval from Contributor or
        any other third party in any way, under a simple (non-exclusive), royalty-free,
        irrevocable license throughout the world by all means not contrary to law, in whole
        or as a part of the Program, or other open-source or closed-source computer programs,
        products or services (hereinafter -- the "License"), including, but not limited to: \
        2.2.1. to execute Contributions and use them for any tasks; \
        2.2.2. to publish and distribute Contributions in modified or unmodified form and/or to rent them; \
        2.2.3. to modify Contributions, add comments, illustrations or any explanations to Contributions while using them; \
        2.2.4. to create other results of intellectual activity based on Contributions, including derivative works and composite works; \
        2.2.5. to translate Contributions into other languages, including other programming languages; \
        2.2.6. to carry out rental and public display of Contributions; \
        2.2.7. to use Contributions under the trade name and/or any trademark or any other label, or without it, as the Author thinks fit; \
   2.3. The Contributor grants to the Author the right to sublicense any of the aforementioned
        rights to third parties on any terms at the Author's discretion. \
   2.4. The License is provided for the entire duration of Contributor's
        exclusive intellectual property rights to the Contributions. \
   2.5. The Contributor grants to the Author the right to decide how and where to mention,
        or to not mention at all, the fact of his authorship, name, nickname and/or company
        details when including Contributions into the Program or in any other computer
        programs, products or services.
 3. Acceptance of the Offer \
   3.1. The Contributor may provide Contributions to the Author in the form of
        a "Pull Request" in an Official Repository of the Program or by any
        other electronic means of communication, including, but not limited to,
        E-mail or messenger applications. \
   3.2. The acceptance of the Offer shall be the fact of provision of Contributions
        to the Author by the Contributor by any means with the following remark:
        “I accept Vitastor CLA agreement: https://git.yourcmc.ru/vitalif/vitastor/src/branch/master/CLA-en.md”
        or “Я принимаю соглашение Vitastor CLA: https://git.yourcmc.ru/vitalif/vitastor/src/branch/master/CLA-ru.md”. \
   3.3. Date of acceptance of the Offer shall be the date of such provision.
 4. Rights and obligations of the parties. \
   4.1. The Contributor reserves the right to use Contributions by any lawful means
        not contrary to this Agreement. \
   4.2. The Author has the right to refuse to include Contributions into the Program
        at any moment with no explanation to the Contributor.
 5. Representations and Warranties. \
   5.1. The person providing Contributions for the purpose of their inclusion
        in the Program represents and warrants that he is the Contributor
        or legally acts on the Contributor's behalf. Name or company details
        of the Contributor shall be provided with the Contribution at the moment
        of their provision to the Author. \
   5.2. The Contributor represents and warrants that he legally owns exclusive
        intellectual property rights to the Contributions. \
   5.3. The Contributor represents and warrants that any further use of
        Contributions by the Author as provided by Contributor under the terms
        of the Agreement does not infringe on intellectual and other rights and
        legitimate interests of third parties. \
   5.4. The Contributor represents and warrants that he has all rights and legal
        capacity needed to accept this Offer; \
   5.5. The Contributor represents and warrants that Contributions don't
        contain malware or any information considered illegal under the law
        of Russian Federation.
 6. Termination of the Agreement \
   6.1. The Agreement may be terminated at will of both Author and Contributor,
        formalised in the written form or if the Agreement is terminated on
        reasons prescribed by the law of Russian Federation.
 7. Final Clauses \
   7.1. The Contributor may optionally sign the Agreement in the written form. \
   7.2. The Agreement is deemed to become effective from the Date of signing of
        the Agreement and until the expiration of Contributor's exclusive
        intellectual property rights to the Contributions. \
   7.3. The Author may unilaterally alter the Agreement without informing Contributors.
        The new version of the document shall come into effect 3 (three) days after
        being published in the Official Repository of the Program at Internet address
        [https://git.yourcmc.ru/vitalif/vitastor/src/branch/master/CLA-en.md](https://git.yourcmc.ru/vitalif/vitastor/src/branch/master/CLA-en.md).
        Contributors should keep informed about the actual version of the Agreement themselves. \
   7.4. If the Author and the Contributor fail to agree on disputable issues,
        disputes shall be referred to the Moscow Arbitration court.
--- a/CLA-ru.md
+++ b/CLA-ru.md
@ -1,108 +0,0 @@
 ## Лицензионное соглашение с участником
 > Данная Оферта написана в Русской и Английской версиях. **Версия на английском
 языке предоставляется в информационных целях** и не связывает стороны договора.
 >
 > В случае несоответствий между положениями Русской и Английской версий Договора,
 **Русская версия имеет приоритет**.
 >
 > Английская версия опубликована по адресу https://git.yourcmc.ru/vitalif/vitastor/src/branch/master/CLA-en.md
 Настоящий договор-оферта (далее по тексту – Оферта, Договор) адресована физическим
 и юридическим лицам (далее – Участникам) и является официальным публичным предложением
 Филиппова Виталия Владимировича (далее – Автора) программного обеспечения Vitastor,
 свидетельство Федеральной службы по интеллектуальной собственности (Роспатент) № 2021617829
 от 20 мая 2021 г. (далее – Программа) о нижеследующем:
 1. Термины и определения \
   1.1. Репозиторий – электронное хранилище, содержащее исходный код Программы. \
   1.2. Доработка – результат интеллектуальной деятельности Участника, включающий
        в себя изменения или дополнения к исходному коду Программы, которые Участник
        желает включить в состав Программы для дальнейшего использования и распространения
        Автором и для этого направляет их Автору. \
   1.3. Участник – физическое или юридическое лицо, вносящее Доработки в код Программы. \
   1.4. ГК РФ – Гражданский кодекс Российской Федерации.
 2. Предмет оферты \
   2.1. Предметом настоящей оферты являются Доработки, отправляемые Участником Автору. \
   2.2. Участник предоставляет Автору право использовать Доработки по собственному усмотрению
        и без необходимости предварительного согласования с Участником или иным третьим лицом
        на условиях простой (неисключительной) безвозмездной безотзывной лицензии, полностью
        или фрагментарно, в составе Программы или других программ, продуктов или сервисов
        как с открытым, так и с закрытым исходным кодом, любыми способами, не противоречащими
        закону, включая, но не ограничиваясь следующими: \
        2.2.1. Запускать и использовать Доработки для выполнения любых задач; \
        2.2.2. Распространять, импортировать и доводить Доработки до всеобщего сведения; \
        2.2.3. Вносить в Доработки изменения, сокращения и дополнения, снабжать Доработки
               при их использовании комментариями, иллюстрациями или пояснениями; \
        2.2.4. Создавать на основе Доработок иные результаты интеллектуальной деятельности,
               в том числе производные и составные произведения; \
        2.2.5. Переводить Доработки на другие языки, в том числе на другие языки программирования; \
        2.2.6. Осуществлять прокат и публичный показ Доработок; \
        2.2.7. Использовать Доработки под любым фирменным наименованием, товарным знаком
               (знаком обслуживания) или иным обозначением, или без такового. \
   2.3. Участник предоставляет Автору право сублицензировать полученные права на Доработки
        третьим лицам на любых условиях на усмотрение Автора. \
   2.4. Участник предоставляет Автору права на Доработки на территории всего мира. \
   2.5. Участник предоставляет Автору права на весь срок действия исключительного права
        Участника на Доработки. \
   2.6. Участник предоставляет Автору права на Доработки на безвозмездной основе. \
   2.7. Участник разрешает Автору самостоятельно определять порядок, способ и
        место указания его имени, реквизитов и/или псевдонима при включении
        Доработок в состав Программы или других программ, продуктов или сервисов.
 3. Акцепт Оферты \
   3.1. Участник может передавать Доработки в адрес Автора через зеркала официального
        Репозитория Программы по адресам https://git.yourcmc.ru/vitalif/vitastor/ или
        https://github.com/vitalif/vitastor/ в виде “запроса на слияние” (pull request),
        либо в письменном виде или с помощью любых других электронных средств коммуникации,
        например, электронной почты или мессенджеров. \
   3.2. Факт передачи Участником Доработок в адрес Автора любым способом с одной из пометок
        “I accept Vitastor CLA agreement: https://git.yourcmc.ru/vitalif/vitastor/src/branch/master/CLA-en.md”
        или “Я принимаю соглашение Vitastor CLA: https://git.yourcmc.ru/vitalif/vitastor/src/branch/master/CLA-ru.md”
        является полным и безоговорочным акцептом (принятием) Участником условий настоящей
        Оферты, т.е. Участник считается ознакомившимся с настоящим публичным договором и
        в соответствии с ГК РФ признается лицом, вступившим с Автором в договорные отношения
        на основании настоящей Оферты. \
   3.3. Датой акцептирования настоящей Оферты считается дата такой передачи.
 4. Права и обязанности Сторон \
   4.1. Участник сохраняет за собой право использовать Доработки любым законным
        способом, не противоречащим настоящему Договору. \
   4.2. Автор вправе отказать Участнику во включении Доработок в состав
        Программы без объяснения причин в любой момент по своему усмотрению.
 5. Гарантии и заверения \
   5.1. Лицо, направляющее Доработки для целей их включения в состав Программы,
        гарантирует, что является Участником или представителем Участника. Имя или реквизиты
        Участника должны быть указаны при их передаче в адрес Автора Программы. \
   5.2. Участник гарантирует, что является законным обладателем исключительных прав
        на Доработки. \
   5.3. Участник гарантирует, что на момент акцептирования настоящей Оферты ему
        ничего не известно (и не могло быть известно) о правах третьих лиц на
        передаваемые Автору Доработки или их часть, которые могут быть нарушены
        в связи с передачей Доработок по настоящему Договору. \
   5.4. Участник гарантирует, что является дееспособным лицом и обладает всеми
        необходимыми правами для заключения Договора. \
   5.5. Участник гарантирует, что Доработки не содержат вредоносного ПО, а также
        любой другой информации, запрещённой к распространению по законам Российской
        Федерации.
 6. Прекращение действия оферты \
   6.1. Действие настоящего договора может быть прекращено по соглашению сторон,
        оформленному в письменном виде, а также вследствие его расторжения по основаниям,
        предусмотренным законом.
 7. Заключительные положения \
   7.1. Участник вправе по желанию подписать настоящий Договор в письменном виде. \
   7.2. Настоящий договор действует с момента его заключения и до истечения срока
        действия исключительных прав Участника на Доработки. \
   7.3. Автор имеет право в одностороннем порядке вносить изменения и дополнения в договор
        без специального уведомления об этом Участников. Новая редакция документа вступает
        в силу через 3 (Три) календарных дня со дня опубликования в официальном Репозитории
        Программы по адресу в сети Интернет
        [https://git.yourcmc.ru/vitalif/vitastor/src/branch/master/CLA-ru.md](https://git.yourcmc.ru/vitalif/vitastor/src/branch/master/CLA-ru.md).
        Участники самостоятельно отслеживают действующие условия Оферты. \
   7.4. Все споры, возникающие между сторонами в процессе их взаимодействия по настоящему
        договору, решаются путём переговоров. В случае невозможности урегулирования споров
        переговорным порядком стороны разрешают их в Арбитражном суде г.Москвы.
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@ -1,7 +1,7 @@
-cmake_minimum_required(VERSION 2.8.12)
+cmake_minimum_required(VERSION 2.8)
 project(vitastor)
-set(VERSION "1.4.4")
+set(VERSION "0.8.3")
 add_subdirectory(src)
--- a/README-ru.md
+++ b/README-ru.md
@ -15,7 +15,7 @@ Vitastor архитектурно похож на Ceph, что означает
 и автоматическое распределение данных по любому числу дисков любого размера с настраиваемыми схемами
 избыточности - репликацией или с произвольными кодами коррекции ошибок.
-Vitastor нацелен в первую очередь на SSD и SSD+HDD кластеры с как минимум 10 Гбит/с сетью, поддерживает
+Vitastor нацелен на SSD и SSD+HDD кластеры с как минимум 10 Гбит/с сетью, поддерживает
 TCP и RDMA и на хорошем железе может достигать задержки 4 КБ чтения и записи на уровне ~0.1 мс,
 что примерно в 10 раз быстрее, чем Ceph и другие популярные программные СХД.
@ -50,7 +50,6 @@ Vitastor поддерживает QEMU-драйвер, протоколы NBD и
  - Параметры
    - [Общие](docs/config/common.ru.md)
    - [Сетевые](docs/config/network.ru.md)
    - [Клиентский код](docs/config/client.en.md)
    - [Глобальные дисковые параметры](docs/config/layout-cluster.ru.md)
    - [Дисковые параметры OSD](docs/config/layout-osd.ru.md)
    - [Прочие параметры OSD](docs/config/osd.ru.md)
--- a/README.md
+++ b/README.md
@ -14,8 +14,8 @@ Vitastor is architecturally similar to Ceph which means strong consistency,
 primary-replication, symmetric clustering and automatic data distribution over any
 number of drives of any size with configurable redundancy (replication or erasure codes/XOR).
-Vitastor targets primarily SSD and SSD+HDD clusters with at least 10 Gbit/s network,
+Vitastor targets SSD and SSD+HDD clusters with at least 10 Gbit/s network, supports
-supports TCP and RDMA and may achieve 4 KB read and write latency as low as ~0.1 ms
+TCP and RDMA and may achieve 4 KB read and write latency as low as ~0.1 ms
 with proper hardware which is ~10 times faster than other popular SDS's like Ceph
 or internal systems of public clouds.
@ -50,7 +50,6 @@ Read more details below in the documentation.
  - Parameter Reference
    - [Common](docs/config/common.en.md)
    - [Network](docs/config/network.en.md)
    - [Client](docs/config/client.en.md)
    - [Global Disk Layout](docs/config/layout-cluster.en.md)
    - [OSD Disk Layout](docs/config/layout-osd.en.md)
    - [OSD Runtime Parameters](docs/config/osd.en.md)
--- a/VNPL-1.1-RU.txt
+++ b/VNPL-1.1-RU.txt
@ -48,9 +48,9 @@ Vitastor, составлены для того, чтобы убедиться,
 интерфейс (прокси), опять же, без открытия в свободный публичный доступ как
 самой программы, так и прокси.
-  Сетевая Публичная Лицензия Vitastor разработана специально, чтобы
+  Сетевая Публичная Лицензия Vitastor разработана специально чтобы
 гарантировать, что в таких случаях и модифицированная версия программы, и
-прокси останутся доступными сообществу. Для этого лицензия требует от
+прокси оставались доступными сообществу. Для этого лицензия требует от
 операторов сетевых серверов предоставлять исходный код оригинальной программы,
 а также всех других программ, взаимодействующих с ней на их серверах,
 пользователям этих серверов, на условиях свободных лицензий. Таким образом,
--- a/2
+++ b/2
@ -1 +1 @@
-Subproject commit 8de8b467acbca50cfd8835c20e0e379110f3b32b
+Subproject commit 45e6d1f13196a0824e2089a586c53b9de0283f17
--- a/csi/Dockerfile
+++ b/csi/Dockerfile
@ -1,15 +1,14 @@
 # Compile stage
-FROM golang:bookworm AS build
+FROM golang:buster AS build
 ADD go.sum go.mod /app/
 RUN cd /app; CGO_ENABLED=1 GOOS=linux GOARCH=amd64 go mod download -x
 ADD . /app
-RUN perl -i -e '$/ = undef; while(<>) { s/\n\s*(\{\s*\n)/$1\n/g; s/\}(\s*\n\s*)else\b/$1} else/g; print; }' `find /app -name '*.go'` && \
+RUN perl -i -e '$/ = undef; while(<>) { s/\n\s*(\{\s*\n)/$1\n/g; s/\}(\s*\n\s*)else\b/$1} else/g; print; }' `find /app -name '*.go'`
-    cd /app && \
+RUN cd /app; CGO_ENABLED=1 GOOS=linux GOARCH=amd64 go build -o vitastor-csi
    CGO_ENABLED=1 GOOS=linux GOARCH=amd64 go build -o vitastor-csi
 # Final stage
-FROM debian:bookworm
+FROM debian:buster
 LABEL maintainers="Vitaliy Filippov <vitalif@yourcmc.ru>"
 LABEL description="Vitastor CSI Driver"
@ -19,30 +18,19 @@ ENV CSI_ENDPOINT=""
 RUN apt-get update && \
    apt-get install -y wget && \
    (echo deb http://deb.debian.org/debian buster-backports main > /etc/apt/sources.list.d/backports.list) && \
    (echo "APT::Install-Recommends false;" > /etc/apt/apt.conf) && \
    apt-get update && \
-    apt-get install -y e2fsprogs xfsprogs kmod iproute2 \
+    apt-get install -y e2fsprogs xfsprogs kmod && \
        # dependencies of qemu-storage-daemon
        libnuma1 liburing2 libglib2.0-0 libfuse3-3 libaio1 libzstd1 libnettle8 \
        libgmp10 libhogweed6 libp11-kit0 libidn2-0 libunistring2 libtasn1-6 libpcre2-8-0 libffi8 && \
    apt-get clean && \
    (echo options nbd nbds_max=128 > /etc/modprobe.d/nbd.conf)
 COPY --from=build /app/vitastor-csi /bin/
-RUN (echo deb http://vitastor.io/debian bookworm main > /etc/apt/sources.list.d/vitastor.list) && \
+RUN (echo deb http://vitastor.io/debian buster main > /etc/apt/sources.list.d/vitastor.list) && \
    ((echo 'Package: *'; echo 'Pin: origin "vitastor.io"'; echo 'Pin-Priority: 1000') > /etc/apt/preferences.d/vitastor.pref) && \
    wget -q -O /etc/apt/trusted.gpg.d/vitastor.gpg https://vitastor.io/debian/pubkey.gpg && \
    apt-get update && \
    apt-get install -y vitastor-client && \
    wget https://vitastor.io/archive/qemu/qemu-bookworm-8.1.2%2Bds-1%2Bvitastor1/qemu-utils_8.1.2%2Bds-1%2Bvitastor1_amd64.deb && \
    wget https://vitastor.io/archive/qemu/qemu-bookworm-8.1.2%2Bds-1%2Bvitastor1/qemu-block-extra_8.1.2%2Bds-1%2Bvitastor1_amd64.deb && \
    dpkg -x qemu-utils*.deb tmp1 && \
    dpkg -x qemu-block-extra*.deb tmp1 && \
    cp -a tmp1/usr/bin/qemu-storage-daemon /usr/bin/ && \
    mkdir -p /usr/lib/x86_64-linux-gnu/qemu && \
    cp -a tmp1/usr/lib/x86_64-linux-gnu/qemu/block-vitastor.so /usr/lib/x86_64-linux-gnu/qemu/ && \
    rm -rf tmp1 *.deb && \
    apt-get clean
 ENTRYPOINT ["/bin/vitastor-csi"]
--- a/csi/Makefile
+++ b/csi/Makefile
@ -1,4 +1,4 @@
-VERSION ?= v1.4.4
+VERSION ?= v0.8.3
 all: build push
--- a/csi/deploy/001-csi-config-map.yaml
+++ b/csi/deploy/001-csi-config-map.yaml
@ -2,7 +2,6 @@
 apiVersion: v1
 kind: ConfigMap
 data:
  # You can add multiple configuration files here to use a multi-cluster setup
  vitastor.conf: |-
    {"etcd_address":"http://192.168.7.2:2379","etcd_prefix":"/vitastor"}
 metadata:
--- a/csi/deploy/004-csi-nodeplugin.yaml
+++ b/csi/deploy/004-csi-nodeplugin.yaml
@ -49,7 +49,7 @@ spec:
            capabilities:
              add: ["SYS_ADMIN"]
            allowPrivilegeEscalation: true
-          image: vitalif/vitastor-csi:v1.4.4
+          image: vitalif/vitastor-csi:v0.8.3
          args:
            - "--node=$(NODE_ID)"
            - "--endpoint=$(CSI_ENDPOINT)"
@ -82,8 +82,6 @@ spec:
              name: host-sys
            - mountPath: /run/mount
              name: host-mount
            - mountPath: /run/vitastor-csi
              name: run-vitastor-csi
            - mountPath: /lib/modules
              name: lib-modules
              readOnly: true
@ -134,9 +132,6 @@ spec:
        - name: host-mount
          hostPath:
            path: /run/mount
        - name: run-vitastor-csi
          hostPath:
            path: /run/vitastor-csi
        - name: lib-modules
          hostPath:
            path: /lib/modules
--- a/csi/deploy/005-csi-provisioner-rbac.yaml
+++ b/csi/deploy/005-csi-provisioner-rbac.yaml
@ -35,13 +35,10 @@ rules:
    verbs: ["get", "list", "watch"]
  - apiGroups: ["snapshot.storage.k8s.io"]
    resources: ["volumesnapshots"]
-    verbs: ["get", "list", "patch"]
+    verbs: ["get", "list"]
  - apiGroups: ["snapshot.storage.k8s.io"]
    resources: ["volumesnapshots/status"]
    verbs: ["get", "list", "patch"]
  - apiGroups: ["snapshot.storage.k8s.io"]
    resources: ["volumesnapshotcontents"]
-    verbs: ["create", "get", "list", "watch", "update", "delete", "patch"]
+    verbs: ["create", "get", "list", "watch", "update", "delete"]
  - apiGroups: ["snapshot.storage.k8s.io"]
    resources: ["volumesnapshotclasses"]
    verbs: ["get", "list", "watch"]
@ -56,7 +53,7 @@ rules:
    verbs: ["get", "list", "watch"]
  - apiGroups: ["snapshot.storage.k8s.io"]
    resources: ["volumesnapshotcontents/status"]
-    verbs: ["update", "patch"]
+    verbs: ["update"]
  - apiGroups: [""]
    resources: ["configmaps"]
    verbs: ["get"]
--- a/csi/deploy/007-csi-provisioner.yaml
+++ b/csi/deploy/007-csi-provisioner.yaml
@ -23,11 +23,6 @@ metadata:
  name: csi-vitastor-provisioner
 spec:
  replicas: 3
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 1
      maxSurge: 0
  selector:
    matchLabels:
      app: csi-vitastor-provisioner
@ -51,7 +46,7 @@ spec:
      priorityClassName: system-cluster-critical
      containers:
        - name: csi-provisioner
-          image: k8s.gcr.io/sig-storage/csi-provisioner:v3.0.0
+          image: k8s.gcr.io/sig-storage/csi-provisioner:v2.2.0
          args:
            - "--csi-address=$(ADDRESS)"
            - "--v=5"
@ -121,7 +116,7 @@ spec:
            privileged: true
            capabilities:
              add: ["SYS_ADMIN"]
-          image: vitalif/vitastor-csi:v1.4.4
+          image: vitalif/vitastor-csi:v0.8.3
          args:
            - "--node=$(NODE_ID)"
            - "--endpoint=$(CSI_ENDPOINT)"
--- a/csi/deploy/009-storage-class.yaml
+++ b/csi/deploy/009-storage-class.yaml
@ -12,6 +12,8 @@ parameters:
  etcdVolumePrefix: ""
  poolId: "1"
  # you can choose other configuration file if you have it in the config map
  # different etcd URLs and prefixes should also be put in the config
  #configPath: "/etc/vitastor/vitastor.conf"
-allowVolumeExpansion: true
+  # you can also specify etcdUrl here, maybe to connect to another Vitastor cluster
  # multiple etcdUrls may be specified, delimited by comma
  #etcdUrl: "http://192.168.7.2:2379"
  #etcdPrefix: "/vitastor"
--- a/csi/deploy/example-snapshot-class.yaml
+++ b/csi/deploy/example-snapshot-class.yaml
@ -1,7 +0,0 @@
 apiVersion: snapshot.storage.k8s.io/v1
 kind: VolumeSnapshotClass
 metadata:
  name: vitastor-snapclass
 driver: csi.vitastor.io
 deletionPolicy: Delete
 parameters:
--- a/csi/deploy/example-snapshot-clone.yaml
+++ b/csi/deploy/example-snapshot-clone.yaml
@ -1,16 +0,0 @@
 ---
 apiVersion: v1
 kind: PersistentVolumeClaim
 metadata:
  name: test-vitastor-clone
 spec:
  storageClassName: vitastor
  dataSource:
    name: snap1
    kind: VolumeSnapshot
    apiGroup: snapshot.storage.k8s.io
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 10Gi
--- a/csi/deploy/example-snapshot.yaml
+++ b/csi/deploy/example-snapshot.yaml
@ -1,8 +0,0 @@
 apiVersion: snapshot.storage.k8s.io/v1
 kind: VolumeSnapshot
 metadata:
  name: snap1
 spec:
  volumeSnapshotClassName: vitastor-snapclass
  source:
    persistentVolumeClaimName: test-vitastor-pvc
--- a/csi/go.mod
+++ b/csi/go.mod
@ -4,12 +4,26 @@ go 1.15
 require (
 	github.com/container-storage-interface/spec v1.4.0
 	github.com/coreos/bbolt v0.0.0-00010101000000-000000000000 // indirect
 	github.com/coreos/etcd v3.3.25+incompatible // indirect
 	github.com/coreos/go-semver v0.3.0 // indirect
 	github.com/coreos/go-systemd v0.0.0-20191104093116-d3cd4ed1dbcf // indirect
 	github.com/coreos/pkg v0.0.0-20180928190104-399ea9e2e55f // indirect
 	github.com/dustin/go-humanize v1.0.0 // indirect
 	github.com/golang/glog v0.0.0-20160126235308-23def4e6c14b
 	github.com/gorilla/websocket v1.4.2 // indirect
 	github.com/grpc-ecosystem/go-grpc-middleware v1.3.0 // indirect
 	github.com/grpc-ecosystem/go-grpc-prometheus v1.2.0 // indirect
 	github.com/grpc-ecosystem/grpc-gateway v1.16.0 // indirect
 	github.com/jonboulle/clockwork v0.2.2 // indirect
 	github.com/kubernetes-csi/csi-lib-utils v0.9.1
 	github.com/soheilhy/cmux v0.1.5 // indirect
 	github.com/tmc/grpc-websocket-proxy v0.0.0-20201229170055-e5319fda7802 // indirect
 	github.com/xiang90/probing v0.0.0-20190116061207-43a291ad63a2 // indirect
 	go.etcd.io/bbolt v0.0.0-00010101000000-000000000000 // indirect
 	go.etcd.io/etcd v3.3.25+incompatible
 	golang.org/x/net v0.0.0-20201202161906-c7110b5ffcbb
 	golang.org/x/xerrors v0.0.0-20200804184101-5ec99f83aff1 // indirect
 	google.golang.org/grpc v1.33.1
 	google.golang.org/protobuf v1.24.0
 	k8s.io/klog v1.0.0
 	k8s.io/utils v0.0.0-20210305010621-2afb4311ab10
 )
--- a/csi/go.sum
+++ b/csi/go.sum
@ -31,11 +31,14 @@ github.com/alecthomas/template v0.0.0-20160405071501-a0175ee3bccc/go.mod h1:LOuy
 github.com/alecthomas/template v0.0.0-20190718012654-fb15b899a751/go.mod h1:LOuyumcjzFXgccqObfd/Ljyb9UuFJ6TxHnclSeseNhc=
 github.com/alecthomas/units v0.0.0-20151022065526-2efee857e7cf/go.mod h1:ybxpYRFXyAe+OPACYpWeL0wqObRcbAqCMya13uyzqw0=
 github.com/alecthomas/units v0.0.0-20190717042225-c3de453c63f4/go.mod h1:ybxpYRFXyAe+OPACYpWeL0wqObRcbAqCMya13uyzqw0=
 github.com/antihax/optional v1.0.0/go.mod h1:uupD/76wgC+ih3iEmQUL+0Ugr19nfwCT1kdvxnR2qWY=
 github.com/beorn7/perks v0.0.0-20180321164747-3a771d992973/go.mod h1:Dwedo/Wpr24TaqPxmxbtue+5NUziq4I4S80YR8gNf3Q=
 github.com/beorn7/perks v1.0.0/go.mod h1:KWe93zE9D1o94FZ5RNwFwVgaQK1VOXiVxmqh+CedLV8=
 github.com/beorn7/perks v1.0.1 h1:VlbKKnNfV8bJzeqoa4cOKqO6bYr3WgKZxO8Z16+hsOM=
 github.com/beorn7/perks v1.0.1/go.mod h1:G2ZrVWU2WbWT9wwq4/hrbKbnv/1ERSJQ0ibhJ6rlkpw=
 github.com/blang/semver v3.5.0+incompatible/go.mod h1:kRBLl5iJ+tD4TcOOxsy/0fnwebNt5EWlYSAyrTnjyyk=
 github.com/census-instrumentation/opencensus-proto v0.2.1/go.mod h1:f6KPmirojxKA12rnyqOA5BBL4O983OfeGPqjHWSTneU=
 github.com/cespare/xxhash/v2 v2.1.1 h1:6MnRN8NT7+YBpUIWxHtefFZOKTAPgGjpQSxqLNn0+qY=
 github.com/cespare/xxhash/v2 v2.1.1/go.mod h1:VGX0DQ3Q6kWi7AoAeZDth3/j3BFtOZR5XLFGgcrjCOs=
 github.com/chzyer/logex v1.1.10/go.mod h1:+Ywpsq7O8HXn0nuIou7OrIPyXbp3wmkHB+jjWRnGsAI=
 github.com/chzyer/readline v0.0.0-20180603132655-2972be24d48e/go.mod h1:nSuG5e5PlCu98SY8svDHJxuZscDgtXS6KTTbou5AhLI=
@ -43,12 +46,25 @@ github.com/chzyer/test v0.0.0-20180213035817-a1ea475d72b1/go.mod h1:Q3SI9o4m/ZMn
 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/coreos/bbolt v1.3.5 h1:XFv7xaq7701j8ZSEzR28VohFYSlyakMyqNMU5FQH6Ac=
 github.com/coreos/bbolt v1.3.5/go.mod h1:G5EMThwa9y8QZGBClrRx5EY+Yw9kAhnjy3bSjsnlVTQ=
 github.com/coreos/etcd v3.3.25+incompatible h1:0GQEw6h3YnuOVdtwygkIfJ+Omx0tZ8/QkVyXI4LkbeY=
 github.com/coreos/etcd v3.3.25+incompatible/go.mod h1:uF7uidLiAD3TWHmW31ZFd/JWoc32PjwdhPthX9715RE=
 github.com/coreos/go-semver v0.3.0 h1:wkHLiw0WNATZnSG7epLsujiMCgPAc9xhjJ4tgnAxmfM=
 github.com/coreos/go-semver v0.3.0/go.mod h1:nnelYz7RCh+5ahJtPPxZlU+153eP4D4r3EedlOD2RNk=
 github.com/coreos/go-systemd v0.0.0-20191104093116-d3cd4ed1dbcf h1:iW4rZ826su+pqaw19uhpSCzhj44qo35pNgKFGqzDKkU=
 github.com/coreos/go-systemd v0.0.0-20191104093116-d3cd4ed1dbcf/go.mod h1:F5haX7vjVVG0kc13fIWeqUViNPyEJxv/OmvnBo0Yme4=
 github.com/coreos/pkg v0.0.0-20180928190104-399ea9e2e55f h1:lBNOc5arjvs8E5mO2tbpBpLoyyu8B6e44T7hJy6potg=
 github.com/coreos/pkg v0.0.0-20180928190104-399ea9e2e55f/go.mod h1:E3G3o1h8I7cfcXa63jLwjI0eiQQMgzzUDFVpN/nH/eA=
 github.com/davecgh/go-spew v1.1.0/go.mod h1:J7Y8YcW2NihsgmVo/mv3lAwl/skON4iLHjSsI+c5H38=
 github.com/davecgh/go-spew v1.1.1 h1:vj9j/u1bqnvCEfJOwUhtlOARqs3+rkHYY13jYWTU97c=
 github.com/davecgh/go-spew v1.1.1/go.mod h1:J7Y8YcW2NihsgmVo/mv3lAwl/skON4iLHjSsI+c5H38=
 github.com/dgrijalva/jwt-go v3.2.0+incompatible h1:7qlOGliEKZXTDg6OTjfoBKDXWrumCAMpl/TFQ4/5kLM=
 github.com/dgrijalva/jwt-go v3.2.0+incompatible/go.mod h1:E3ru+11k8xSBh+hMPgOLZmtrrCbhqsmaPHjLKYnJCaQ=
 github.com/docker/spdystream v0.0.0-20160310174837-449fdfce4d96/go.mod h1:Qh8CwZgvJUkLughtfhJv5dyTYa91l1fOUCrgjqmcifM=
 github.com/docopt/docopt-go v0.0.0-20180111231733-ee0de3bc6815/go.mod h1:WwZ+bS3ebgob9U8Nd0kOddGdZWjyMGR8Wziv+TBNwSE=
 github.com/dustin/go-humanize v1.0.0 h1:VSnTsYCnlFHaM2/igO1h6X3HA71jcobQuxemgkq4zYo=
 github.com/dustin/go-humanize v1.0.0/go.mod h1:HtrtbFcZ19U5GC7JDqmcUSB87Iq5E25KnS6fMYU6eOk=
 github.com/elazarl/goproxy v0.0.0-20180725130230-947c36da3153/go.mod h1:/Zj4wYkgs4iZTTu3o/KG3Itv/qCCa8VVMlb3i9OVuzc=
 github.com/emicklei/go-restful v0.0.0-20170410110728-ff4f55a20633/go.mod h1:otzb+WCGbkyDHkqmQmT5YD2WR4BBwUdeQoFo8l/7tVs=
 github.com/envoyproxy/go-control-plane v0.9.0/go.mod h1:YTl/9mNaCwkRvm6d1a2C3ymFceY/DCBVvsKhRF0iEA4=
@ -57,6 +73,7 @@ github.com/evanphx/json-patch v4.9.0+incompatible/go.mod h1:50XU6AFN0ol/bzJsmQLi
 github.com/fsnotify/fsnotify v1.4.7/go.mod h1:jwhsz4b93w/PPRr/qN1Yymfu8t87LnFCMoQvtojpjFo=
 github.com/fsnotify/fsnotify v1.4.9/go.mod h1:znqG4EE+3YCdAaPaxE2ZRY/06pZUdp0tY4IgpuI1SZQ=
 github.com/ghodss/yaml v0.0.0-20150909031657-73d445a93680/go.mod h1:4dBDuWmgqj2HViK6kFavaiC9ZROes6MMH2rRYeMEF04=
 github.com/ghodss/yaml v1.0.0/go.mod h1:4dBDuWmgqj2HViK6kFavaiC9ZROes6MMH2rRYeMEF04=
 github.com/go-gl/glfw/v3.3/glfw v0.0.0-20191125211704-12ad95a8df72/go.mod h1:tQ2UAYgL5IevRw8kRxooKSPJfGvJ9fJQFa0TUsXzTg8=
 github.com/go-kit/kit v0.8.0/go.mod h1:xBxKIO96dXMWWy0MnWVtmwkA9/13aqxPnvrjFYMA2as=
 github.com/go-kit/kit v0.9.0/go.mod h1:xBxKIO96dXMWWy0MnWVtmwkA9/13aqxPnvrjFYMA2as=
@ -71,10 +88,14 @@ github.com/go-openapi/spec v0.0.0-20160808142527-6aced65f8501/go.mod h1:J8+jY1nA
 github.com/go-openapi/swag v0.0.0-20160704191624-1d0bd113de87/go.mod h1:DXUve3Dpr1UfpPtxFw+EFuQ41HhCWZfha5jSVRG7C7I=
 github.com/go-stack/stack v1.8.0/go.mod h1:v0f6uXyyMGvRgIKkXu+yp6POWl0qKG85gN/melR3HDY=
 github.com/gogo/protobuf v1.1.1/go.mod h1:r8qH/GZQm5c6nD/R0oafs1akxWv10x8SbQlK7atdtwQ=
 github.com/gogo/protobuf v1.3.1 h1:DqDEcV5aeaTmdFBePNpYsp3FlcVH/2ISVVM9Qf8PSls=
 github.com/gogo/protobuf v1.3.1/go.mod h1:SlYgWuQ5SjCEi6WLHjHCa1yvBfUnHcTbrrZtXPKa29o=
 github.com/gogo/protobuf v1.3.2 h1:Ov1cvc58UF3b5XjBnZv7+opcTcQFZebYjWzi34vdm4Q=
 github.com/gogo/protobuf v1.3.2/go.mod h1:P1XiOD3dCwIKUDQYPy72D8LYyHL2YPYrpS2s69NZV8Q=
 github.com/golang/glog v0.0.0-20160126235308-23def4e6c14b h1:VKtxabqXZkF25pY9ekfRL6a582T4P37/31XEstQ5p58=
 github.com/golang/glog v0.0.0-20160126235308-23def4e6c14b/go.mod h1:SBH7ygxi8pfUlaOkMMuAQtPIUF8ecWP5IEl/CR7VP2Q=
 github.com/golang/groupcache v0.0.0-20190702054246-869f871628b6/go.mod h1:cIg4eruTrX1D+g88fzRXU5OdNfaM+9IcxsU14FzY7Hc=
 github.com/golang/groupcache v0.0.0-20191227052852-215e87163ea7 h1:5ZkaAPbicIKTF2I64qf5Fh8Aa83Q/dnOafMYV0OMwjA=
 github.com/golang/groupcache v0.0.0-20191227052852-215e87163ea7/go.mod h1:cIg4eruTrX1D+g88fzRXU5OdNfaM+9IcxsU14FzY7Hc=
 github.com/golang/mock v1.1.1/go.mod h1:oTYuIxOrZwtPieC+H1uAHpcLFnEyAGVDL/k47Jfbm0A=
 github.com/golang/mock v1.2.0/go.mod h1:oTYuIxOrZwtPieC+H1uAHpcLFnEyAGVDL/k47Jfbm0A=
@ -92,6 +113,7 @@ github.com/golang/protobuf v1.4.1/go.mod h1:U8fpvMrcmy5pZrNK1lt4xCsGvpyWQ/VVv6QD
 github.com/golang/protobuf v1.4.2 h1:+Z5KGCizgyZCbGh1KZqA0fcLLkwbsjIzS4aV2v7wJX0=
 github.com/golang/protobuf v1.4.2/go.mod h1:oDoupMAO8OvCJWAcko0GGGIgR6R6ocIYbsSw735rRwI=
 github.com/google/btree v0.0.0-20180813153112-4030bb1f1f0c/go.mod h1:lNA+9X1NB3Zf8V7Ke586lFgjr2dZNuvo3lPJSGZ5JPQ=
 github.com/google/btree v1.0.0 h1:0udJVsspx3VBr5FwtLhQQtuAsVc79tTq0ocGIPAU6qo=
 github.com/google/btree v1.0.0/go.mod h1:lNA+9X1NB3Zf8V7Ke586lFgjr2dZNuvo3lPJSGZ5JPQ=
 github.com/google/go-cmp v0.2.0/go.mod h1:oXzfMopK8JAjlY9xF4vHSVASa0yLyX7SntLO5aqRK0M=
 github.com/google/go-cmp v0.3.0/go.mod h1:8QqcDgzrUqlUb/G2PQTWiueGozuR1884gddMywk6iLU=
@ -105,24 +127,38 @@ github.com/google/pprof v0.0.0-20181206194817-3ea8567a2e57/go.mod h1:zfwlbNMJ+OI
 github.com/google/pprof v0.0.0-20190515194954-54271f7e092f/go.mod h1:zfwlbNMJ+OItoe0UupaVj+oy1omPYYDuagoSzA8v9mc=
 github.com/google/pprof v0.0.0-20191218002539-d4f498aebedc/go.mod h1:ZgVRPoUq/hfqzAqh7sHMqb3I9Rq5C59dIz2SbBwJ4eM=
 github.com/google/renameio v0.1.0/go.mod h1:KWCgfxg9yswjAJkECMjeO8J8rahYeXnNhOm40UhjYkI=
 github.com/google/uuid v1.1.1 h1:Gkbcsh/GbpXz7lPftLA3P6TYMwjCLYm83jiFQZF/3gY=
 github.com/google/uuid v1.1.1/go.mod h1:TIyPZe4MgqvfeYDBFedMoGGpEw/LqOeaOT+nhxU+yHo=
 github.com/googleapis/gax-go/v2 v2.0.4/go.mod h1:0Wqv26UfaUD9n4G6kQubkQ+KchISgw+vpHVxEJEs9eg=
 github.com/googleapis/gax-go/v2 v2.0.5/go.mod h1:DWXyrwAJ9X0FpwwEdw+IPEYBICEFu5mhpdKc/us6bOk=
 github.com/googleapis/gnostic v0.4.1/go.mod h1:LRhVm6pbyptWbWbuZ38d1eyptfvIytN3ir6b65WBswg=
 github.com/gorilla/websocket v1.4.2 h1:+/TMaTYc4QFitKJxsQ7Yye35DkWvkdLcvGKqM+x0Ufc=
 github.com/gorilla/websocket v1.4.2/go.mod h1:YR8l580nyteQvAITg2hZ9XVh4b55+EU/adAjf1fMHhE=
 github.com/gregjones/httpcache v0.0.0-20180305231024-9cad4c3443a7/go.mod h1:FecbI9+v66THATjSRHfNgh1IVFe/9kFxbXtjV0ctIMA=
 github.com/grpc-ecosystem/go-grpc-middleware v1.3.0 h1:+9834+KizmvFV7pXQGSXQTsaWhq2GjuNUt0aUU0YBYw=
 github.com/grpc-ecosystem/go-grpc-middleware v1.3.0/go.mod h1:z0ButlSOZa5vEBq9m2m2hlwIgKw+rp3sdCBRoJY+30Y=
 github.com/grpc-ecosystem/go-grpc-prometheus v1.2.0 h1:Ovs26xHkKqVztRpIrF/92BcuyuQ/YW4NSIpoGtfXNho=
 github.com/grpc-ecosystem/go-grpc-prometheus v1.2.0/go.mod h1:8NvIoxWQoOIhqOTXgfV/d3M/q6VIi02HzZEHgUlZvzk=
 github.com/grpc-ecosystem/grpc-gateway v1.16.0 h1:gmcG1KaJ57LophUzW0Hy8NmPhnMZb4M0+kPpLofRdBo=
 github.com/grpc-ecosystem/grpc-gateway v1.16.0/go.mod h1:BDjrQk3hbvj6Nolgz8mAMFbcEtjT1g+wF4CSlocrBnw=
 github.com/hashicorp/golang-lru v0.5.0/go.mod h1:/m3WP610KZHVQ1SGc6re/UDhFvYD7pJ4Ao+sR/qLZy8=
 github.com/hashicorp/golang-lru v0.5.1/go.mod h1:/m3WP610KZHVQ1SGc6re/UDhFvYD7pJ4Ao+sR/qLZy8=
 github.com/hpcloud/tail v1.0.0/go.mod h1:ab1qPbhIpdTxEkNHXyeSf5vhxWSCs/tWer42PpOxQnU=
 github.com/ianlancetaylor/demangle v0.0.0-20181102032728-5e5cf60278f6/go.mod h1:aSSvb/t6k1mPoxDqO4vJh6VOCGPwU4O0C2/Eqndh1Sc=
 github.com/imdario/mergo v0.3.5/go.mod h1:2EnlNZ0deacrJVfApfmtdGgDfMuh/nq6Ok1EcJh5FfA=
 github.com/jonboulle/clockwork v0.2.2 h1:UOGuzwb1PwsrDAObMuhUnj0p5ULPj8V/xJ7Kx9qUBdQ=
 github.com/jonboulle/clockwork v0.2.2/go.mod h1:Pkfl5aHPm1nk2H9h0bjmnJD/BcgbGXUBGnn1kMkgxc8=
 github.com/json-iterator/go v1.1.6/go.mod h1:+SdeFBvtyEkXs7REEP0seUULqWtbJapLOCVDaaPEHmU=
 github.com/json-iterator/go v1.1.10 h1:Kz6Cvnvv2wGdaG/V8yMvfkmNiXq9Ya2KUv4rouJJr68=
 github.com/json-iterator/go v1.1.10/go.mod h1:KdQUCv79m/52Kvf8AW2vK1V8akMuk1QjK/uOdHXbAo4=
 github.com/jstemmer/go-junit-report v0.0.0-20190106144839-af01ea7f8024/go.mod h1:6v2b51hI/fHJwM22ozAgKL4VKDeJcHhJFhtBdhmNjmU=
 github.com/jstemmer/go-junit-report v0.9.1/go.mod h1:Brl9GWCQeLvo8nXZwPNNblvFj/XSXhF0NWZEnDohbsk=
 github.com/julienschmidt/httprouter v1.2.0/go.mod h1:SYymIcj16QtmaHHD7aYtjjsJG7VTCxuUUipMqKk8s4w=
 github.com/kisielk/errcheck v1.2.0/go.mod h1:/BMXB+zMLi60iA8Vv6Ksmxu/1UDYcXs4uQLJ+jE2L00=
 github.com/kisielk/errcheck v1.5.0/go.mod h1:pFxgyoBC7bSaBwPgfKdkLd5X25qrDl4LWUI2bnpBCr8=
 github.com/kisielk/gotool v1.0.0/go.mod h1:XhKaO+MFFWcvkIS/tQcRk01m1F5IRFswLeQ+oQHNcck=
 github.com/konsorten/go-windows-terminal-sequences v1.0.1/go.mod h1:T0+1ngSBFLxvqU3pZ+m/2kptfBszLMUkC4ZK/EgS/cQ=
 github.com/konsorten/go-windows-terminal-sequences v1.0.3 h1:CE8S1cTafDpPvMhIxNJKvHsGVBgn1xWYf1NbHQhywc8=
 github.com/konsorten/go-windows-terminal-sequences v1.0.3/go.mod h1:T0+1ngSBFLxvqU3pZ+m/2kptfBszLMUkC4ZK/EgS/cQ=
 github.com/kr/logfmt v0.0.0-20140226030751-b84e30acd515/go.mod h1:+0opPa2QZZtGFBFZlji/RkVcI2GknAs/DXo4wKdlNEc=
 github.com/kr/pretty v0.1.0/go.mod h1:dAy3ld7l9f0ibDNOQOHHMYYIIbhfbHSm3C4ZsoJORNo=
@ -135,11 +171,14 @@ github.com/kubernetes-csi/csi-lib-utils v0.9.1 h1:sGq6ifVujfMSkfTsMZip44Ttv8SDXv
 github.com/kubernetes-csi/csi-lib-utils v0.9.1/go.mod h1:8E2jVUX9j3QgspwHXa6LwyN7IHQDjW9jX3kwoWnSC+M=
 github.com/mailru/easyjson v0.0.0-20160728113105-d5b7844b561a/go.mod h1:C1wdFJiN94OJF2b5HbByQZoLdCWB1Yqtg26g4irojpc=
 github.com/matttproud/golang_protobuf_extensions v1.0.1/go.mod h1:D8He9yQNgCq6Z5Ld7szi9bcBfOoFv/3dc6xSMkL2PC0=
 github.com/matttproud/golang_protobuf_extensions v1.0.2-0.20181231171920-c182affec369 h1:I0XW9+e1XWDxdcEniV4rQAIOPUGDq67JSCiRCgGCZLI=
 github.com/matttproud/golang_protobuf_extensions v1.0.2-0.20181231171920-c182affec369/go.mod h1:BSXmuO+STAnVfrANrmjBb36TMTDstsz7MSK+HVaYKv4=
 github.com/moby/term v0.0.0-20200312100748-672ec06f55cd/go.mod h1:DdlQx2hp0Ss5/fLikoLlEeIYiATotOjgB//nb973jeo=
 github.com/modern-go/concurrent v0.0.0-20180228061459-e0a39a4cb421/go.mod h1:6dJC0mAP4ikYIbvyc7fijjWJddQyLn8Ig3JB5CqoB9Q=
 github.com/modern-go/concurrent v0.0.0-20180306012644-bacd9c7ef1dd h1:TRLaZ9cD/w8PVh93nsPXa1VrQ6jlwL5oN8l14QlcNfg=
 github.com/modern-go/concurrent v0.0.0-20180306012644-bacd9c7ef1dd/go.mod h1:6dJC0mAP4ikYIbvyc7fijjWJddQyLn8Ig3JB5CqoB9Q=
 github.com/modern-go/reflect2 v0.0.0-20180701023420-4b7aa43c6742/go.mod h1:bx2lNnkwVCuqBIxFjflWJWanXIb3RllmbCylyMrvgv0=
 github.com/modern-go/reflect2 v1.0.1 h1:9f412s+6RmYXLWZSEzVVgPGK7C2PphHj5RJrvfx9AWI=
 github.com/modern-go/reflect2 v1.0.1/go.mod h1:bx2lNnkwVCuqBIxFjflWJWanXIb3RllmbCylyMrvgv0=
 github.com/munnerz/goautoneg v0.0.0-20120707110453-a547fc61f48d/go.mod h1:+n7T8mK8HuQTcFwEeznm/DIxMOiR9yIdICNftLE1DvQ=
 github.com/mwitkow/go-conntrack v0.0.0-20161129095857-cc309e4a2223/go.mod h1:qRWi+5nqEBWmkhHvq77mSJWrCKwh8bxhgT7d/eI7P4U=
@ -149,28 +188,38 @@ github.com/onsi/ginkgo v1.6.0/go.mod h1:lLunBs/Ym6LB5Z9jYTR76FiuTmxDTDusOGeTQH+W
 github.com/onsi/ginkgo v1.11.0/go.mod h1:lLunBs/Ym6LB5Z9jYTR76FiuTmxDTDusOGeTQH+WWjE=
 github.com/onsi/gomega v0.0.0-20170829124025-dcabb60a477c/go.mod h1:C1qb7wdrVGGVU+Z6iS04AVkA3Q65CEZX59MT0QO5uiA=
 github.com/onsi/gomega v1.7.0/go.mod h1:ex+gbHU/CVuBBDIJjb2X0qEXbFg53c61hWP/1CpauHY=
 github.com/opentracing/opentracing-go v1.1.0/go.mod h1:UkNAQd3GIcIGf0SeVgPpRdFStlNbqXla1AfSYxPUl2o=
 github.com/peterbourgon/diskv v2.0.1+incompatible/go.mod h1:uqqh8zWWbv1HBMNONnaR/tNboyR3/BZd58JJSHlUSCU=
 github.com/pkg/errors v0.8.0/go.mod h1:bwawxfHBFNV+L2hUp1rHADufV3IMtnDRdf1r5NINEl0=
 github.com/pkg/errors v0.8.1/go.mod h1:bwawxfHBFNV+L2hUp1rHADufV3IMtnDRdf1r5NINEl0=
 github.com/pkg/errors v0.9.1 h1:FEBLx1zS214owpjy7qsBeixbURkuhQAwrK5UwLGTwt4=
 github.com/pkg/errors v0.9.1/go.mod h1:bwawxfHBFNV+L2hUp1rHADufV3IMtnDRdf1r5NINEl0=
 github.com/pmezard/go-difflib v1.0.0 h1:4DBwDE0NGyQoBHbLQYPwSUPoCMWR5BEzIk/f1lZbAQM=
 github.com/pmezard/go-difflib v1.0.0/go.mod h1:iKH77koFhYxTK1pcRnkKkqfTogsbg7gZNVY4sRDYZ/4=
 github.com/prometheus/client_golang v0.9.1/go.mod h1:7SWBe2y4D6OKWSNQJUaRYU/AaXPKyh/dDVn+NZz0KFw=
 github.com/prometheus/client_golang v1.0.0/go.mod h1:db9x61etRT2tGnBNRi70OPL5FsnadC4Ky3P0J6CfImo=
 github.com/prometheus/client_golang v1.7.1 h1:NTGy1Ja9pByO+xAeH/qiWnLrKtr3hJPNjaVUwnjpdpA=
 github.com/prometheus/client_golang v1.7.1/go.mod h1:PY5Wy2awLA44sXw4AOSfFBetzPP4j5+D6mVACh+pe2M=
 github.com/prometheus/client_model v0.0.0-20180712105110-5c3871d89910/go.mod h1:MbSGuTsp3dbXC40dX6PRTWyKYBIrTGTE9sqQNg2J8bo=
 github.com/prometheus/client_model v0.0.0-20190129233127-fd36f4220a90/go.mod h1:xMI15A0UPsDsEKsMN9yxemIoYk6Tm2C1GtYGdfGttqA=
 github.com/prometheus/client_model v0.0.0-20190812154241-14fe0d1b01d4/go.mod h1:xMI15A0UPsDsEKsMN9yxemIoYk6Tm2C1GtYGdfGttqA=
 github.com/prometheus/client_model v0.2.0 h1:uq5h0d+GuxiXLJLNABMgp2qUWDPiLvgCzz2dUR+/W/M=
 github.com/prometheus/client_model v0.2.0/go.mod h1:xMI15A0UPsDsEKsMN9yxemIoYk6Tm2C1GtYGdfGttqA=
 github.com/prometheus/common v0.4.1/go.mod h1:TNfzLD0ON7rHzMJeJkieUDPYmFC7Snx/y86RQel1bk4=
 github.com/prometheus/common v0.10.0 h1:RyRA7RzGXQZiW+tGMr7sxa85G1z0yOpM1qq5c8lNawc=
 github.com/prometheus/common v0.10.0/go.mod h1:Tlit/dnDKsSWFlCLTWaA1cyBgKHSMdTB80sz/V91rCo=
 github.com/prometheus/procfs v0.0.0-20181005140218-185b4288413d/go.mod h1:c3At6R/oaqEKCNdg8wHV1ftS6bRYblBhIjjI8uT2IGk=
 github.com/prometheus/procfs v0.0.2/go.mod h1:TjEm7ze935MbeOT/UhFTIMYKhuLP4wbCsTZCD3I8kEA=
 github.com/prometheus/procfs v0.1.3 h1:F0+tqvhOksq22sc6iCHF5WGlWjdwj92p0udFh1VFBS8=
 github.com/prometheus/procfs v0.1.3/go.mod h1:lV6e/gmhEcM9IjHGsFOCxxuZ+z1YqCvr4OA4YeYWdaU=
 github.com/rogpeppe/fastuuid v1.2.0/go.mod h1:jVj6XXZzXRy/MSR5jhDC/2q6DgLz+nrA6LYCDYWNEvQ=
 github.com/rogpeppe/go-internal v1.3.0/go.mod h1:M8bDsm7K2OlrFYOpmOWEs/qY81heoFRclV5y23lUDJ4=
 github.com/sirupsen/logrus v1.2.0/go.mod h1:LxeOpSwHxABJmUn/MG1IvRgCAasNZTLOkJPxbbu5VWo=
 github.com/sirupsen/logrus v1.4.2/go.mod h1:tLMulIdttU9McNUspp0xgXVQah82FyeX6MwdIuYE2rE=
 github.com/sirupsen/logrus v1.6.0 h1:UBcNElsrwanuuMsnGSlYmtmgbb23qDR5dG+6X6Oo89I=
 github.com/sirupsen/logrus v1.6.0/go.mod h1:7uNnSEd1DgxDLC74fIahvMZmmYsHGZGEOFrfsX/uA88=
 github.com/soheilhy/cmux v0.1.5 h1:jjzc5WVemNEDTLwv9tlmemhC73tI08BNOIGwBOo10Js=
 github.com/soheilhy/cmux v0.1.5/go.mod h1:T7TcVDs9LWfQgPlPsdngu6I6QIoyIFZDDC6sNE1GqG0=
 github.com/spf13/afero v1.2.2/go.mod h1:9ZxEEn6pIJ8Rxe320qSDBk6AsU0r9pR7Q4OcevTdifk=
 github.com/spf13/pflag v0.0.0-20170130214245-9ff6c6923cff/go.mod h1:DYY7MBk1bdzusC3SYhjObp+wFpr4gzcvqqNjLnInEg4=
 github.com/spf13/pflag v1.0.3/go.mod h1:DYY7MBk1bdzusC3SYhjObp+wFpr4gzcvqqNjLnInEg4=
@ -182,11 +231,24 @@ github.com/stretchr/testify v1.3.0/go.mod h1:M5WIy9Dh21IEIfnGCwXGc5bZfKNJtfHm1UV
 github.com/stretchr/testify v1.4.0/go.mod h1:j7eGeouHqKxXV5pUuKE4zz7dFj8WfuZ+81PSLYec5m4=
 github.com/stretchr/testify v1.5.1 h1:nOGnQDM7FYENwehXlg/kFVnos3rEvtKTjRvOWSzb6H4=
 github.com/stretchr/testify v1.5.1/go.mod h1:5W2xD1RspED5o8YsWQXVCued0rvSQ+mT+I5cxcmMvtA=
 github.com/tmc/grpc-websocket-proxy v0.0.0-20201229170055-e5319fda7802 h1:uruHq4dN7GR16kFc5fp3d1RIYzJW5onx8Ybykw2YQFA=
 github.com/tmc/grpc-websocket-proxy v0.0.0-20201229170055-e5319fda7802/go.mod h1:ncp9v5uamzpCO7NfCPTXjqaC+bZgJeR0sMTm6dMHP7U=
 github.com/xiang90/probing v0.0.0-20190116061207-43a291ad63a2 h1:eY9dn8+vbi4tKz5Qo6v2eYzo7kUS51QINcR5jNpbZS8=
 github.com/xiang90/probing v0.0.0-20190116061207-43a291ad63a2/go.mod h1:UETIi67q53MR2AWcXfiuqkDkRtnGDLqkBTpCHuJHxtU=
 github.com/yuin/goldmark v1.1.27/go.mod h1:3hX8gzYuyVAZsxl0MRgGTJEmQBFcNTphYh9decYSb74=
 github.com/yuin/goldmark v1.2.1/go.mod h1:3hX8gzYuyVAZsxl0MRgGTJEmQBFcNTphYh9decYSb74=
 go.etcd.io/bbolt v1.3.5 h1:XAzx9gjCb0Rxj7EoqcClPD1d5ZBxZJk0jbuoPHenBt0=
 go.etcd.io/bbolt v1.3.5/go.mod h1:G5EMThwa9y8QZGBClrRx5EY+Yw9kAhnjy3bSjsnlVTQ=
 go.etcd.io/etcd v3.3.25+incompatible h1:V1RzkZJj9LqsJRy+TUBgpWSbZXITLB819lstuTFoZOY=
 go.etcd.io/etcd v3.3.25+incompatible/go.mod h1:yaeTdrJi5lOmYerz05bd8+V7KubZs8YSFZfzsF9A6aI=
 go.opencensus.io v0.21.0/go.mod h1:mSImk1erAIZhrmZN+AvHh14ztQfjbGwt4TtuofqLduU=
 go.opencensus.io v0.22.0/go.mod h1:+kGneAE2xo2IficOXnaByMWTGM9T73dGwxeWcUqIpI8=
 go.opencensus.io v0.22.2/go.mod h1:yxeiOL68Rb0Xd1ddK5vPZ/oVn4vY4Ynel7k9FzqtOIw=
 go.uber.org/atomic v1.4.0 h1:cxzIVoETapQEqDhQu3QfnvXAV4AlzcvUCxkVUFw3+EU=
 go.uber.org/atomic v1.4.0/go.mod h1:gD2HeocX3+yG+ygLZcrzQJaqmWj9AIm7n08wl/qW/PE=
 go.uber.org/multierr v1.1.0 h1:HoEmRHQPVSqub6w2z2d2EOVs2fjyFRGyofhKuyDq0QI=
 go.uber.org/multierr v1.1.0/go.mod h1:wR5kodmAFQ0UK8QlbwjlSNy0Z68gJhDJUG5sjR94q/0=
 go.uber.org/zap v1.10.0 h1:ORx85nbTijNz8ljznvCMR1ZBIPKFn3jQrag10X2AsuM=
 go.uber.org/zap v1.10.0/go.mod h1:vwi/ZaCAaUcBkycHslxD9B2zi4UTXhF60s6SWpuDF0Q=
 golang.org/x/crypto v0.0.0-20180904163835-0709b304e793/go.mod h1:6SG95UA2DQfeDnfUPMdvaQW0Q7yPrPDi9nlGo2tz2b4=
 golang.org/x/crypto v0.0.0-20190308221718-c2843e01d9a2/go.mod h1:djNgcEr1/C05ACkg1iLfiJU5Ep61QUkGW8qpdssI0+w=
@ -194,6 +256,7 @@ golang.org/x/crypto v0.0.0-20190510104115-cbcb75029529/go.mod h1:yigFU9vqHzYiE8U
 golang.org/x/crypto v0.0.0-20190605123033-f99c8df09eb5/go.mod h1:yigFU9vqHzYiE8UmvKecakEJjdnWj3jj499lnFckfCI=
 golang.org/x/crypto v0.0.0-20191011191535-87dc89f01550/go.mod h1:yigFU9vqHzYiE8UmvKecakEJjdnWj3jj499lnFckfCI=
 golang.org/x/crypto v0.0.0-20191206172530-e9b2fee46413/go.mod h1:LzIPMQfyMNhhGPhUkYOs5KpL4U8rLKemX1yGLhDgUto=
 golang.org/x/crypto v0.0.0-20200622213623-75b288015ac9 h1:psW17arqaxU48Z5kZ0CQnkZWQJsqcURM6tKiBApRjXI=
 golang.org/x/crypto v0.0.0-20200622213623-75b288015ac9/go.mod h1:LzIPMQfyMNhhGPhUkYOs5KpL4U8rLKemX1yGLhDgUto=
 golang.org/x/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=
@ -213,6 +276,8 @@ golang.org/x/mobile v0.0.0-20190719004257-d2bd2a29d028/go.mod h1:E/iHnbuqvinMTCc
 golang.org/x/mod v0.0.0-20190513183733-4bf6d317e70e/go.mod h1:mXi4GBBbnImb6dmsKGUJ2LatrhH/nqhxcFungHvyanc=
 golang.org/x/mod v0.1.0/go.mod h1:0QHyrYULN0/3qlju5TqG8bIK38QM8yzMo5ekMj3DlcY=
 golang.org/x/mod v0.1.1-0.20191105210325-c90efee705ee/go.mod h1:QqPTAvyqsEbceGzBzNggFXnrqF1CaUcvgkdR5Ot7KZg=
 golang.org/x/mod v0.2.0/go.mod h1:s0Qsj1ACt9ePp/hMypM3fl4fZqREWJwdYDEqhRiZZUA=
 golang.org/x/mod v0.3.0/go.mod h1:s0Qsj1ACt9ePp/hMypM3fl4fZqREWJwdYDEqhRiZZUA=
 golang.org/x/net v0.0.0-20180724234803-3673e40ba225/go.mod h1:mL1N/T3taQHkDXs73rZJwtUhF3w3ftmwwsq0BUmARs4=
 golang.org/x/net v0.0.0-20180906233101-161cd47e91fd/go.mod h1:mL1N/T3taQHkDXs73rZJwtUhF3w3ftmwwsq0BUmARs4=
 golang.org/x/net v0.0.0-20181114220301-adae6a3d119a/go.mod h1:mL1N/T3taQHkDXs73rZJwtUhF3w3ftmwwsq0BUmARs4=
@ -226,20 +291,26 @@ golang.org/x/net v0.0.0-20190603091049-60506f45cf65/go.mod h1:HSz+uSET+XFnRR8LxR
 golang.org/x/net v0.0.0-20190613194153-d28f0bde5980/go.mod h1:z5CRVTTTmAJ677TzLLGU+0bjPO0LkuOLi4/5GtJWs/s=
 golang.org/x/net v0.0.0-20190620200207-3b0461eec859/go.mod h1:z5CRVTTTmAJ677TzLLGU+0bjPO0LkuOLi4/5GtJWs/s=
 golang.org/x/net v0.0.0-20191209160850-c0dbc17a3553/go.mod h1:z5CRVTTTmAJ677TzLLGU+0bjPO0LkuOLi4/5GtJWs/s=
 golang.org/x/net v0.0.0-20200226121028-0de0cce0169b/go.mod h1:z5CRVTTTmAJ677TzLLGU+0bjPO0LkuOLi4/5GtJWs/s=
 golang.org/x/net v0.0.0-20200324143707-d3edc9973b7e/go.mod h1:qpuaurCH72eLCgpAm/N6yyVIVM9cpaDIP3A8BGJEC5A=
 golang.org/x/net v0.0.0-20200707034311-ab3426394381 h1:VXak5I6aEWmAXeQjA+QSZzlgNrpq9mjcfDemuexIKsU=
 golang.org/x/net v0.0.0-20200707034311-ab3426394381/go.mod h1:/O7V0waA8r7cgGh81Ro3o1hOxt32SMVPicZroKQ2sZA=
 golang.org/x/net v0.0.0-20200822124328-c89045814202/go.mod h1:/O7V0waA8r7cgGh81Ro3o1hOxt32SMVPicZroKQ2sZA=
 golang.org/x/net v0.0.0-20201021035429-f5854403a974/go.mod h1:sp8m0HH+o8qH0wwXwYZr8TS3Oi6o0r6Gce1SSxlDquU=
 golang.org/x/net v0.0.0-20201202161906-c7110b5ffcbb h1:eBmm0M9fYhWpKZLjQUUKka/LtIxf46G4fxeEz5KJr9U=
 golang.org/x/net v0.0.0-20201202161906-c7110b5ffcbb/go.mod h1:sp8m0HH+o8qH0wwXwYZr8TS3Oi6o0r6Gce1SSxlDquU=
 golang.org/x/oauth2 v0.0.0-20180821212333-d2e6202438be/go.mod h1:N/0e6XlmueqKjAGxoOufVs8QHGRruUQn6yWY3a++T0U=
 golang.org/x/oauth2 v0.0.0-20190226205417-e64efc72b421/go.mod h1:gOpvHmFTYa4IltrdGE7lF6nIHvwfUNPOp7c8zoXwtLw=
 golang.org/x/oauth2 v0.0.0-20190604053449-0f29369cfe45/go.mod h1:gOpvHmFTYa4IltrdGE7lF6nIHvwfUNPOp7c8zoXwtLw=
 golang.org/x/oauth2 v0.0.0-20191202225959-858c2ad4c8b6/go.mod h1:gOpvHmFTYa4IltrdGE7lF6nIHvwfUNPOp7c8zoXwtLw=
 golang.org/x/oauth2 v0.0.0-20200107190931-bf48bf16ab8d/go.mod h1:gOpvHmFTYa4IltrdGE7lF6nIHvwfUNPOp7c8zoXwtLw=
 golang.org/x/sync v0.0.0-20180314180146-1d60e4601c6f/go.mod h1:RxMgew5VJxzue5/jJTE5uejpjVlOe/izrB70Jof72aM=
 golang.org/x/sync v0.0.0-20181108010431-42b317875d0f/go.mod h1:RxMgew5VJxzue5/jJTE5uejpjVlOe/izrB70Jof72aM=
 golang.org/x/sync v0.0.0-20181221193216-37e7f081c4d4/go.mod h1:RxMgew5VJxzue5/jJTE5uejpjVlOe/izrB70Jof72aM=
 golang.org/x/sync v0.0.0-20190227155943-e225da77a7e6/go.mod h1:RxMgew5VJxzue5/jJTE5uejpjVlOe/izrB70Jof72aM=
 golang.org/x/sync v0.0.0-20190423024810-112230192c58/go.mod h1:RxMgew5VJxzue5/jJTE5uejpjVlOe/izrB70Jof72aM=
 golang.org/x/sync v0.0.0-20190911185100-cd5d95a43a6e/go.mod h1:RxMgew5VJxzue5/jJTE5uejpjVlOe/izrB70Jof72aM=
 golang.org/x/sync v0.0.0-20201020160332-67f06af15bc9/go.mod h1:RxMgew5VJxzue5/jJTE5uejpjVlOe/izrB70Jof72aM=
 golang.org/x/sys v0.0.0-20180905080454-ebe1bf3edb33/go.mod h1:STP8DvDyc/dI5b8T5hshtkjS+E42TnysNCUPdjciGhY=
 golang.org/x/sys v0.0.0-20180909124046-d0be0721c37e/go.mod h1:STP8DvDyc/dI5b8T5hshtkjS+E42TnysNCUPdjciGhY=
 golang.org/x/sys v0.0.0-20181116152217-5ac8a444bdc5/go.mod h1:STP8DvDyc/dI5b8T5hshtkjS+E42TnysNCUPdjciGhY=
@ -255,9 +326,11 @@ golang.org/x/sys v0.0.0-20191005200804-aed5e4c7ecf9/go.mod h1:h1NjWce9XRLGQEsW7w
 golang.org/x/sys v0.0.0-20191204072324-ce4227a45e2e/go.mod h1:h1NjWce9XRLGQEsW7wpKNCjG9DtNlClVuFLEZdDNbEs=
 golang.org/x/sys v0.0.0-20191228213918-04cbcbbfeed8/go.mod h1:h1NjWce9XRLGQEsW7wpKNCjG9DtNlClVuFLEZdDNbEs=
 golang.org/x/sys v0.0.0-20200106162015-b016eb3dc98e/go.mod h1:h1NjWce9XRLGQEsW7wpKNCjG9DtNlClVuFLEZdDNbEs=
 golang.org/x/sys v0.0.0-20200202164722-d101bd2416d5/go.mod h1:h1NjWce9XRLGQEsW7wpKNCjG9DtNlClVuFLEZdDNbEs=
 golang.org/x/sys v0.0.0-20200302150141-5c8b2ff67527/go.mod h1:h1NjWce9XRLGQEsW7wpKNCjG9DtNlClVuFLEZdDNbEs=
 golang.org/x/sys v0.0.0-20200323222414-85ca7c5b95cd/go.mod h1:h1NjWce9XRLGQEsW7wpKNCjG9DtNlClVuFLEZdDNbEs=
 golang.org/x/sys v0.0.0-20200615200032-f1bc736245b1/go.mod h1:h1NjWce9XRLGQEsW7wpKNCjG9DtNlClVuFLEZdDNbEs=
 golang.org/x/sys v0.0.0-20200622214017-ed371f2e16b4 h1:5/PjkGUjvEU5Gl6BxmvKRPpqo2uNMv4rcHBMwzk/st8=
 golang.org/x/sys v0.0.0-20200622214017-ed371f2e16b4/go.mod h1:h1NjWce9XRLGQEsW7wpKNCjG9DtNlClVuFLEZdDNbEs=
 golang.org/x/sys v0.0.0-20200930185726-fdedc70b468f h1:+Nyd8tzPX9R7BWHguqsrbFdRx3WQ/1ib8I44HXV5yTA=
 golang.org/x/sys v0.0.0-20200930185726-fdedc70b468f/go.mod h1:h1NjWce9XRLGQEsW7wpKNCjG9DtNlClVuFLEZdDNbEs=
@ -268,6 +341,7 @@ 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/time v0.0.0-20181108054448-85acf8d2951c/go.mod h1:tRJNPiyCQ0inRvYxbN9jk5I+vvW/OXSQhTDSoE431IQ=
 golang.org/x/time v0.0.0-20190308202827-9d24e82272b4/go.mod h1:tRJNPiyCQ0inRvYxbN9jk5I+vvW/OXSQhTDSoE431IQ=
 golang.org/x/time v0.0.0-20191024005414-555d28b269f0 h1:/5xXl8Y5W96D+TtHSlonuFqGHIWVuyCkGJLwGh9JJFs=
 golang.org/x/time v0.0.0-20191024005414-555d28b269f0/go.mod h1:tRJNPiyCQ0inRvYxbN9jk5I+vvW/OXSQhTDSoE431IQ=
 golang.org/x/tools v0.0.0-20180917221912-90fa682c2a6e/go.mod h1:n7NCudcB/nEzxVGmLbDWY5pfWTLqBcC2KZ6jyYvM4mQ=
 golang.org/x/tools v0.0.0-20181011042414-1f849cf54d09/go.mod h1:n7NCudcB/nEzxVGmLbDWY5pfWTLqBcC2KZ6jyYvM4mQ=
@ -286,10 +360,14 @@ 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.0.0-20200619180055-7c47624df98f/go.mod h1:EkVYQZoAsY45+roYkvgYkIh4xh/qjgUK9TdY2XT94GE=
 golang.org/x/tools v0.0.0-20210106214847-113979e3529a/go.mod h1:emZCQorbCU4vsT4fOWvOPXz4eW1wZW4PmDk9uLelYpA=
 golang.org/x/xerrors v0.0.0-20190717185122-a985d3407aa7/go.mod h1:I/5z698sn9Ka8TeJc9MKroUUfqBBauWjQqLJ2OPfmY0=
 golang.org/x/xerrors v0.0.0-20191011141410-1b5146add898/go.mod h1:I/5z698sn9Ka8TeJc9MKroUUfqBBauWjQqLJ2OPfmY0=
 golang.org/x/xerrors v0.0.0-20191204190536-9bdfabe68543 h1:E7g+9GITq07hpfrRu66IVDexMakfv52eLZ2CXBWiKr4=
 golang.org/x/xerrors v0.0.0-20191204190536-9bdfabe68543/go.mod h1:I/5z698sn9Ka8TeJc9MKroUUfqBBauWjQqLJ2OPfmY0=
 golang.org/x/xerrors v0.0.0-20200804184101-5ec99f83aff1 h1:go1bK/D/BFZV2I8cIQd1NKEZ+0owSTG1fDTci4IqFcE=
 golang.org/x/xerrors v0.0.0-20200804184101-5ec99f83aff1/go.mod h1:I/5z698sn9Ka8TeJc9MKroUUfqBBauWjQqLJ2OPfmY0=
@ -310,6 +388,8 @@ google.golang.org/genproto v0.0.0-20190801165951-fa694d86fc64/go.mod h1:DMBHOl98
 google.golang.org/genproto v0.0.0-20190819201941-24fa4b261c55/go.mod h1:DMBHOl98Agz4BDEuKkezgsaosCRResVns1a3J2ZsMNc=
 google.golang.org/genproto v0.0.0-20190911173649-1774047e7e51/go.mod h1:IbNlFCBrqXvoKpeg0TB2l7cyZUmoaFKYIwrEpbDKLA8=
 google.golang.org/genproto v0.0.0-20191230161307-f3c370f40bfb/go.mod h1:n3cpQtvxv34hfy77yVDNjmbRyujviMdxYliBSkLhpCc=
 google.golang.org/genproto v0.0.0-20200423170343-7949de9c1215/go.mod h1:55QSHmfGQM9UVYDPBsyGGes0y52j32PQ3BqQfXhyH3c=
 google.golang.org/genproto v0.0.0-20200513103714-09dca8ec2884/go.mod h1:55QSHmfGQM9UVYDPBsyGGes0y52j32PQ3BqQfXhyH3c=
 google.golang.org/genproto v0.0.0-20200526211855-cb27e3aa2013 h1:+kGHl1aib/qcwaRi1CbqBZ1rk19r85MNUf8HaBghugY=
 google.golang.org/genproto v0.0.0-20200526211855-cb27e3aa2013/go.mod h1:NbSheEEYHJ7i3ixzK3sjbqSGDJWnxyFXZblF3eUsNvo=
 google.golang.org/grpc v1.25.1 h1:wdKvqQk7IttEw92GoRyKG2IDrUIpgpj6H6m81yfeMW0=
@ -335,6 +415,7 @@ gopkg.in/inf.v0 v0.9.1/go.mod h1:cWUDdTG/fYaXco+Dcufb5Vnc6Gp2YChqWtbxRZE0mXw=
 gopkg.in/tomb.v1 v1.0.0-20141024135613-dd632973f1e7/go.mod h1:dt/ZhP58zS4L8KSrWDmTeBkI65Dw0HsyUHuEVlX15mw=
 gopkg.in/yaml.v2 v2.2.1/go.mod h1:hI93XBmqTisBFMUTm0b8Fm+jr3Dg1NNxqwp+5A1VGuI=
 gopkg.in/yaml.v2 v2.2.2/go.mod h1:hI93XBmqTisBFMUTm0b8Fm+jr3Dg1NNxqwp+5A1VGuI=
 gopkg.in/yaml.v2 v2.2.3/go.mod h1:hI93XBmqTisBFMUTm0b8Fm+jr3Dg1NNxqwp+5A1VGuI=
 gopkg.in/yaml.v2 v2.2.4/go.mod h1:hI93XBmqTisBFMUTm0b8Fm+jr3Dg1NNxqwp+5A1VGuI=
 gopkg.in/yaml.v2 v2.2.5/go.mod h1:hI93XBmqTisBFMUTm0b8Fm+jr3Dg1NNxqwp+5A1VGuI=
 gopkg.in/yaml.v2 v2.2.8 h1:obN1ZagJSUGI0Ek/LBmuj4SNLPfIny3KsKFopxRdj10=
@ -363,4 +444,5 @@ k8s.io/utils v0.0.0-20210305010621-2afb4311ab10/go.mod h1:jPW/WVKK9YHAvNhRxK0md/
 rsc.io/binaryregexp v0.2.0/go.mod h1:qTv7/COck+e2FymRvadv62gMdZztPaShugOCi3I+8D8=
 sigs.k8s.io/structured-merge-diff/v4 v4.0.1/go.mod h1:bJZC9H9iH24zzfZ/41RGcq60oK1F7G282QMXDPYydCw=
 sigs.k8s.io/yaml v1.1.0/go.mod h1:UJmg0vDUVViEyp3mgSv9WPwZCDxu4rQW1olrI1uml+o=
 sigs.k8s.io/yaml v1.2.0 h1:kr/MCeFWJWTwyaHoR9c8EjH9OumOmoF9YGiZd7lFm/Q=
 sigs.k8s.io/yaml v1.2.0/go.mod h1:yfXDCHCao9+ENCvLSE62v9VSji2MKu5jeNfTrofGhJc=
--- a/csi/src/config.go
+++ b/csi/src/config.go
@ -5,7 +5,7 @@ package vitastor
 const (
    vitastorCSIDriverName    = "csi.vitastor.io"
-    vitastorCSIDriverVersion = "1.4.4"
+    vitastorCSIDriverVersion = "0.8.3"
 )
 // Config struct fills the parameters of request or user input
--- a/csi/src/controllerserver.go
+++ b/csi/src/controllerserver.go
@ -6,11 +6,11 @@ package vitastor
 import (
    "context"
    "encoding/json"
    "fmt"
    "strings"
    "bytes"
    "strconv"
    "time"
    "fmt"
    "os"
    "os/exec"
    "io/ioutil"
@ -20,7 +20,8 @@ import (
    "google.golang.org/grpc/codes"
    "google.golang.org/grpc/status"
-    "google.golang.org/protobuf/types/known/timestamppb"
+
    "go.etcd.io/etcd/clientv3"
    "github.com/container-storage-interface/spec/lib/go/csi"
 )
@ -46,7 +47,6 @@ type InodeConfig struct
    ParentPool uint64 `json:"parent_pool,omitempty"`
    ParentId uint64 `json:"parent_id,omitempty"`
    Readonly bool `json:"readonly,omitempty"`
    CreateTs uint64 `json:"create_ts,omitempty"`
 }
 type ControllerServer struct
@ -62,7 +62,7 @@ func NewControllerServer(driver *Driver) *ControllerServer
    }
 }
-func GetConnectionParams(params map[string]string) (map[string]string, error)
+func GetConnectionParams(params map[string]string) (map[string]string, []string, string)
 {
    ctxVars := make(map[string]string)
    configPath := params["configPath"]
@ -75,69 +75,43 @@ func GetConnectionParams(params map[string]string) (map[string]string, error)
        ctxVars["configPath"] = configPath
    }
    config := make(map[string]interface{})
-    configFD, err := os.Open(configPath)
+    if configFD, err := os.Open(configPath); err == nil
    if (err != nil)
    {
        return nil, err
    }
        defer configFD.Close()
        data, _ := ioutil.ReadAll(configFD)
        json.Unmarshal(data, &config)
-    // Check etcd URL in the config, but do not use the explicit etcdUrl
+    }
-    // parameter for CLI calls, otherwise users won't be able to later
+    // Try to load prefix & etcd URL from the config
    // change them - storage class parameters are saved in volume IDs
    var etcdUrl []string
-    switch config["etcd_address"].(type)
+    if (params["etcdUrl"] != "")
    {
-    case string:
+        ctxVars["etcdUrl"] = params["etcdUrl"]
-        url := strings.TrimSpace(config["etcd_address"].(string))
+        etcdUrl = strings.Split(params["etcdUrl"], ",")
        if (url != "")
        {
            etcdUrl = strings.Split(url, ",")
        }
    case []string:
        etcdUrl = config["etcd_address"].([]string)
    case []interface{}:
        for _, url := range config["etcd_address"].([]interface{})
        {
            s, ok := url.(string)
            if (ok)
            {
                etcdUrl = append(etcdUrl, s)
            }
        }
    }
    if (len(etcdUrl) == 0)
    {
-        return nil, status.Error(codes.InvalidArgument, "etcd_address is missing in "+configPath)
+        switch config["etcd_address"].(type)
    }
    return ctxVars, nil
 }
 func system(program string, args ...string) ([]byte, []byte, error)
        {
-    klog.Infof("Running "+program+" "+strings.Join(args, " "))
+        case string:
-    c := exec.Command(program, args...)
+            etcdUrl = strings.Split(config["etcd_address"].(string), ",")
-    var stdout, stderr bytes.Buffer
+        case []string:
-    c.Stdout, c.Stderr = &stdout, &stderr
+            etcdUrl = config["etcd_address"].([]string)
    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
    }
-
+    etcdPrefix := params["etcdPrefix"]
-func invokeCLI(ctxVars map[string]string, args []string) ([]byte, error)
+    if (etcdPrefix == "")
    {
-    if (ctxVars["configPath"] != "")
+        etcdPrefix, _ = config["etcd_prefix"].(string)
        if (etcdPrefix == "")
        {
-        args = append(args, "--config_path", ctxVars["configPath"])
+            etcdPrefix = "/vitastor"
        }
-    stdout, _, err := system("/usr/bin/vitastor-cli", args...)
+    }
-    return stdout, err
+    else
    {
        ctxVars["etcdPrefix"] = etcdPrefix
    }
    return ctxVars, etcdUrl, etcdPrefix
 }
 // Create the volume
@ -172,57 +146,128 @@ func (cs *ControllerServer) CreateVolume(ctx context.Context, req *csi.CreateVol
        volSize = ((capRange.GetRequiredBytes() + MB - 1) / MB) * MB
    }
-    ctxVars, err := GetConnectionParams(req.Parameters)
+    // FIXME: The following should PROBABLY be implemented externally in a management tool
-    if (err != nil)
+
    ctxVars, etcdUrl, etcdPrefix := GetConnectionParams(req.Parameters)
    if (len(etcdUrl) == 0)
    {
-        return nil, err
+        return nil, status.Error(codes.InvalidArgument, "no etcdUrl in storage class configuration and no etcd_address in vitastor.conf")
    }
-    args := []string{ "create", volName, "-s", fmt.Sprintf("%v", volSize), "--pool", fmt.Sprintf("%v", poolId) }
+    // Connect to etcd
    cli, err := clientv3.New(clientv3.Config{
        DialTimeout: ETCD_TIMEOUT,
        Endpoints: etcdUrl,
    })
    if (err != nil)
    {
        return nil, status.Error(codes.Internal, "failed to connect to etcd at "+strings.Join(etcdUrl, ",")+": "+err.Error())
    }
    defer cli.Close()
-    // Support creation from snapshot
+    var imageId uint64 = 0
-    var src *csi.VolumeContentSource
+    for
    if (req.VolumeContentSource.GetSnapshot() != nil)
    {
-        snapId := req.VolumeContentSource.GetSnapshot().GetSnapshotId()
+        // Check if the image exists
-        if (snapId != "")
+        ctx, cancel := context.WithTimeout(context.Background(), ETCD_TIMEOUT)
-        {
+        resp, err := cli.Get(ctx, etcdPrefix+"/index/image/"+volName)
-            snapVars := make(map[string]string)
+        cancel()
            err := json.Unmarshal([]byte(snapId), &snapVars)
        if (err != nil)
        {
-                return nil, status.Error(codes.Internal, "volume ID not in JSON format")
+            return nil, status.Error(codes.Internal, "failed to read key from etcd: "+err.Error())
        }
-            args = append(args, "--parent", snapVars["name"]+"@"+snapVars["snapshot"])
+        if (len(resp.Kvs) > 0)
-            src = &csi.VolumeContentSource{
+        {
-                Type: &csi.VolumeContentSource_Snapshot{
+            kv := resp.Kvs[0]
-                    Snapshot: &csi.VolumeContentSource_SnapshotSource{
+            var v InodeIndex
-                        SnapshotId: snapId,
+            err := json.Unmarshal(kv.Value, &v)
                    },
                },
            }
        }
    }
    // Create image using vitastor-cli
    _, err = invokeCLI(ctxVars, args)
            if (err != nil)
            {
-        if (strings.Index(err.Error(), "already exists") > 0)
+                return nil, status.Error(codes.Internal, "invalid /index/image/"+volName+" key in etcd: "+err.Error())
-        {
+            }
-            inodeCfg, err := invokeList(ctxVars, volName, true)
+            poolId = v.PoolId
            imageId = v.Id
            inodeCfgKey := fmt.Sprintf("/config/inode/%d/%d", poolId, imageId)
            ctx, cancel := context.WithTimeout(context.Background(), ETCD_TIMEOUT)
            resp, err := cli.Get(ctx, etcdPrefix+inodeCfgKey)
            cancel()
            if (err != nil)
            {
-                return nil, err
+                return nil, status.Error(codes.Internal, "failed to read key from etcd: "+err.Error())
            }
-            if (inodeCfg[0].Size < uint64(volSize))
+            if (len(resp.Kvs) == 0)
            {
                return nil, status.Error(codes.Internal, "missing "+inodeCfgKey+" key in etcd")
            }
            var inodeCfg InodeConfig
            err = json.Unmarshal(resp.Kvs[0].Value, &inodeCfg)
            if (err != nil)
            {
                return nil, status.Error(codes.Internal, "invalid "+inodeCfgKey+" key in etcd: "+err.Error())
            }
            if (inodeCfg.Size < uint64(volSize))
            {
                return nil, status.Error(codes.Internal, "image "+volName+" is already created, but size is less than expected")
            }
        }
        else
        {
-            return nil, err
+            // Find a free ID
            // Create image metadata in a transaction verifying that the image doesn't exist yet AND ID is still free
            maxIdKey := fmt.Sprintf("%s/index/maxid/%d", etcdPrefix, poolId)
            ctx, cancel := context.WithTimeout(context.Background(), ETCD_TIMEOUT)
            resp, err := cli.Get(ctx, maxIdKey)
            cancel()
            if (err != nil)
            {
                return nil, status.Error(codes.Internal, "failed to read key from etcd: "+err.Error())
            }
            var modRev int64
            var nextId uint64
            if (len(resp.Kvs) > 0)
            {
                var err error
                nextId, err = strconv.ParseUint(string(resp.Kvs[0].Value), 10, 64)
                if (err != nil)
                {
                    return nil, status.Error(codes.Internal, maxIdKey+" contains invalid ID")
                }
                modRev = resp.Kvs[0].ModRevision
                nextId++
            }
            else
            {
                nextId = 1
            }
            inodeIdxJson, _ := json.Marshal(InodeIndex{
                Id: nextId,
                PoolId: poolId,
            })
            inodeCfgJson, _ := json.Marshal(InodeConfig{
                Name: volName,
                Size: uint64(volSize),
            })
            ctx, cancel = context.WithTimeout(context.Background(), ETCD_TIMEOUT)
            txnResp, err := cli.Txn(ctx).If(
                clientv3.Compare(clientv3.ModRevision(fmt.Sprintf("%s/index/maxid/%d", etcdPrefix, poolId)), "=", modRev),
                clientv3.Compare(clientv3.CreateRevision(fmt.Sprintf("%s/index/image/%s", etcdPrefix, volName)), "=", 0),
                clientv3.Compare(clientv3.CreateRevision(fmt.Sprintf("%s/config/inode/%d/%d", etcdPrefix, poolId, nextId)), "=", 0),
            ).Then(
                clientv3.OpPut(fmt.Sprintf("%s/index/maxid/%d", etcdPrefix, poolId), fmt.Sprintf("%d", nextId)),
                clientv3.OpPut(fmt.Sprintf("%s/index/image/%s", etcdPrefix, volName), string(inodeIdxJson)),
                clientv3.OpPut(fmt.Sprintf("%s/config/inode/%d/%d", etcdPrefix, poolId, nextId), string(inodeCfgJson)),
            ).Commit()
            cancel()
            if (err != nil)
            {
                return nil, status.Error(codes.Internal, "failed to commit transaction in etcd: "+err.Error())
            }
            if (txnResp.Succeeded)
            {
                imageId = nextId
                break
            }
            // Start over if the transaction fails
        }
    }
@ -233,7 +278,6 @@ func (cs *ControllerServer) CreateVolume(ctx context.Context, req *csi.CreateVol
            // Ugly, but VolumeContext isn't passed to DeleteVolume :-(
            VolumeId: string(volumeIdJson),
            CapacityBytes: volSize,
            ContentSource: src,
        },
    }, nil
 }
@ -247,24 +291,105 @@ func (cs *ControllerServer) DeleteVolume(ctx context.Context, req *csi.DeleteVol
        return nil, status.Error(codes.InvalidArgument, "request cannot be empty")
    }
-    volVars := make(map[string]string)
+    ctxVars := make(map[string]string)
-    err := json.Unmarshal([]byte(req.VolumeId), &volVars)
+    err := json.Unmarshal([]byte(req.VolumeId), &ctxVars)
    if (err != nil)
    {
        return nil, status.Error(codes.Internal, "volume ID not in JSON format")
    }
-    volName := volVars["name"]
+    volName := ctxVars["name"]
-    ctxVars, err := GetConnectionParams(volVars)
+    _, etcdUrl, etcdPrefix := GetConnectionParams(ctxVars)
-    if (err != nil)
+    if (len(etcdUrl) == 0)
    {
-        return nil, err
+        return nil, status.Error(codes.InvalidArgument, "no etcdUrl in storage class configuration and no etcd_address in vitastor.conf")
    }
-    _, err = invokeCLI(ctxVars, []string{ "rm", volName })
+    cli, err := clientv3.New(clientv3.Config{
        DialTimeout: ETCD_TIMEOUT,
        Endpoints: etcdUrl,
    })
    if (err != nil)
    {
-        return nil, err
+        return nil, status.Error(codes.Internal, "failed to connect to etcd at "+strings.Join(etcdUrl, ",")+": "+err.Error())
    }
    defer cli.Close()
    // Find inode by name
    ctx, cancel := context.WithTimeout(context.Background(), ETCD_TIMEOUT)
    resp, err := cli.Get(ctx, etcdPrefix+"/index/image/"+volName)
    cancel()
    if (err != nil)
    {
        return nil, status.Error(codes.Internal, "failed to read key from etcd: "+err.Error())
    }
    if (len(resp.Kvs) == 0)
    {
        return nil, status.Error(codes.NotFound, "volume "+volName+" does not exist")
    }
    var idx InodeIndex
    err = json.Unmarshal(resp.Kvs[0].Value, &idx)
    if (err != nil)
    {
        return nil, status.Error(codes.Internal, "invalid /index/image/"+volName+" key in etcd: "+err.Error())
    }
    // Get inode config
    inodeCfgKey := fmt.Sprintf("%s/config/inode/%d/%d", etcdPrefix, idx.PoolId, idx.Id)
    ctx, cancel = context.WithTimeout(context.Background(), ETCD_TIMEOUT)
    resp, err = cli.Get(ctx, inodeCfgKey)
    cancel()
    if (err != nil)
    {
        return nil, status.Error(codes.Internal, "failed to read key from etcd: "+err.Error())
    }
    if (len(resp.Kvs) == 0)
    {
        return nil, status.Error(codes.NotFound, "volume "+volName+" does not exist")
    }
    var inodeCfg InodeConfig
    err = json.Unmarshal(resp.Kvs[0].Value, &inodeCfg)
    if (err != nil)
    {
        return nil, status.Error(codes.Internal, "invalid "+inodeCfgKey+" key in etcd: "+err.Error())
    }
    // Delete inode data by invoking vitastor-cli
    args := []string{
        "rm-data", "--etcd_address", strings.Join(etcdUrl, ","),
        "--pool", fmt.Sprintf("%d", idx.PoolId),
        "--inode", fmt.Sprintf("%d", idx.Id),
    }
    if (ctxVars["configPath"] != "")
    {
        args = append(args, "--config_path", ctxVars["configPath"])
    }
    c := exec.Command("/usr/bin/vitastor-cli", args...)
    var stderr bytes.Buffer
    c.Stdout = nil
    c.Stderr = &stderr
    err = c.Run()
    stderrStr := string(stderr.Bytes())
    if (err != nil)
    {
        klog.Errorf("vitastor-cli rm-data failed: %s, status %s\n", stderrStr, err)
        return nil, status.Error(codes.Internal, stderrStr+" (status "+err.Error()+")")
    }
    // Delete inode config in etcd
    ctx, cancel = context.WithTimeout(context.Background(), ETCD_TIMEOUT)
    txnResp, err := cli.Txn(ctx).Then(
        clientv3.OpDelete(fmt.Sprintf("%s/index/image/%s", etcdPrefix, volName)),
        clientv3.OpDelete(fmt.Sprintf("%s/config/inode/%d/%d", etcdPrefix, idx.PoolId, idx.Id)),
    ).Commit()
    cancel()
    if (err != nil)
    {
        return nil, status.Error(codes.Internal, "failed to delete keys in etcd: "+err.Error())
    }
    if (!txnResp.Succeeded)
    {
        return nil, status.Error(codes.Internal, "failed to delete keys in etcd: transaction failed")
    }
    return &csi.DeleteVolumeResponse{}, nil
@ -365,8 +490,6 @@ func (cs *ControllerServer) ControllerGetCapabilities(ctx context.Context, req *
        csi.ControllerServiceCapability_RPC_LIST_VOLUMES,
        csi.ControllerServiceCapability_RPC_EXPAND_VOLUME,
        csi.ControllerServiceCapability_RPC_CREATE_DELETE_SNAPSHOT,
        csi.ControllerServiceCapability_RPC_LIST_SNAPSHOTS,
        // TODO: csi.ControllerServiceCapability_RPC_CLONE_VOLUME,
    } {
        controllerServerCapabilities = append(controllerServerCapabilities, functionControllerServerCapabilities(capability))
    }
@ -376,226 +499,28 @@ func (cs *ControllerServer) ControllerGetCapabilities(ctx context.Context, req *
    }, nil
 }
 func invokeList(ctxVars map[string]string, pattern string, expectExist bool) ([]InodeConfig, error)
 {
    stat, err := invokeCLI(ctxVars, []string{ "ls", "--json", pattern })
    if (err != nil)
    {
        return nil, err
    }
    var inodeCfg []InodeConfig
    err = json.Unmarshal(stat, &inodeCfg)
    if (err != nil)
    {
        return nil, status.Error(codes.Internal, "Invalid JSON in vitastor-cli ls: "+err.Error())
    }
    if (expectExist && len(inodeCfg) == 0)
    {
        return nil, status.Error(codes.Internal, "Can't find expected image "+pattern+" via vitastor-cli ls")
    }
    return inodeCfg, nil
 }
 // CreateSnapshot create snapshot of an existing PV
 func (cs *ControllerServer) CreateSnapshot(ctx context.Context, req *csi.CreateSnapshotRequest) (*csi.CreateSnapshotResponse, error)
 {
-    klog.Infof("received controller create snapshot request %+v", protosanitizer.StripSecrets(req))
+    return nil, status.Error(codes.Unimplemented, "")
    if (req == nil)
    {
        return nil, status.Errorf(codes.InvalidArgument, "request cannot be empty")
    }
    if (req.SourceVolumeId == "" || req.Name == "")
    {
        return nil, status.Error(codes.InvalidArgument, "source volume ID and snapshot name are required fields")
    }
    // snapshot name
    snapName := req.Name
    // req.VolumeId is an ugly json string in our case :)
    ctxVars := make(map[string]string)
    err := json.Unmarshal([]byte(req.SourceVolumeId), &ctxVars)
    if (err != nil)
    {
        return nil, status.Error(codes.Internal, "volume ID not in JSON format")
    }
    volName := ctxVars["name"]
    // Create image using vitastor-cli
    _, err = invokeCLI(ctxVars, []string{ "create", "--snapshot", snapName, volName })
    if (err != nil && strings.Index(err.Error(), "already exists") <= 0)
    {
        return nil, err
    }
    // Check created snapshot
    inodeCfg, err := invokeList(ctxVars, volName+"@"+snapName, true)
    if (err != nil)
    {
        return nil, err
    }
    // Use ugly JSON snapshot ID again, DeleteSnapshot doesn't have context :-(
    ctxVars["snapshot"] = snapName
    snapIdJson, _ := json.Marshal(ctxVars)
    return &csi.CreateSnapshotResponse{
        Snapshot: &csi.Snapshot{
            SizeBytes: int64(inodeCfg[0].Size),
            SnapshotId: string(snapIdJson),
            SourceVolumeId: req.SourceVolumeId,
            CreationTime: &timestamppb.Timestamp{ Seconds: int64(inodeCfg[0].CreateTs) },
            ReadyToUse: true,
        },
    }, nil
 }
 // DeleteSnapshot delete provided snapshot of a PV
 func (cs *ControllerServer) DeleteSnapshot(ctx context.Context, req *csi.DeleteSnapshotRequest) (*csi.DeleteSnapshotResponse, error)
 {
-    klog.Infof("received controller delete snapshot request %+v", protosanitizer.StripSecrets(req))
+    return nil, status.Error(codes.Unimplemented, "")
    if (req == nil)
    {
        return nil, status.Errorf(codes.InvalidArgument, "request cannot be empty")
    }
    if (req.SnapshotId == "")
    {
        return nil, status.Error(codes.InvalidArgument, "snapshot ID is a required field")
    }
    volVars := make(map[string]string)
    err := json.Unmarshal([]byte(req.SnapshotId), &volVars)
    if (err != nil)
    {
        return nil, status.Error(codes.Internal, "snapshot ID not in JSON format")
    }
    volName := volVars["name"]
    snapName := volVars["snapshot"]
    ctxVars, err := GetConnectionParams(volVars)
    if (err != nil)
    {
        return nil, err
    }
    _, err = invokeCLI(ctxVars, []string{ "rm", volName+"@"+snapName })
    if (err != nil)
    {
        return nil, err
    }
    return &csi.DeleteSnapshotResponse{}, nil
 }
 // ListSnapshots list the snapshots of a PV
 func (cs *ControllerServer) ListSnapshots(ctx context.Context, req *csi.ListSnapshotsRequest) (*csi.ListSnapshotsResponse, error)
 {
-    klog.Infof("received controller list snapshots request %+v", protosanitizer.StripSecrets(req))
+    return nil, status.Error(codes.Unimplemented, "")
    if (req == nil)
    {
        return nil, status.Error(codes.InvalidArgument, "request cannot be empty")
 }
-    volVars := make(map[string]string)
+// ControllerExpandVolume resizes a volume
    err := json.Unmarshal([]byte(req.SourceVolumeId), &volVars)
    if (err != nil)
    {
        return nil, status.Error(codes.Internal, "volume ID not in JSON format")
    }
    volName := volVars["name"]
    ctxVars, err := GetConnectionParams(volVars)
    if (err != nil)
    {
        return nil, err
    }
    inodeCfg, err := invokeList(ctxVars, volName+"@*", false)
    if (err != nil)
    {
        return nil, err
    }
    resp := &csi.ListSnapshotsResponse{}
    for _, ino := range inodeCfg
    {
        snapName := ino.Name[len(volName)+1:]
        if (len(req.StartingToken) > 0 && snapName < req.StartingToken)
        {
        }
        else if (req.MaxEntries == 0 || len(resp.Entries) < int(req.MaxEntries))
        {
            volVars["snapshot"] = snapName
            snapIdJson, _ := json.Marshal(volVars)
            resp.Entries = append(resp.Entries, &csi.ListSnapshotsResponse_Entry{
                Snapshot: &csi.Snapshot{
                    SizeBytes: int64(ino.Size),
                    SnapshotId: string(snapIdJson),
                    SourceVolumeId: req.SourceVolumeId,
                    CreationTime: &timestamppb.Timestamp{ Seconds: int64(ino.CreateTs) },
                    ReadyToUse: true,
                },
            })
        }
        else
        {
            resp.NextToken = snapName
            break
        }
    }
    return resp, nil
 }
 // ControllerExpandVolume increases the size of a volume
 func (cs *ControllerServer) ControllerExpandVolume(ctx context.Context, req *csi.ControllerExpandVolumeRequest) (*csi.ControllerExpandVolumeResponse, error)
 {
-    klog.Infof("received controller expand volume request %+v", protosanitizer.StripSecrets(req))
+    return nil, status.Error(codes.Unimplemented, "")
    if (req == nil)
    {
        return nil, status.Error(codes.InvalidArgument, "request cannot be empty")
    }
    if (req.VolumeId == "" || req.CapacityRange == nil || req.CapacityRange.RequiredBytes == 0)
    {
        return nil, status.Error(codes.InvalidArgument, "VolumeId, CapacityRange and RequiredBytes are required fields")
    }
    volVars := make(map[string]string)
    err := json.Unmarshal([]byte(req.VolumeId), &volVars)
    if (err != nil)
    {
        return nil, status.Error(codes.Internal, "volume ID not in JSON format")
    }
    volName := volVars["name"]
    ctxVars, err := GetConnectionParams(volVars)
    if (err != nil)
    {
        return nil, err
    }
    inodeCfg, err := invokeList(ctxVars, volName, true)
    if (err != nil)
    {
        return nil, err
    }
    if (req.CapacityRange.RequiredBytes > 0 && inodeCfg[0].Size < uint64(req.CapacityRange.RequiredBytes))
    {
        sz := ((req.CapacityRange.RequiredBytes+4095)/4096)*4096
        _, err := invokeCLI(ctxVars, []string{ "modify", "--inc_size", "1", "--resize", fmt.Sprintf("%d", sz), volName })
        if (err != nil)
        {
            return nil, err
        }
        inodeCfg, err = invokeList(ctxVars, volName, true)
        if (err != nil)
        {
            return nil, err
        }
    }
    return &csi.ControllerExpandVolumeResponse{
        CapacityBytes: int64(inodeCfg[0].Size),
        NodeExpansionRequired: false,
    }, nil
 }
 // ControllerGetVolume get volume info
--- a/csi/src/identityserver.go
+++ b/csi/src/identityserver.go
@ -49,13 +49,6 @@ func (is *IdentityServer) GetPluginCapabilities(ctx context.Context, req *csi.Ge
                    },
                },
            },
            {
                Type: &csi.PluginCapability_VolumeExpansion_{
                    VolumeExpansion: &csi.PluginCapability_VolumeExpansion{
                        Type: csi.PluginCapability_VolumeExpansion_OFFLINE,
                    },
                },
            },
        },
    }, nil
 }
--- a/csi/src/nodeserver.go
+++ b/csi/src/nodeserver.go
@ -5,16 +5,11 @@ package vitastor
 import (
    "context"
    "errors"
    "encoding/json"
    "fmt"
    "os"
    "os/exec"
-    "path/filepath"
+    "encoding/json"
    "strconv"
    "strings"
-    "syscall"
+    "bytes"
    "time"
    "google.golang.org/grpc/codes"
    "google.golang.org/grpc/status"
@ -30,102 +25,16 @@ import (
 type NodeServer struct
 {
    *Driver
    useVduse bool
    stateDir string
    mounter mount.Interface
    restartInterval time.Duration
 }
 type DeviceState struct
 {
    ConfigPath string `json:"configPath"`
    VdpaId     string `json:"vdpaId"`
    Image      string `json:"image"`
    Blockdev   string `json:"blockdev"`
    Readonly   bool   `json:"readonly"`
    PidFile    string `json:"pidFile"`
 }
 // NewNodeServer create new instance node
 func NewNodeServer(driver *Driver) *NodeServer
 {
-    stateDir := os.Getenv("STATE_DIR")
+    return &NodeServer{
    if (stateDir == "")
    {
        stateDir = "/run/vitastor-csi"
    }
    if (stateDir[len(stateDir)-1] != '/')
    {
        stateDir += "/"
    }
    ns := &NodeServer{
        Driver: driver,
        useVduse: checkVduseSupport(),
        stateDir: stateDir,
        mounter: mount.New(""),
    }
    if (ns.useVduse)
    {
        ns.restoreVduseDaemons()
        dur, err := time.ParseDuration(os.Getenv("RESTART_INTERVAL"))
        if (err != nil)
        {
            dur = 10 * time.Second
        }
        ns.restartInterval = dur
        if (ns.restartInterval != time.Duration(0))
        {
            go ns.restarter()
        }
    }
    return ns
 }
 func checkVduseSupport() bool
 {
    // Check VDUSE support (vdpa, vduse, virtio-vdpa kernel modules)
    vduse := true
    for _, mod := range []string{"vdpa", "vduse", "virtio-vdpa"}
    {
        _, err := os.Stat("/sys/module/"+mod)
        if (err != nil)
        {
            if (!errors.Is(err, os.ErrNotExist))
            {
                klog.Errorf("failed to check /sys/module/%s: %v", mod, err)
            }
            c := exec.Command("/sbin/modprobe", mod)
            c.Stdout = os.Stderr
            c.Stderr = os.Stderr
            err := c.Run()
            if (err != nil)
            {
                klog.Errorf("/sbin/modprobe %s failed: %v", mod, err)
                vduse = false
                break
            }
        }
    }
    // Check that vdpa tool functions
    if (vduse)
    {
        c := exec.Command("/sbin/vdpa", "-j", "dev")
        c.Stderr = os.Stderr
        err := c.Run()
        if (err != nil)
        {
            klog.Errorf("/sbin/vdpa -j dev failed: %v", err)
            vduse = false
        }
    }
    if (!vduse)
    {
        klog.Errorf(
            "Your host apparently has no VDUSE support. VDUSE support disabled, NBD will be used to map devices."+
            " For VDUSE you need at least Linux 5.15 and the following kernel modules: vdpa, virtio-vdpa, vduse.",
        )
    }
    return vduse
 }
 // NodeStageVolume mounts the volume to a staging path on the node.
@ -152,318 +61,6 @@ func Contains(list []string, s string) bool
    return false
 }
 func (ns *NodeServer) mapNbd(volName string, ctxVars map[string]string, readonly bool) (string, error)
 {
    // Map NBD device
    // FIXME: Check if already mapped
    args := []string{
        "map", "--image", volName,
    }
    if (ctxVars["configPath"] != "")
    {
        args = append(args, "--config_path", ctxVars["configPath"])
    }
    if (readonly)
    {
        args = append(args, "--readonly", "1")
    }
    stdout, stderr, err := system("/usr/bin/vitastor-nbd", args...)
    dev := strings.TrimSpace(string(stdout))
    if (dev == "")
    {
        return "", fmt.Errorf("vitastor-nbd did not return the name of NBD device. output: %s", stderr)
    }
    return dev, err
 }
 func (ns *NodeServer) unmapNbd(devicePath string)
 {
    // unmap NBD device
    unmapOut, unmapErr := exec.Command("/usr/bin/vitastor-nbd", "unmap", devicePath).CombinedOutput()
    if (unmapErr != nil)
    {
        klog.Errorf("failed to unmap NBD device %s: %s, error: %v", devicePath, unmapOut, unmapErr)
    }
 }
 func findByPidFile(pidFile string) (*os.Process, error)
 {
    pidBuf, err := os.ReadFile(pidFile)
    if (err != nil)
    {
        return nil, err
    }
    pid, err := strconv.ParseInt(strings.TrimSpace(string(pidBuf)), 0, 64)
    if (err != nil)
    {
        return nil, err
    }
    proc, err := os.FindProcess(int(pid))
    if (err != nil)
    {
        return nil, err
    }
    return proc, nil
 }
 func killByPidFile(pidFile string) error
 {
    klog.Infof("killing process with PID from file %s", pidFile)
    proc, err := findByPidFile(pidFile)
    if (err != nil)
    {
        return err
    }
    return proc.Signal(syscall.SIGTERM)
 }
 func startStorageDaemon(vdpaId, volName, pidFile, configPath string, readonly bool) error
 {
    // Start qemu-storage-daemon
    blockSpec := map[string]interface{}{
        "node-name": "disk1",
        "driver": "vitastor",
        "image": volName,
        "cache": map[string]bool{
            "direct": true,
            "no-flush": false,
        },
        "discard": "unmap",
    }
    if (configPath != "")
    {
        blockSpec["config-path"] = configPath
    }
    blockSpecJson, _ := json.Marshal(blockSpec)
    writable := "true"
    if (readonly)
    {
        writable = "false"
    }
    _, _, err := system(
        "/usr/bin/qemu-storage-daemon", "--daemonize", "--pidfile", pidFile, "--blockdev", string(blockSpecJson),
        "--export", "vduse-blk,id="+vdpaId+",node-name=disk1,name="+vdpaId+",num-queues=16,queue-size=128,writable="+writable,
    )
    return err
 }
 func (ns *NodeServer) mapVduse(volName string, ctxVars map[string]string, readonly bool) (string, string, error)
 {
    // Generate state file
    stateFd, err := os.CreateTemp(ns.stateDir, "vitastor-vduse-*.json")
    if (err != nil)
    {
        return "", "", err
    }
    stateFile := stateFd.Name()
    stateFd.Close()
    vdpaId := filepath.Base(stateFile)
    vdpaId = vdpaId[0:len(vdpaId)-5] // remove ".json"
    pidFile := ns.stateDir + vdpaId + ".pid"
    // Map VDUSE device via qemu-storage-daemon
    err = startStorageDaemon(vdpaId, volName, pidFile, ctxVars["configPath"], readonly)
    if (err == nil)
    {
        // Add device to VDPA bus
        _, _, err = system("/sbin/vdpa", "-j", "dev", "add", "name", vdpaId, "mgmtdev", "vduse")
        if (err == nil)
        {
            // Find block device name
            var matches []string
            matches, err = filepath.Glob("/sys/bus/vdpa/devices/"+vdpaId+"/virtio*/block/*")
            if (err == nil && len(matches) == 0)
            {
                err = errors.New("/sys/bus/vdpa/devices/"+vdpaId+"/virtio*/block/* is not found")
            }
            if (err == nil)
            {
                blockdev := "/dev/"+filepath.Base(matches[0])
                _, err = os.Stat(blockdev)
                if (err == nil)
                {
                    // Generate state file
                    stateJSON, _ := json.Marshal(&DeviceState{
                        ConfigPath: ctxVars["configPath"],
                        VdpaId:     vdpaId,
                        Image:      volName,
                        Blockdev:   blockdev,
                        Readonly:   readonly,
                        PidFile:    pidFile,
                    })
                    err = os.WriteFile(stateFile, stateJSON, 0600)
                    if (err == nil)
                    {
                        return blockdev, vdpaId, nil
                    }
                }
            }
        }
        killErr := killByPidFile(pidFile)
        if (killErr != nil)
        {
            klog.Errorf("Failed to kill started qemu-storage-daemon: %v", killErr)
        }
        os.Remove(stateFile)
        os.Remove(pidFile)
    }
    return "", "", err
 }
 func (ns *NodeServer) unmapVduse(devicePath string)
 {
    if (len(devicePath) < 6 || devicePath[0:6] != "/dev/v")
    {
        klog.Errorf("%s does not start with /dev/v", devicePath)
        return
    }
    vduseDev, err := os.Readlink("/sys/block/"+devicePath[5:])
    if (err != nil)
    {
        klog.Errorf("%s is not a symbolic link to VDUSE device (../devices/virtual/vduse/xxx): %v", devicePath, err)
        return
    }
    vdpaId := ""
    p := strings.Index(vduseDev, "/vduse/")
    if (p >= 0)
    {
        vduseDev = vduseDev[p+7:]
        p = strings.Index(vduseDev, "/")
        if (p >= 0)
        {
            vdpaId = vduseDev[0:p]
        }
    }
    if (vdpaId == "")
    {
        klog.Errorf("%s is not a symbolic link to VDUSE device (../devices/virtual/vduse/xxx), but is %v", devicePath, vduseDev)
        return
    }
    ns.unmapVduseById(vdpaId)
 }
 func (ns *NodeServer) unmapVduseById(vdpaId string)
 {
    _, err := os.Stat("/sys/bus/vdpa/devices/"+vdpaId)
    if (err != nil)
    {
        klog.Errorf("failed to stat /sys/bus/vdpa/devices/"+vdpaId+": %v", err)
    }
    else
    {
        _, _, _ = system("/sbin/vdpa", "-j", "dev", "del", vdpaId)
    }
    stateFile := ns.stateDir + vdpaId + ".json"
    os.Remove(stateFile)
    pidFile := ns.stateDir + vdpaId + ".pid"
    _, err = os.Stat(pidFile)
    if (os.IsNotExist(err))
    {
        // ok, already killed
    }
    else if (err != nil)
    {
        klog.Errorf("Failed to stat %v: %v", pidFile, err)
        return
    }
    else
    {
        err = killByPidFile(pidFile)
        if (err != nil)
        {
            klog.Errorf("Failed to kill started qemu-storage-daemon: %v", err)
        }
        os.Remove(pidFile)
    }
 }
 func (ns *NodeServer) restarter()
 {
    // Restart dead VDUSE daemons at regular intervals
    // Otherwise volume I/O may hang in case of a qemu-storage-daemon crash
    // Moreover, it may lead to a kernel panic of the kernel is configured to
    // panic on hung tasks
    ticker := time.NewTicker(ns.restartInterval)
    defer ticker.Stop()
    for
    {
        <-ticker.C
        ns.restoreVduseDaemons()
    }
 }
 func (ns *NodeServer) restoreVduseDaemons()
 {
    pattern := ns.stateDir+"vitastor-vduse-*.json"
    matches, err := filepath.Glob(pattern)
    if (err != nil)
    {
        klog.Errorf("failed to list %s: %v", pattern, err)
    }
    if (len(matches) == 0)
    {
        return
    }
    devList := make(map[string]interface{})
    // example output: {"dev":{"test1":{"type":"block","mgmtdev":"vduse","vendor_id":0,"max_vqs":16,"max_vq_size":128}}}
    devListJSON, _, err := system("/sbin/vdpa", "-j", "dev", "list")
    if (err != nil)
    {
        return
    }
    err = json.Unmarshal(devListJSON, &devList)
    devs, ok := devList["dev"].(map[string]interface{})
    if (err != nil || !ok)
    {
        klog.Errorf("/sbin/vdpa -j dev list returned bad JSON (error %v): %v", err, string(devListJSON))
        return
    }
    for _, stateFile := range matches
    {
        vdpaId := filepath.Base(stateFile)
        vdpaId = vdpaId[0:len(vdpaId)-5]
        // Check if VDPA device is still added to the bus
        if (devs[vdpaId] != nil)
        {
            // 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
                stateJSON, err := os.ReadFile(stateFile)
                if (err != nil)
                {
                    klog.Warningf("error reading state file %v: %v", stateFile, err)
                }
                else
                {
                    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))
                    }
                    else
                    {
                        klog.Warningf("restarting storage daemon for volume %v (VDPA ID %v)", state.Image, vdpaId)
                        _ = startStorageDaemon(vdpaId, state.Image, pidFile, state.ConfigPath, state.Readonly)
                    }
                }
            }
        }
        else
        {
            // Unused, clean it up
            ns.unmapVduseById(vdpaId)
        }
    }
 }
 // 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)
 {
@ -473,10 +70,10 @@ func (ns *NodeServer) NodePublishVolume(ctx context.Context, req *csi.NodePublis
    isBlock := req.GetVolumeCapability().GetBlock() != nil
    // Check that it's not already mounted
-    _, err := mount.IsNotMountPoint(ns.mounter, targetPath)
+    _, error := mount.IsNotMountPoint(ns.mounter, targetPath)
-    if (err != nil)
+    if (error != nil)
    {
-        if (os.IsNotExist(err))
+        if (os.IsNotExist(error))
        {
            if (isBlock)
            {
@ -484,13 +81,13 @@ func (ns *NodeServer) NodePublishVolume(ctx context.Context, req *csi.NodePublis
                if (err != nil)
                {
                    klog.Errorf("failed to create block device mount target %s with error: %v", targetPath, err)
-                    return nil, err
+                    return nil, status.Error(codes.Internal, err.Error())
                }
                err = pathFile.Close()
                if (err != nil)
                {
                    klog.Errorf("failed to close %s with error: %v", targetPath, err)
-                    return nil, err
+                    return nil, status.Error(codes.Internal, err.Error())
                }
            }
            else
@ -499,57 +96,70 @@ func (ns *NodeServer) NodePublishVolume(ctx context.Context, req *csi.NodePublis
                if (err != nil)
                {
                    klog.Errorf("failed to create fs mount target %s with error: %v", targetPath, err)
-                    return nil, err
+                    return nil, status.Error(codes.Internal, err.Error())
                }
            }
        }
        else
        {
-            return nil, err
+            return nil, status.Error(codes.Internal, error.Error())
        }
    }
    ctxVars := make(map[string]string)
-    err = json.Unmarshal([]byte(req.VolumeId), &ctxVars)
+    err := json.Unmarshal([]byte(req.VolumeId), &ctxVars)
    if (err != nil)
    {
        return nil, status.Error(codes.Internal, "volume ID not in JSON format")
    }
    volName := ctxVars["name"]
-    _, err = GetConnectionParams(ctxVars)
+    _, etcdUrl, etcdPrefix := GetConnectionParams(ctxVars)
-    if (err != nil)
+    if (len(etcdUrl) == 0)
    {
-        return nil, err
+        return nil, status.Error(codes.InvalidArgument, "no etcdUrl in storage class configuration and no etcd_address in vitastor.conf")
    }
-    var devicePath, vdpaId string
+    // Map NBD device
-    if (!ns.useVduse)
+    // FIXME: Check if already mapped
    args := []string{
        "map", "--etcd_address", strings.Join(etcdUrl, ","),
        "--etcd_prefix", etcdPrefix,
        "--image", volName,
    };
    if (ctxVars["configPath"] != "")
    {
-        devicePath, err = ns.mapNbd(volName, ctxVars, req.GetReadonly())
+        args = append(args, "--config_path", ctxVars["configPath"])
    }
-    else
+    if (req.GetReadonly())
    {
-        devicePath, vdpaId, err = ns.mapVduse(volName, ctxVars, req.GetReadonly())
+        args = append(args, "--readonly", "1")
    }
    c := exec.Command("/usr/bin/vitastor-nbd", args...)
    var stdout, stderr bytes.Buffer
    c.Stdout, c.Stderr = &stdout, &stderr
    err = c.Run()
    stdoutStr, stderrStr := string(stdout.Bytes()), string(stderr.Bytes())
    if (err != nil)
    {
-        return nil, err
+        klog.Errorf("vitastor-nbd map failed: %s, status %s\n", stdoutStr+stderrStr, err)
        return nil, status.Error(codes.Internal, stdoutStr+stderrStr+" (status "+err.Error()+")")
    }
    devicePath := strings.TrimSpace(stdoutStr)
    diskMounter := &mount.SafeFormatAndMount{Interface: ns.mounter, Exec: utilexec.New()}
    if (isBlock)
    {
        err = diskMounter.Mount(devicePath, targetPath, "", []string{"bind"})
    }
    else
    {
    // Check existing format
    diskMounter := &mount.SafeFormatAndMount{Interface: ns.mounter, Exec: utilexec.New()}
    existingFormat, err := diskMounter.GetDiskFormat(devicePath)
    if (err != nil)
    {
        klog.Errorf("failed to get disk format for path %s, error: %v", err)
-            goto unmap
+        // unmap NBD device
        unmapOut, unmapErr := exec.Command("/usr/bin/vitastor-nbd", "unmap", devicePath).CombinedOutput()
        if (unmapErr != nil)
        {
            klog.Errorf("failed to unmap NBD device %s: %s, error: %v", devicePath, unmapOut, unmapErr)
        }
        return nil, err
    }
    // Format the device (ext4 or xfs)
@ -569,42 +179,38 @@ func (ns *NodeServer) NodePublishVolume(ctx context.Context, req *csi.NodePublis
    readOnly := Contains(opt, "ro")
    if (existingFormat == "" && !readOnly)
    {
-            var cmdOut []byte
+        args := []string{}
        switch fsType
        {
            case "ext4":
-                    args := []string{"-m0", "-Enodiscard,lazy_itable_init=1,lazy_journal_init=1", devicePath}
+                args = []string{"-m0", "-Enodiscard,lazy_itable_init=1,lazy_journal_init=1", devicePath}
                    cmdOut, err = diskMounter.Exec.Command("mkfs.ext4", args...).CombinedOutput()
            case "xfs":
-                    cmdOut, err = diskMounter.Exec.Command("mkfs.xfs", "-K", devicePath).CombinedOutput()
+                args = []string{"-K", devicePath}
        }
-            if (err != nil)
+        if (len(args) > 0)
        {
-                klog.Errorf("failed to run mkfs error: %v, output: %v", err, string(cmdOut))
+            cmdOut, cmdErr := diskMounter.Exec.Command("mkfs."+fsType, args...).CombinedOutput()
-                goto unmap
+            if (cmdErr != nil)
            {
                klog.Errorf("failed to run mkfs error: %v, output: %v", cmdErr, string(cmdOut))
                // unmap NBD device
                unmapOut, unmapErr := exec.Command("/usr/bin/vitastor-nbd", "unmap", devicePath).CombinedOutput()
                if (unmapErr != nil)
                {
                    klog.Errorf("failed to unmap NBD device %s: %s, error: %v", devicePath, unmapOut, unmapErr)
                }
                return nil, status.Error(codes.Internal, cmdErr.Error())
            }
        }
-
+    }
    if (isBlock)
    {
        opt = append(opt, "bind")
        err = diskMounter.Mount(devicePath, targetPath, fsType, opt)
    }
    else
    {
        err = diskMounter.FormatAndMount(devicePath, targetPath, fsType, opt)
        // 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()
                case "xfs":
                    cmdOut, err = diskMounter.Exec.Command("xfs_growfs", devicePath).CombinedOutput()
            }
            if (err != nil)
            {
                klog.Errorf("failed to run resizefs error: %v, output: %v", err, string(cmdOut))
                goto unmap
            }
        }
    }
    if (err != nil)
    {
@ -612,20 +218,15 @@ func (ns *NodeServer) NodePublishVolume(ctx context.Context, req *csi.NodePublis
            "failed to mount device path (%s) to path (%s) for volume (%s) error: %s",
            devicePath, targetPath, volName, err,
        )
-        goto unmap
+        // unmap NBD device
        unmapOut, unmapErr := exec.Command("/usr/bin/vitastor-nbd", "unmap", devicePath).CombinedOutput()
        if (unmapErr != nil)
        {
            klog.Errorf("failed to unmap NBD device %s: %s, error: %v", devicePath, unmapOut, unmapErr)
        }
        return nil, status.Error(codes.Internal, err.Error())
    }
    return &csi.NodePublishVolumeResponse{}, nil
 unmap:
    if (!ns.useVduse || len(devicePath) >= 8 && devicePath[0:8] == "/dev/nbd")
    {
        ns.unmapNbd(devicePath)
    }
    else
    {
        ns.unmapVduseById(vdpaId)
    }
    return nil, err
 }
 // NodeUnpublishVolume unmounts the volume from the target path
@ -640,31 +241,25 @@ func (ns *NodeServer) NodeUnpublishVolume(ctx context.Context, req *csi.NodeUnpu
        {
            return nil, status.Error(codes.NotFound, "Target path not found")
        }
-        return nil, err
+        return nil, status.Error(codes.Internal, err.Error())
    }
    if (devicePath == "")
    {
-        // volume not mounted
+        return nil, status.Error(codes.NotFound, "Volume not mounted")
        klog.Warningf("%s is not a mountpoint, deleting", targetPath)
        os.Remove(targetPath)
        return &csi.NodeUnpublishVolumeResponse{}, nil
    }
    // unmount
    err = mount.CleanupMountPoint(targetPath, ns.mounter, false)
    if (err != nil)
    {
-        return nil, err
+        return nil, status.Error(codes.Internal, err.Error())
    }
    // unmap NBD device
    if (refCount == 1)
    {
-        if (!ns.useVduse)
+        unmapOut, unmapErr := exec.Command("/usr/bin/vitastor-nbd", "unmap", devicePath).CombinedOutput()
        if (unmapErr != nil)
        {
-            ns.unmapNbd(devicePath)
+            klog.Errorf("failed to unmap NBD device %s: %s, error: %v", devicePath, unmapOut, unmapErr)
        }
        else
        {
            ns.unmapVduse(devicePath)
        }
    }
    return &csi.NodeUnpublishVolumeResponse{}, nil
--- a/debian/build-pve-qemu.sh
+++ b/debian/build-pve-qemu.sh
@ -1,58 +0,0 @@
 exit
 git clone https://git.yourcmc.ru/vitalif/pve-qemu .
 # bookworm
 docker run -it -v `pwd`/pve-qemu:/root/pve-qemu --name pve-qemu-bullseye debian:bullseye bash
 perl -i -pe 's/Types: deb$/Types: deb deb-src/' /etc/apt/sources.list.d/debian.sources
 echo 'deb [arch=amd64] http://download.proxmox.com/debian/pve bookworm pve-no-subscription' >> /etc/apt/sources.list
 echo 'deb https://vitastor.io/debian bookworm main' >> /etc/apt/sources.list
 echo 'APT::Install-Recommends false;' >> /etc/apt/apt.conf
 echo 'ru_RU UTF-8' >> /etc/locale.gen
 echo 'en_US UTF-8' >> /etc/locale.gen
 apt-get update
 apt-get install wget ca-certificates
 wget https://enterprise.proxmox.com/debian/proxmox-release-bookworm.gpg -O /etc/apt/trusted.gpg.d/proxmox-release-bookworm.gpg
 wget https://vitastor.io/debian/pubkey.gpg -O /etc/apt/trusted.gpg.d/vitastor.gpg
 apt-get update
 apt-get install git devscripts equivs wget mc libjemalloc-dev vitastor-client-dev lintian locales
 mk-build-deps --install ./control
 # bullseye
 docker run -it -v `pwd`/pve-qemu:/root/pve-qemu --name pve-qemu-bullseye debian:bullseye bash
 grep '^deb ' /etc/apt/sources.list | perl -pe 's/^deb /deb-src /' >> /etc/apt/sources.list
 echo 'deb [arch=amd64] http://download.proxmox.com/debian/pve bullseye pve-no-subscription' >> /etc/apt/sources.list
 echo 'deb https://vitastor.io/debian bullseye main' >> /etc/apt/sources.list
 echo 'APT::Install-Recommends false;' >> /etc/apt/apt.conf
 echo 'ru_RU UTF-8' >> /etc/locale.gen
 echo 'en_US UTF-8' >> /etc/locale.gen
 apt-get update
 apt-get install wget
 wget https://enterprise.proxmox.com/debian/proxmox-release-bullseye.gpg -O /etc/apt/trusted.gpg.d/proxmox-release-bullseye.gpg
 wget https://vitastor.io/debian/pubkey.gpg -O /etc/apt/trusted.gpg.d/vitastor.gpg
 apt-get update
 apt-get install git devscripts equivs wget mc libjemalloc-dev vitastor-client-dev lintian locales
 mk-build-deps --install ./control
 # buster
 docker run -it -v `pwd`/pve-qemu:/root/pve-qemu --name pve-qemu-buster debian:buster bash
 grep '^deb ' /etc/apt/sources.list | perl -pe 's/^deb /deb-src /' >> /etc/apt/sources.list
 echo 'deb [arch=amd64] http://download.proxmox.com/debian/pve buster pve-no-subscription' >> /etc/apt/sources.list
 echo 'deb https://vitastor.io/debian buster main' >> /etc/apt/sources.list
 echo 'deb http://deb.debian.org/debian buster-backports main' >> /etc/apt/sources.list
 echo 'APT::Install-Recommends false;' >> /etc/apt/apt.conf
 echo 'ru_RU UTF-8' >> /etc/locale.gen
 echo 'en_US UTF-8' >> /etc/locale.gen
 apt-get update
 apt-get install wget ca-certificates
 wget http://download.proxmox.com/debian/proxmox-ve-release-6.x.gpg -O /etc/apt/trusted.gpg.d/proxmox-ve-release-6.x.gpg
 wget https://vitastor.io/debian/pubkey.gpg -O /etc/apt/trusted.gpg.d/vitastor.gpg
 apt-get update
 apt-get install git devscripts equivs wget mc libjemalloc-dev vitastor-client-dev lintian locales
 mk-build-deps --install ./control
--- a/debian/build-vitastor-bookworm.sh
+++ b/debian/build-vitastor-bookworm.sh
@ -1,7 +0,0 @@
 #!/bin/bash
 cat < vitastor.Dockerfile > ../Dockerfile
 cd ..
 mkdir -p packages
 sudo podman build --build-arg REL=bookworm -v `pwd`/packages:/root/packages -f Dockerfile .
 rm Dockerfile
--- a/debian/changelog
+++ b/debian/changelog
@ -1,10 +1,10 @@
-vitastor (1.4.4-1) unstable; urgency=medium
+vitastor (0.8.3-1) unstable; urgency=medium
  * Bugfixes
 -- Vitaliy Filippov <vitalif@yourcmc.ru>  Fri, 03 Jun 2022 02:09:44 +0300
-vitastor (0.7.0-1) unstable; urgency=medium
+vitastor (0.8.3-1) unstable; urgency=medium
  * Implement NFS proxy
  * Add documentation
--- a/debian/control
+++ b/debian/control
@ -2,7 +2,7 @@ Source: vitastor
 Section: admin
 Priority: optional
 Maintainer: Vitaliy Filippov <vitalif@yourcmc.ru>
-Build-Depends: debhelper, liburing-dev (>= 0.6), g++ (>= 8), libstdc++6 (>= 8), linux-libc-dev, libgoogle-perftools-dev, libjerasure-dev, libgf-complete-dev, libibverbs-dev, libisal-dev, cmake, pkg-config
+Build-Depends: debhelper, liburing-dev (>= 0.6), g++ (>= 8), libstdc++6 (>= 8), linux-libc-dev, libgoogle-perftools-dev, libjerasure-dev, libgf-complete-dev, libibverbs-dev, libisal-dev
 Standards-Version: 4.5.0
 Homepage: https://vitastor.io/
 Rules-Requires-Root: no
--- a/debian/patched-qemu.Dockerfile
+++ b/debian/patched-qemu.Dockerfile
@ -1,4 +1,4 @@
-# Build patched QEMU for Debian inside a container
+# Build patched QEMU for Debian Buster or Bullseye/Sid inside a container
 # cd ..; podman build --build-arg REL=bullseye -v `pwd`/packages:/root/packages -f debian/patched-qemu.Dockerfile .
 ARG REL=
@ -7,7 +7,7 @@ ARG REL=
 WORKDIR /root
-RUN if [ "$REL" = "buster" -o "$REL" = "bullseye" -o "$REL" = "bookworm" ]; then \
+RUN if [ "$REL" = "buster" -o "$REL" = "bullseye" ]; then \
        echo "deb http://deb.debian.org/debian $REL-backports main" >> /etc/apt/sources.list; \
        echo >> /etc/apt/preferences; \
        echo 'Package: *' >> /etc/apt/preferences; \
@ -15,47 +15,47 @@ RUN if [ "$REL" = "buster" -o "$REL" = "bullseye" -o "$REL" = "bookworm" ]; then
        echo 'Pin-Priority: 500' >> /etc/apt/preferences; \
    fi; \
    grep '^deb ' /etc/apt/sources.list | perl -pe 's/^deb/deb-src/' >> /etc/apt/sources.list; \
    perl -i -pe 's/Types: deb$/Types: deb deb-src/' /etc/apt/sources.list.d/debian.sources || true; \
    echo 'APT::Install-Recommends false;' >> /etc/apt/apt.conf; \
    echo 'APT::Install-Suggests false;' >> /etc/apt/apt.conf
 RUN apt-get update
-RUN apt-get -y install fio liburing-dev libgoogle-perftools-dev devscripts
+RUN apt-get -y install qemu fio liburing1 liburing-dev libgoogle-perftools-dev devscripts
 RUN apt-get -y build-dep qemu
 # To build a custom version
 #RUN cp /root/packages/qemu-orig/* /root
 RUN apt-get --download-only source qemu
-ADD patches /root/vitastor/patches
+ADD patches/qemu-5.0-vitastor.patch patches/qemu-5.1-vitastor.patch patches/qemu-6.1-vitastor.patch src/qemu_driver.c /root/vitastor/patches/
 ADD src/qemu_driver.c /root/vitastor/src/qemu_driver.c
 #RUN set -e; \
 #    apt-get install -y wget; \
 #    wget -q -O /etc/apt/trusted.gpg.d/vitastor.gpg https://vitastor.io/debian/pubkey.gpg; \
 #    (echo deb http://vitastor.io/debian $REL main > /etc/apt/sources.list.d/vitastor.list); \
 #    (echo "APT::Install-Recommends false;" > /etc/apt/apt.conf) && \
 #    apt-get update; \
 #    apt-get install -y vitastor-client vitastor-client-dev quilt
 RUN set -e; \
-    dpkg -i /root/packages/vitastor-$REL/vitastor-client_*.deb /root/packages/vitastor-$REL/vitastor-client-dev_*.deb; \
+    apt-get install -y wget; \
    wget -q -O /etc/apt/trusted.gpg.d/vitastor.gpg https://vitastor.io/debian/pubkey.gpg; \
    (echo deb http://vitastor.io/debian $REL main > /etc/apt/sources.list.d/vitastor.list); \
    (echo "APT::Install-Recommends false;" > /etc/apt/apt.conf) && \
    apt-get update; \
-    apt-get install -y quilt; \
+    apt-get install -y vitastor-client vitastor-client-dev quilt; \
    mkdir -p /root/packages/qemu-$REL; \
    rm -rf /root/packages/qemu-$REL/*; \
    cd /root/packages/qemu-$REL; \
    dpkg-source -x /root/qemu*.dsc; \
-    QEMU_VER=$(ls -d qemu*/ | perl -pe 's!^.*?(\d+\.\d+).*!$1!'); \
+    if ls -d /root/packages/qemu-$REL/qemu-5.0*; then \
-    D=$(ls -d qemu*/); \
+        D=$(ls -d /root/packages/qemu-$REL/qemu-5.0*); \
-    cp /root/vitastor/patches/qemu-$QEMU_VER-vitastor.patch ./qemu-*/debian/patches; \
+        cp /root/vitastor/patches/qemu-5.0-vitastor.patch $D/debian/patches; \
-    echo qemu-$QEMU_VER-vitastor.patch >> $D/debian/patches/series; \
+        echo qemu-5.0-vitastor.patch >> $D/debian/patches/series; \
    elif ls /root/packages/qemu-$REL/qemu-6.1*; then \
        D=$(ls -d /root/packages/qemu-$REL/qemu-6.1*); \
        cp /root/vitastor/patches/qemu-6.1-vitastor.patch $D/debian/patches; \
        echo qemu-6.1-vitastor.patch >> $D/debian/patches/series; \
    else \
        cp /root/vitastor/patches/qemu-5.1-vitastor.patch /root/packages/qemu-$REL/qemu-*/debian/patches; \
        P=`ls -d /root/packages/qemu-$REL/qemu-*/debian/patches`; \
        echo qemu-5.1-vitastor.patch >> $P/series; \
    fi; \
    cd /root/packages/qemu-$REL/qemu-*/; \
    quilt push -a; \
    quilt add block/vitastor.c; \
-    cp /root/vitastor/src/qemu_driver.c block/vitastor.c; \
+    cp /root/vitastor/patches/qemu_driver.c block/vitastor.c; \
    quilt refresh; \
-    V=$(head -n1 debian/changelog | perl -pe 's/5\.2\+dfsg-9/5.2+dfsg-11/; s/^.*\((.*?)(~bpo[\d\+]*)?\).*$/$1/')+vitastor4; \
+    V=$(head -n1 debian/changelog | perl -pe 's/^.*\((.*?)(~bpo[\d\+]*)?\).*$/$1/')+vitastor1; \
    if [ "$REL" = bullseye ]; then V=${V}bullseye; fi; \
    DEBEMAIL="Vitaliy Filippov <vitalif@yourcmc.ru>" dch -D $REL -v $V 'Plug Vitastor block driver'; \
    DEB_BUILD_OPTIONS=nocheck dpkg-buildpackage --jobs=auto -sa; \
    rm -rf /root/packages/qemu-$REL/qemu-*/
--- a/debian/vitastor.Dockerfile
+++ b/debian/vitastor.Dockerfile
@ -1,4 +1,4 @@
-# Build Vitastor packages for Debian inside a container
+# Build Vitastor packages for Debian Buster or Bullseye/Sid inside a container
 # cd ..; podman build --build-arg REL=bullseye -v `pwd`/packages:/root/packages -f debian/vitastor.Dockerfile .
 ARG REL=
@ -15,12 +15,11 @@ RUN if [ "$REL" = "buster" -o "$REL" = "bullseye" ]; then \
        echo 'Pin-Priority: 500' >> /etc/apt/preferences; \
    fi; \
    grep '^deb ' /etc/apt/sources.list | perl -pe 's/^deb/deb-src/' >> /etc/apt/sources.list; \
    perl -i -pe 's/Types: deb$/Types: deb deb-src/' /etc/apt/sources.list.d/debian.sources || true; \
    echo 'APT::Install-Recommends false;' >> /etc/apt/apt.conf; \
    echo 'APT::Install-Suggests false;' >> /etc/apt/apt.conf
 RUN apt-get update
-RUN apt-get -y install fio liburing-dev libgoogle-perftools-dev devscripts
+RUN apt-get -y install fio liburing1 liburing-dev libgoogle-perftools-dev devscripts
 RUN apt-get -y build-dep fio
 RUN apt-get --download-only source fio
 RUN apt-get update && apt-get -y install libjerasure-dev cmake libibverbs-dev libisal-dev
@ -35,8 +34,8 @@ RUN set -e -x; \
    mkdir -p /root/packages/vitastor-$REL; \
    rm -rf /root/packages/vitastor-$REL/*; \
    cd /root/packages/vitastor-$REL; \
-    cp -r /root/vitastor vitastor-1.4.4; \
+    cp -r /root/vitastor vitastor-0.8.3; \
-    cd vitastor-1.4.4; \
+    cd vitastor-0.8.3; \
    ln -s /root/fio-build/fio-*/ ./fio; \
    FIO=$(head -n1 fio/debian/changelog | perl -pe 's/^.*\((.*?)\).*$/$1/'); \
    ls /usr/include/linux/raw.h || cp ./debian/raw.h /usr/include/linux/raw.h; \
@ -49,8 +48,8 @@ RUN set -e -x; \
    rm -rf a b; \
    echo "dep:fio=$FIO" > debian/fio_version; \
    cd /root/packages/vitastor-$REL; \
-    tar --sort=name --mtime='2020-01-01' --owner=0 --group=0 --exclude=debian -cJf vitastor_1.4.4.orig.tar.xz vitastor-1.4.4; \
+    tar --sort=name --mtime='2020-01-01' --owner=0 --group=0 --exclude=debian -cJf vitastor_0.8.3.orig.tar.xz vitastor-0.8.3; \
-    cd vitastor-1.4.4; \
+    cd vitastor-0.8.3; \
    V=$(head -n1 debian/changelog | perl -pe 's/^.*\((.*?)\).*$/$1/'); \
    DEBFULLNAME="Vitaliy Filippov <vitalif@yourcmc.ru>" dch -D $REL -v "$V""$REL" "Rebuild for $REL"; \
    DEB_BUILD_OPTIONS=nocheck dpkg-buildpackage --jobs=auto -sa; \
--- a/docker/vitastor.gpg
+++ b/docker/vitastor.gpg
--- a/docs/config.en.md
+++ b/docs/config.en.md
@ -17,23 +17,20 @@ Configuration parameters can be set in 3 places:
 - Configuration file (`/etc/vitastor/vitastor.conf` or other path)
 - etcd key `/vitastor/config/global`. Most variables can be set there, but etcd
  connection parameters should obviously be set in the configuration file.
- Command line of Vitastor components: OSD (when you run it without vitastor-disk),
+- Command line of Vitastor components: OSD, mon, fio and QEMU options,
-  mon, fio and QEMU options, OpenStack/Proxmox/etc configuration. The latter
+  OpenStack/Proxmox/etc configuration. The latter doesn't allow to set all
-  doesn't allow to set all variables directly, but it allows to override the
+  variables directly, but it allows to override the configuration file and
-  configuration file and set everything you need inside it.
+  set everything you need inside it.
 - OSD superblocks created by [vitastor-disk](usage/disk.en.md) contain
  primarily disk layout parameters of specific OSDs. In fact, these parameters
  are automatically passed into the command line of vitastor-osd process, so
  they have the same "status" as command-line parameters.
 In the future, additional configuration methods may be added:
 - OSD superblock which will, by design, contain parameters related to the disk
  layout and to one specific OSD.
 - OSD-specific keys in etcd like `/vitastor/config/osd/<number>`.
 ## Parameter Reference
 - [Common](config/common.en.md)
 - [Network](config/network.en.md)
 - [Client](config/client.en.md)
 - [Global Disk Layout](config/layout-cluster.en.md)
 - [OSD Disk Layout](config/layout-osd.en.md)
 - [OSD Runtime Parameters](config/osd.en.md)
--- a/docs/config.ru.md
+++ b/docs/config.ru.md
@ -19,24 +19,20 @@
 - Ключе в etcd `/vitastor/config/global`. Большая часть параметров может
  задаваться там, кроме, естественно, самих параметров соединения с etcd,
  которые должны задаваться в файле конфигурации
- В командной строке компонентов Vitastor: OSD (при ручном запуске без vitastor-disk),
+- В командной строке компонентов Vitastor: OSD, монитора, опциях fio и QEMU,
-  монитора, опциях fio и QEMU, настроек OpenStack, Proxmox и т.п. Последние,
+  настроек OpenStack, Proxmox и т.п. Последние, как правило, не включают полный
-  как правило, не включают полный набор параметров напрямую, но позволяют
+  набор параметров напрямую, но разрешают определить путь к файлу конфигурации
-  определить путь к файлу конфигурации и задать любые параметры в нём.
+  и задать любые параметры в нём.
 - В суперблоке OSD, записываемом [vitastor-disk](usage/disk.ru.md) - параметры,
  связанные с дисковым форматом и с этим конкретным OSD. На самом деле,
  при запуске OSD эти параметры автоматически передаются в командную строку
  процесса vitastor-osd, то есть по "статусу" они эквивалентны параметрам
  командной строки OSD.
 В будущем также могут быть добавлены другие способы конфигурации:
 - Суперблок OSD, в котором будут храниться параметры OSD, связанные с дисковым
  форматом и с этим конкретным OSD.
 - OSD-специфичные ключи в etcd типа `/vitastor/config/osd/<номер>`.
 ## Список параметров
 - [Общие](config/common.ru.md)
 - [Сеть](config/network.ru.md)
 - [Клиентский код](config/client.ru.md)
 - [Глобальные дисковые параметры](config/layout-cluster.ru.md)
 - [Дисковые параметры OSD](config/layout-osd.ru.md)
 - [Прочие параметры OSD](config/osd.ru.md)
--- a/docs/config/client.en.md
+++ b/docs/config/client.en.md
@ -1,137 +0,0 @@
 [Documentation](../../README.md#documentation) → [Configuration](../config.en.md) → Client Parameters
 -----
 [Читать на русском](client.ru.md)
 # Client Parameters
 These parameters apply only to Vitastor clients (QEMU, fio, NBD and so on) and
 affect their interaction with the cluster.
 - [client_max_dirty_bytes](#client_max_dirty_bytes)
 - [client_max_dirty_ops](#client_max_dirty_ops)
 - [client_enable_writeback](#client_enable_writeback)
 - [client_max_buffered_bytes](#client_max_buffered_bytes)
 - [client_max_buffered_ops](#client_max_buffered_ops)
 - [client_max_writeback_iodepth](#client_max_writeback_iodepth)
 - [nbd_timeout](#nbd_timeout)
 - [nbd_max_devices](#nbd_max_devices)
 - [nbd_max_part](#nbd_max_part)
 ## client_max_dirty_bytes
 - Type: integer
 - Default: 33554432
 - Can be changed online: yes
 Without [immediate_commit](layout-cluster.en.md#immediate_commit)=all this parameter sets the limit of "dirty"
 (not committed by fsync) data allowed by the client before forcing an
 additional fsync and committing the data. Also note that the client always
 holds a copy of uncommitted data in memory so this setting also affects
 RAM usage of clients.
 ## client_max_dirty_ops
 - Type: integer
 - Default: 1024
 - Can be changed online: yes
 Same as client_max_dirty_bytes, but instead of total size, limits the number
 of uncommitted write operations.
 ## client_enable_writeback
 - Type: boolean
 - Default: false
 - Can be changed online: yes
 This parameter enables client-side write buffering. This means that write
 requests are accumulated in memory for a short time before being sent to
 a Vitastor cluster which allows to send them in parallel and increase
 performance of some applications. Writes are buffered until client forces
 a flush with fsync() or until the amount of buffered writes exceeds the
 limit.
 Write buffering significantly increases performance of some applications,
 for example, CrystalDiskMark under Windows (LOL :-D), but also any other
 applications if they do writes in one of two non-optimal ways: either if
 they do a lot of small (4 kb or so) sequential writes, or if they do a lot
 of small random writes, but without any parallelism or asynchrony, and also
 without calling fsync().
 With write buffering enabled, you can expect around 22000 T1Q1 random write
 iops in QEMU more or less regardless of the quality of your SSDs, and this
 number is in fact bound by QEMU itself rather than Vitastor (check it
 yourself by adding a "driver=null-co" disk in QEMU). Without write
 buffering, the current record is 9900 iops, but the number is usually
 even lower with non-ideal hardware, for example, it may be 5000 iops.
 Even when this parameter is enabled, write buffering isn't enabled until
 the client explicitly allows it, because enabling it without the client
 being aware of the fact that his writes may be buffered may lead to data
 loss. Because of this, older versions of clients don't support write
 buffering at all, newer versions of the QEMU driver allow write buffering
 only if it's enabled in disk settings with `-blockdev cache.direct=false`,
 and newer versions of FIO only allow write buffering if you don't specify
 `-direct=1`. NBD and NFS drivers allow write buffering by default.
 You can overcome this restriction too with the `client_writeback_allowed`
 parameter, but you shouldn't do that unless you **really** know what you
 are doing.
 ## client_max_buffered_bytes
 - Type: integer
 - Default: 33554432
 - Can be changed online: yes
 Maximum total size of buffered writes which triggers write-back when reached.
 ## client_max_buffered_ops
 - Type: integer
 - Default: 1024
 - Can be changed online: yes
 Maximum number of buffered writes which triggers write-back when reached.
 Multiple consecutive modified data regions are counted as 1 write here.
 ## client_max_writeback_iodepth
 - Type: integer
 - Default: 256
 - Can be changed online: yes
 Maximum number of parallel writes when flushing buffered data to the server.
 ## nbd_timeout
 - Type: seconds
 - Default: 300
 Timeout for I/O operations for [NBD](../usage/nbd.en.md). If an operation
 executes for longer than this timeout, including when your cluster is just
 temporarily down for more than timeout, the NBD device will detach by itself
 (and possibly break the mounted file system).
 You can set timeout to 0 to never detach, but in that case you won't be
 able to remove the kernel device at all if the NBD process dies - you'll have
 to reboot the host.
 ## nbd_max_devices
 - Type: integer
 - Default: 64
 Maximum number of NBD devices in the system. This value is passed as
 `nbds_max` parameter for the nbd kernel module when vitastor-nbd autoloads it.
 ## nbd_max_part
 - Type: integer
 - Default: 3
 Maximum number of partitions per NBD device. This value is passed as
 `max_part` parameter for the nbd kernel module when vitastor-nbd autoloads it.
 Note that (nbds_max)*(1+max_part) usually can't exceed 256.
--- a/docs/config/client.ru.md
+++ b/docs/config/client.ru.md
@ -1,137 +0,0 @@
 [Документация](../../README-ru.md#документация) → [Конфигурация](../config.ru.md) → Параметры клиентского кода
 -----
 [Read in English](client.en.md)
 # Параметры клиентского кода
 Данные параметры применяются только к клиентам Vitastor (QEMU, fio, NBD и т.п.) и
 затрагивают логику их работы с кластером.
 - [client_max_dirty_bytes](#client_max_dirty_bytes)
 - [client_max_dirty_ops](#client_max_dirty_ops)
 - [client_enable_writeback](#client_enable_writeback)
 - [client_max_buffered_bytes](#client_max_buffered_bytes)
 - [client_max_buffered_ops](#client_max_buffered_ops)
 - [client_max_writeback_iodepth](#client_max_writeback_iodepth)
 - [nbd_timeout](#nbd_timeout)
 - [nbd_max_devices](#nbd_max_devices)
 - [nbd_max_part](#nbd_max_part)
 ## client_max_dirty_bytes
 - Тип: целое число
 - Значение по умолчанию: 33554432
 - Можно менять на лету: да
 При работе без [immediate_commit](layout-cluster.ru.md#immediate_commit)=all - это лимит объёма "грязных" (не
 зафиксированных fsync-ом) данных, при достижении которого клиент будет
 принудительно вызывать fsync и фиксировать данные. Также стоит иметь в виду,
 что в этом случае до момента fsync клиент хранит копию незафиксированных
 данных в памяти, то есть, настройка влияет на потребление памяти клиентами.
 ## client_max_dirty_ops
 - Тип: целое число
 - Значение по умолчанию: 1024
 - Можно менять на лету: да
 Аналогично client_max_dirty_bytes, но ограничивает количество
 незафиксированных операций записи вместо их общего объёма.
 ## client_enable_writeback
 - Тип: булево (да/нет)
 - Значение по умолчанию: false
 - Можно менять на лету: да
 Данный параметр разрешает включать буферизацию записи в памяти. Буферизация
 означает, что операции записи отправляются на кластер Vitastor не сразу, а
 могут небольшое время накапливаться в памяти и сбрасываться сразу пакетами,
 до тех пор, пока либо не будет превышен лимит неотправленных записей, либо
 пока клиент не вызовет fsync.
 Буферизация значительно повышает производительность некоторых приложений,
 например, CrystalDiskMark в Windows (ха-ха :-D), но также и любых других,
 которые пишут на диск неоптимально: либо последовательно, но мелкими блоками
 (например, по 4 кб), либо случайно, но без параллелизма и без fsync - то
 есть, например, отправляя 128 операций записи в разные места диска, но не
 все сразу с помощью асинхронного I/O, а по одной.
 В QEMU с буферизацией записи можно ожидать показателя примерно 22000
 операций случайной записи в секунду в 1 поток и с глубиной очереди 1 (T1Q1)
 без fsync, почти вне зависимости от того, насколько хороши ваши диски - эта
 цифра упирается в сам QEMU. Без буферизации рекорд пока что - 9900 операций
 в секунду, но на железе похуже может быть и поменьше, например, 5000 операций
 в секунду.
 При этом, даже если данный параметр включён, буферизация не включается, если
 явно не разрешена клиентом, т.к. если клиент не знает, что запросы записи
 буферизуются, это может приводить к потере данных. Поэтому в старых версиях
 клиентских драйверов буферизация записи не включается вообще, в новых
 версиях QEMU-драйвера включается, только если разрешена опцией диска
 `-blockdev cache.direct=false`, а в fio - только если нет опции `-direct=1`.
 В NBD и NFS драйверах буферизация записи разрешена по умолчанию.
 Можно обойти и это ограничение с помощью параметра `client_writeback_allowed`,
 но делать так не надо, если только вы не уверены в том, что делаете, на все
 100%. :-)
 ## client_max_buffered_bytes
 - Тип: целое число
 - Значение по умолчанию: 33554432
 - Можно менять на лету: да
 Максимальный общий размер буферизованных записей, при достижении которого
 начинается процесс сброса данных на сервер.
 ## client_max_buffered_ops
 - Тип: целое число
 - Значение по умолчанию: 1024
 - Можно менять на лету: да
 Максимальное количество буферизованных записей, при достижении которого
 начинается процесс сброса данных на сервер. При этом несколько
 последовательных изменённых областей здесь считаются 1 записью.
 ## client_max_writeback_iodepth
 - Тип: целое число
 - Значение по умолчанию: 256
 - Можно менять на лету: да
 Максимальное число параллельных операций записи при сбросе буферов на сервер.
 ## nbd_timeout
 - Тип: секунды
 - Значение по умолчанию: 300
 Таймаут для операций чтения/записи через [NBD](../usage/nbd.ru.md). Если
 операция выполняется дольше таймаута, включая временную недоступность
 кластера на время, большее таймаута, NBD-устройство отключится само собой
 (и, возможно, сломает примонтированную ФС).
 Вы можете установить таймаут в 0, чтобы никогда не отключать устройство по
 таймауту, но в этом случае вы вообще не сможете удалить устройство, если
 процесс NBD умрёт - вам придётся перезагружать сервер.
 ## nbd_max_devices
 - Тип: целое число
 - Значение по умолчанию: 64
 Максимальное число NBD-устройств в системе. Данное значение передаётся
 модулю ядра nbd как параметр `nbds_max`, когда его загружает vitastor-nbd.
 ## nbd_max_part
 - Тип: целое число
 - Значение по умолчанию: 3
 Максимальное число разделов на одном NBD-устройстве. Данное значение передаётся
 модулю ядра nbd как параметр `max_part`, когда его загружает vitastor-nbd.
 Имейте в виду, что (nbds_max)*(1+max_part) обычно не может превышать 256.
--- a/docs/config/common.en.md
+++ b/docs/config/common.en.md
@ -25,16 +25,11 @@ running if required parameters are specified.
 ## etcd_address
 - Type: string or array of strings
 - Can be changed online: yes
 etcd connection endpoint(s). Multiple endpoints may be delimited by "," or
 specified in a JSON array `["10.0.115.10:2379/v3","10.0.115.11:2379/v3"]`.
 Note that https is not supported for etcd connections yet.
 etcd connection endpoints can be changed online by updating global
 configuration in etcd itself - this allows to switch the cluster to new
 etcd addresses without downtime.
 ## etcd_prefix
 - Type: string
@ -47,6 +42,5 @@ example, use a single etcd cluster for multiple Vitastor clusters.
 - Type: integer
 - Default: 0
 - Can be changed online: yes
 Log level. Raise if you want more verbose output.
--- a/docs/config/common.ru.md
+++ b/docs/config/common.ru.md
@ -24,14 +24,10 @@
 ## etcd_address
 - Тип: строка или массив строк
 - Можно менять на лету: да
 Адрес(а) подключения к etcd. Несколько адресов могут разделяться запятой
 или указываться в виде JSON-массива `["10.0.115.10:2379/v3","10.0.115.11:2379/v3"]`.
 Адреса подключения к etcd можно поменять на лету, обновив конфигурацию в
 самом etcd - это позволяет переключить кластер на новые etcd без остановки.
 ## etcd_prefix
 - Тип: строка
@ -45,6 +41,5 @@
 - Тип: целое число
 - Значение по умолчанию: 0
 - Можно менять на лету: да
 Уровень логгирования. Повысьте, если хотите более подробный вывод.
--- a/docs/config/layout-cluster.en.md
+++ b/docs/config/layout-cluster.en.md
@ -33,13 +33,12 @@ Size of objects (data blocks) into which all physical and virtual drives
 in Vitastor, affects memory usage, write amplification and I/O load
 distribution effectiveness.
-Recommended default block size is 128 KB for SSD and 1 MB for HDD. In fact,
+Recommended default block size is 128 KB for SSD and 4 MB for HDD. In fact,
-it's possible to use 1 MB for SSD too - it will lower memory usage, but
+it's possible to use 4 MB for SSD too - it will lower memory usage, but
 may increase average WA and reduce linear performance.
 OSD memory usage is roughly (SIZE / BLOCK * 68 bytes) which is roughly
 544 MB per 1 TB of used disk space with the default 128 KB block size.
 With 1 MB it's 8 times lower.
 ## bitmap_granularity
@ -96,9 +95,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_journal_fsync and disable_meta_fsync, setting it to "all" also requires
-[disable_meta_fsync](layout-osd.en.yml#disable_meta_fsync), setting it to
+enabling disable_data_fsync.
 "all" also requires enabling [disable_data_fsync](layout-osd.en.yml#disable_data_fsync).
 TLDR: For optimal performance, set immediate_commit to "all" if you only use
 SSDs with supercapacitor-based power loss protection (nonvolatile
--- a/docs/config/layout-cluster.ru.md
+++ b/docs/config/layout-cluster.ru.md
@ -33,14 +33,14 @@ OSD) могут сосуществовать в одном кластере Vita
 настроек, влияет на потребление памяти, объём избыточной записи (write
 amplification) и эффективность распределения нагрузки по OSD.
-Рекомендуемые по умолчанию размеры блока - 128 килобайт для SSD и 1 мегабайт
+Рекомендуемые по умолчанию размеры блока - 128 килобайт для SSD и 4
-для HDD. В принципе, для SSD можно тоже использовать блок размером 1 мегабайт,
+мегабайта для HDD. В принципе, для SSD можно тоже использовать 4 мегабайта,
 это понизит использование памяти, но ухудшит распределение нагрузки и в
 среднем увеличит WA.
 Потребление памяти OSD составляет примерно (РАЗМЕР / БЛОК * 68 байт),
 т.е. примерно 544 МБ памяти на 1 ТБ занятого места на диске при
-стандартном 128 КБ блоке. При 1 МБ блоке памяти нужно в 8 раз меньше.
+стандартном 128 КБ блоке.
 ## bitmap_granularity
@ -103,9 +103,8 @@ HDD-дисках с внутренним SSD или "медиа" кэшем - н
 указано в спецификациях).
 Указание "all" или "small" в настройках / командной строке OSD требует
-включения [disable_journal_fsync](layout-osd.ru.yml#disable_journal_fsync) и
+включения disable_journal_fsync и disable_meta_fsync, значение "all" также
-[disable_meta_fsync](layout-osd.ru.yml#disable_meta_fsync), значение "all"
+требует включения disable_data_fsync.
 также требует включения [disable_data_fsync](layout-osd.ru.yml#disable_data_fsync).
 Итого, вкратце: для оптимальной производительности установите
 immediate_commit в значение "all", если вы используете в кластере только SSD
--- a/docs/config/layout-osd.en.md
+++ b/docs/config/layout-osd.en.md
@ -24,8 +24,6 @@ initialization and can't be changed after it without losing data.
 - [disable_journal_fsync](#disable_journal_fsync)
 - [disable_device_lock](#disable_device_lock)
 - [disk_alignment](#disk_alignment)
 - [data_csum_type](#data_csum_type)
 - [csum_block_size](#csum_block_size)
 ## data_device
@ -176,43 +174,3 @@ Intel Optane (probably, not tested yet).
 Clients don't need to be aware of disk_alignment, so it's not required to
 put a modified value into etcd key /vitastor/config/global.
 ## data_csum_type
 - Type: string
 - Default: none
 Data checksum type to use. May be "crc32c" or "none". Set to "crc32c" to
 enable data checksums.
 ## csum_block_size
 - Type: integer
 - Default: 4096
 Checksum calculation block size.
 Must be equal or a multiple of [bitmap_granularity](layout-cluster.en.md#bitmap_granularity)
 (which is usually 4 KB).
 Checksums increase metadata size by 4 bytes per each csum_block_size of data.
 Checksums are always a tradeoff:
 1. You either sacrifice +1 GB RAM per 1 TB of data
 2. Or you raise csum_block_size, for example, to 32k and sacrifice
   50% random write iops due to checksum read-modify-write
 3. Or you turn off [inmemory_metadata](osd.en.md#inmemory_metadata) and
   sacrifice 50% random read iops due to checksum reads
 All-flash clusters usually have enough RAM to use default csum_block_size,
 which uses 1 GB RAM per 1 TB of data. HDD clusters usually don't.
 Thus, recommended setups are:
 1. All-flash, 1 GB RAM per 1 TB data: default (csum_block_size=4k)
 2. All-flash, less RAM: csum_block_size=4k + inmemory_metadata=false
 3. Hybrid HDD+SSD: csum_block_size=4k + inmemory_metadata=false
 4. HDD-only, faster random read: csum_block_size=32k
 5. HDD-only, faster random write: csum_block_size=4k +
   inmemory_metadata=false + meta_io=cached
 See also [meta_io](osd.en.md#meta_io).
--- a/docs/config/layout-osd.ru.md
+++ b/docs/config/layout-osd.ru.md
@ -25,8 +25,6 @@
 - [disable_journal_fsync](#disable_journal_fsync)
 - [disable_device_lock](#disable_device_lock)
 - [disk_alignment](#disk_alignment)
 - [data_csum_type](#data_csum_type)
 - [csum_block_size](#csum_block_size)
 ## data_device
@ -185,47 +183,3 @@ journal_block_size и meta_block_size. Однако единственные SSD
 Клиентам не обязательно знать про disk_alignment, так что помещать значение
 этого параметра в etcd в /vitastor/config/global не нужно.
 ## data_csum_type
 - Тип: строка
 - Значение по умолчанию: none
 Тип используемых OSD контрольных сумм данных. Может быть "crc32c" или "none".
 Установите в "crc32c", чтобы включить расчёт и проверку контрольных сумм данных.
 Следует понимать, что контрольные суммы в зависимости от размера блока их
 расчёта либо увеличивают потребление памяти, либо снижают производительность.
 Подробнее смотрите в описании параметра [csum_block_size](#csum_block_size).
 ## csum_block_size
 - Тип: целое число
 - Значение по умолчанию: 4096
 Размер блока расчёта контрольных сумм.
 Должен быть равен или кратен [bitmap_granularity](layout-cluster.ru.md#bitmap_granularity)
 (который обычно равен 4 КБ).
 Контрольные суммы увеличивают размер метаданных на 4 байта на каждые
 csum_block_size данных.
 Контрольные суммы - это всегда компромисс:
 1. Вы либо жертвуете потреблением +1 ГБ памяти на 1 ТБ дискового пространства
 2. Либо вы повышаете csum_block_size до, скажем, 32k и жертвуете 50%
   скорости случайной записи из-за цикла чтения-изменения-записи для расчёта
   новых контрольных сумм
 3. Либо вы отключаете [inmemory_metadata](osd.ru.md#inmemory_metadata) и
   жертвуете 50% скорости случайного чтения из-за чтения контрольных сумм
   с диска
 Таким образом, рекомендуются следующие варианты настроек:
 1. All-flash, 1 ГБ памяти на 1 ТБ данных: по умолчанию (csum_block_size=4k)
 2. All-flash, меньше памяти: csum_block_size=4k + inmemory_metadata=false
 3. Гибридные HDD+SSD: csum_block_size=4k + inmemory_metadata=false
 4. Только HDD, быстрее случайное чтение: csum_block_size=32k
 5. Только HDD, быстрее случайная запись: csum_block_size=4k +
   inmemory_metadata=false + meta_io=cached
 Смотрите также [meta_io](osd.ru.md#meta_io).
--- a/docs/config/monitor.en.md
+++ b/docs/config/monitor.en.md
@ -19,8 +19,8 @@ These parameters only apply to Monitors.
 ## etcd_mon_ttl
 - Type: seconds
- Default: 1
+- Default: 30
- Minimum: 5
+- Minimum: 10
 Monitor etcd lease refresh interval in seconds
--- a/docs/config/monitor.ru.md
+++ b/docs/config/monitor.ru.md
@ -19,8 +19,8 @@
 ## etcd_mon_ttl
 - Тип: секунды
- Значение по умолчанию: 1
+- Значение по умолчанию: 30
- Минимальное значение: 5
+- Минимальное значение: 10
 Интервал обновления etcd резервации (lease) монитором
--- a/docs/config/network.en.md
+++ b/docs/config/network.en.md
@ -19,8 +19,6 @@ between clients, OSDs and etcd.
 - [rdma_max_sge](#rdma_max_sge)
 - [rdma_max_msg](#rdma_max_msg)
 - [rdma_max_recv](#rdma_max_recv)
 - [rdma_max_send](#rdma_max_send)
 - [rdma_odp](#rdma_odp)
 - [peer_connect_interval](#peer_connect_interval)
 - [peer_connect_timeout](#peer_connect_timeout)
 - [osd_idle_timeout](#osd_idle_timeout)
@ -31,6 +29,7 @@ between clients, OSDs and etcd.
 - [etcd_slow_timeout](#etcd_slow_timeout)
 - [etcd_keepalive_timeout](#etcd_keepalive_timeout)
 - [etcd_ws_keepalive_timeout](#etcd_ws_keepalive_timeout)
 - [client_dirty_limit](#client_dirty_limit)
 ## tcp_header_buffer_size
@ -69,20 +68,11 @@ but they are not connected to the cluster.
 - Type: string
 RDMA device name to use for Vitastor OSD communications (for example,
-"rocep5s0f0"). Now Vitastor supports all adapters, even ones without
+"rocep5s0f0"). Please note that Vitastor RDMA requires Implicit On-Demand
-ODP support, like Mellanox ConnectX-3 and non-Mellanox cards.
+Paging (Implicit ODP) and Scatter/Gather (SG) support from the RDMA device
-
+to work. For example, Mellanox ConnectX-3 and older adapters don't have
-Versions up to Vitastor 1.2.0 required ODP which is only present in
+Implicit ODP, so they're unsupported by Vitastor. Run `ibv_devinfo -v` as
-Mellanox ConnectX >= 4. See also [rdma_odp](#rdma_odp).
+root to list available RDMA devices and their features.
 Run `ibv_devinfo -v` as root to list available RDMA devices and their
 features.
 Remember that you also have to configure your network switches if you use
 RoCE/RoCEv2, otherwise you may experience unstable performance. Refer to
 the manual of your network vendor for details about setting up the switch
 for RoCEv2 correctly. Usually it means setting up Lossless Ethernet with
 PFC (Priority Flow Control) and ECN (Explicit Congestion Notification).
 ## rdma_port_num
@ -126,59 +116,26 @@ required to change this parameter.
 ## rdma_max_msg
 - Type: integer
- Default: 132096
+- Default: 1048576
 Maximum size of a single RDMA send or receive operation in bytes.
 ## rdma_max_recv
 - Type: integer
 - Default: 16
 Maximum number of RDMA receive buffers per connection (RDMA requires
 preallocated buffers to receive data). Each buffer is `rdma_max_msg` bytes
 in size. So this setting directly affects memory usage: a single Vitastor
 RDMA client uses `rdma_max_recv * rdma_max_msg * OSD_COUNT` bytes of memory.
 Default is roughly 2 MB * number of OSDs.
 ## rdma_max_send
 - Type: integer
 - Default: 8
-Maximum number of outstanding RDMA send operations per connection. Should be
+Maximum number of parallel RDMA receive operations. Note that this number
-less than `rdma_max_recv` so the receiving side doesn't run out of buffers.
+of receive buffers `rdma_max_msg` in size are allocated for each client,
-Doesn't affect memory usage - additional memory isn't allocated for send
+so this setting actually affects memory usage. This is because RDMA receive
-operations.
+operations are (sadly) still not zero-copy in Vitastor. It may be fixed in
-
+later versions.
 ## rdma_odp
 - Type: boolean
 - Default: false
 Use RDMA with On-Demand Paging. ODP is currently only available on Mellanox
 ConnectX-4 and newer adapters. ODP allows to not register memory explicitly
 for RDMA adapter to be able to use it. This, in turn, allows to skip memory
 copying during sending. One would think this should improve performance, but
 **in reality** RDMA performance with ODP is **drastically** worse. Example
 3-node cluster with 8 NVMe in each node and 2*25 GBit/s ConnectX-6 RDMA network
 without ODP pushes 3950000 read iops, but only 239000 iops with ODP...
 This happens because Mellanox ODP implementation seems to be based on
 message retransmissions when the adapter doesn't know about the buffer yet -
 it likely uses standard "RNR retransmissions" (RNR = receiver not ready)
 which is generally slow in RDMA/RoCE networks. Here's a presentation about
 it from ISPASS-2021 conference: https://tkygtr6.github.io/pub/ISPASS21_slides.pdf
 ODP support is retained in the code just in case a good ODP implementation
 appears one day.
 ## peer_connect_interval
 - Type: seconds
 - Default: 5
 - Minimum: 1
 - Can be changed online: yes
 Interval before attempting to reconnect to an unavailable OSD.
@ -187,7 +144,6 @@ Interval before attempting to reconnect to an unavailable OSD.
 - Type: seconds
 - Default: 5
 - Minimum: 1
 - Can be changed online: yes
 Timeout for OSD connection attempts.
@ -196,7 +152,6 @@ Timeout for OSD connection attempts.
 - Type: seconds
 - Default: 5
 - Minimum: 1
 - Can be changed online: yes
 OSD connection inactivity time after which clients and other OSDs send
 keepalive requests to check state of the connection.
@ -206,7 +161,6 @@ keepalive requests to check state of the connection.
 - Type: seconds
 - Default: 5
 - Minimum: 1
 - Can be changed online: yes
 Maximum time to wait for OSD keepalive responses. If an OSD doesn't respond
 within this time, the connection to it is dropped and a reconnection attempt
@ -215,9 +169,8 @@ is scheduled.
 ## up_wait_retry_interval
 - Type: milliseconds
- Default: 50
+- Default: 500
- Minimum: 10
+- Minimum: 50
 - Can be changed online: yes
 OSDs respond to clients with a special error code when they receive I/O
 requests for a PG that's not synchronized and started. This parameter sets
@ -227,7 +180,6 @@ the time for the clients to wait before re-attempting such I/O requests.
 - Type: integer
 - Default: 5
 - Can be changed online: yes
 Maximum number of attempts for etcd requests which can't be retried
 indefinitely.
@ -236,7 +188,6 @@ indefinitely.
 - Type: milliseconds
 - Default: 1000
 - Can be changed online: yes
 Timeout for etcd requests which should complete quickly, like lease refresh.
@ -244,7 +195,6 @@ Timeout for etcd requests which should complete quickly, like lease refresh.
 - Type: milliseconds
 - Default: 5000
 - Can be changed online: yes
 Timeout for etcd requests which are allowed to wait for some time.
@ -252,7 +202,6 @@ Timeout for etcd requests which are allowed to wait for some time.
 - Type: seconds
 - Default: max(30, etcd_report_interval*2)
 - Can be changed online: yes
 Timeout for etcd connection HTTP Keep-Alive. Should be higher than
 etcd_report_interval to guarantee that keepalive actually works.
@ -261,7 +210,19 @@ etcd_report_interval to guarantee that keepalive actually works.
 - Type: seconds
 - Default: 30
 - Can be changed online: yes
 etcd websocket ping interval required to keep the connection alive and
 detect disconnections quickly.
 ## client_dirty_limit
 - Type: integer
 - Default: 33554432
 Without immediate_commit=all this parameter sets the limit of "dirty"
 (not committed by fsync) data allowed by the client before forcing an
 additional fsync and committing the data. Also note that the client always
 holds a copy of uncommitted data in memory so this setting also affects
 RAM usage of clients.
 This parameter doesn't affect OSDs themselves.
--- a/docs/config/network.ru.md
+++ b/docs/config/network.ru.md
@ -19,8 +19,6 @@
 - [rdma_max_sge](#rdma_max_sge)
 - [rdma_max_msg](#rdma_max_msg)
 - [rdma_max_recv](#rdma_max_recv)
 - [rdma_max_send](#rdma_max_send)
 - [rdma_odp](#rdma_odp)
 - [peer_connect_interval](#peer_connect_interval)
 - [peer_connect_timeout](#peer_connect_timeout)
 - [osd_idle_timeout](#osd_idle_timeout)
@ -31,6 +29,7 @@
 - [etcd_slow_timeout](#etcd_slow_timeout)
 - [etcd_keepalive_timeout](#etcd_keepalive_timeout)
 - [etcd_ws_keepalive_timeout](#etcd_ws_keepalive_timeout)
 - [client_dirty_limit](#client_dirty_limit)
 ## tcp_header_buffer_size
@ -72,22 +71,12 @@ RDMA может быть нужно только если у клиентов е
 - Тип: строка
 Название RDMA-устройства для связи с Vitastor OSD (например, "rocep5s0f0").
-Сейчас Vitastor поддерживает все модели адаптеров, включая те, у которых
+Имейте в виду, что поддержка RDMA в Vitastor требует функций устройства
-нет поддержки ODP, то есть вы можете использовать RDMA с ConnectX-3 и
+Implicit On-Demand Paging (Implicit ODP) и Scatter/Gather (SG). Например,
-картами производства не Mellanox.
+адаптеры Mellanox ConnectX-3 и более старые не поддерживают Implicit ODP и
-
+потому не поддерживаются в Vitastor. Запустите `ibv_devinfo -v` от имени
-Версии Vitastor до 1.2.0 включительно требовали ODP, который есть только
+суперпользователя, чтобы посмотреть список доступных RDMA-устройств, их
-на Mellanox ConnectX 4 и более новых. См. также [rdma_odp](#rdma_odp).
+параметры и возможности.
 Запустите `ibv_devinfo -v` от имени суперпользователя, чтобы посмотреть
 список доступных RDMA-устройств, их параметры и возможности.
 Обратите внимание, что если вы используете RoCE/RoCEv2, вам также необходимо
 правильно настроить для него коммутаторы, иначе вы можете столкнуться с
 нестабильной производительностью. Подробную информацию о настройке
 коммутатора для RoCEv2 ищите в документации производителя. Обычно это
 подразумевает настройку сети без потерь на основе PFC (Priority Flow
 Control) и ECN (Explicit Congestion Notification).
 ## rdma_port_num
@ -132,62 +121,28 @@ OSD в любом случае согласовывают реальное зн
 ## rdma_max_msg
 - Тип: целое число
- Значение по умолчанию: 132096
+- Значение по умолчанию: 1048576
 Максимальный размер одной RDMA-операции отправки или приёма.
 ## rdma_max_recv
 - Тип: целое число
 - Значение по умолчанию: 16
 Максимальное число буферов для RDMA-приёма данных на одно соединение
 (RDMA требует заранее выделенных буферов для приёма данных). Каждый буфер
 имеет размер `rdma_max_msg` байт. Таким образом, настройка прямо влияет на
 потребление памяти - один Vitastor-клиент с RDMA использует
 `rdma_max_recv * rdma_max_msg * ЧИСЛО_OSD` байт памяти, по умолчанию -
 примерно 2 МБ * число OSD.
 ## rdma_max_send
 - Тип: целое число
 - Значение по умолчанию: 8
-Максимальное число RDMA-операций отправки, отправляемых в очередь одного
+Максимальное число параллельных RDMA-операций получения данных. Следует
-соединения. Желательно, чтобы оно было меньше `rdma_max_recv`, чтобы
+иметь в виду, что данное число буферов размером `rdma_max_msg` выделяется
-у принимающей стороны в процессе работы не заканчивались буферы на приём.
+для каждого подключённого клиентского соединения, так что данная настройка
-Не влияет на потребление памяти - дополнительная память на операции отправки
+влияет на потребление памяти. Это так потому, что RDMA-приём данных в
-не выделяется.
+Vitastor, увы, всё равно не является zero-copy, т.е. всё равно 1 раз
-
+копирует данные в памяти. Данная особенность, возможно, будет исправлена в
-## rdma_odp
+более новых версиях Vitastor.
 - Тип: булево (да/нет)
 - Значение по умолчанию: false
 Использовать RDMA с On-Demand Paging. ODP - функция, доступная пока что
 исключительно на адаптерах Mellanox ConnectX-4 и более новых. ODP позволяет
 не регистрировать память для её использования RDMA-картой. Благодаря этому
 можно не копировать данные при отправке их в сеть и, казалось бы, это должно
 улучшать производительность - но **по факту** получается так, что
 производительность только ухудшается, причём сильно. Пример - на 3-узловом
 кластере с 8 NVMe в каждом узле и сетью 2*25 Гбит/с на чтение с RDMA без ODP
 удаётся снять 3950000 iops, а с ODP - всего 239000 iops...
 Это происходит из-за того, что реализация ODP у Mellanox неоптимальная и
 основана на повторной передаче сообщений, когда карте не известен буфер -
 вероятно, на стандартных "RNR retransmission" (RNR = receiver not ready).
 А данные повторные передачи в RDMA/RoCE - всегда очень медленная штука.
 Презентация на эту тему с конференции ISPASS-2021: https://tkygtr6.github.io/pub/ISPASS21_slides.pdf
 Возможность использования ODP сохранена в коде на случай, если вдруг в один
 прекрасный день появится хорошая реализация ODP.
 ## peer_connect_interval
 - Тип: секунды
 - Значение по умолчанию: 5
 - Минимальное значение: 1
 - Можно менять на лету: да
 Время ожидания перед повторной попыткой соединиться с недоступным OSD.
@ -196,7 +151,6 @@ OSD в любом случае согласовывают реальное зн
 - Тип: секунды
 - Значение по умолчанию: 5
 - Минимальное значение: 1
 - Можно менять на лету: да
 Максимальное время ожидания попытки соединения с OSD.
@ -205,7 +159,6 @@ OSD в любом случае согласовывают реальное зн
 - Тип: секунды
 - Значение по умолчанию: 5
 - Минимальное значение: 1
 - Можно менять на лету: да
 Время неактивности соединения с OSD, после которого клиенты или другие OSD
 посылают запрос проверки состояния соединения.
@ -215,7 +168,6 @@ OSD в любом случае согласовывают реальное зн
 - Тип: секунды
 - Значение по умолчанию: 5
 - Минимальное значение: 1
 - Можно менять на лету: да
 Максимальное время ожидания ответа на запрос проверки состояния соединения.
 Если OSD не отвечает за это время, соединение отключается и производится
@ -224,9 +176,8 @@ OSD в любом случае согласовывают реальное зн
 ## up_wait_retry_interval
 - Тип: миллисекунды
- Значение по умолчанию: 50
+- Значение по умолчанию: 500
- Минимальное значение: 10
+- Минимальное значение: 50
 - Можно менять на лету: да
 Когда OSD получают от клиентов запросы ввода-вывода, относящиеся к не
 поднятым на данный момент на них PG, либо к PG в процессе синхронизации,
@ -238,7 +189,6 @@ OSD в любом случае согласовывают реальное зн
 - Тип: целое число
 - Значение по умолчанию: 5
 - Можно менять на лету: да
 Максимальное число попыток выполнения запросов к etcd для тех запросов,
 которые нельзя повторять бесконечно.
@ -247,7 +197,6 @@ OSD в любом случае согласовывают реальное зн
 - Тип: миллисекунды
 - Значение по умолчанию: 1000
 - Можно менять на лету: да
 Максимальное время выполнения запросов к etcd, которые должны завершаться
 быстро, таких, как обновление резервации (lease).
@ -256,7 +205,6 @@ OSD в любом случае согласовывают реальное зн
 - Тип: миллисекунды
 - Значение по умолчанию: 5000
 - Можно менять на лету: да
 Максимальное время выполнения запросов к etcd, для которых не обязательно
 гарантировать быстрое выполнение.
@ -265,7 +213,6 @@ OSD в любом случае согласовывают реальное зн
 - Тип: секунды
 - Значение по умолчанию: max(30, etcd_report_interval*2)
 - Можно менять на лету: да
 Таймаут для HTTP Keep-Alive в соединениях к etcd. Должен быть больше, чем
 etcd_report_interval, чтобы keepalive гарантированно работал.
@ -274,6 +221,18 @@ etcd_report_interval, чтобы keepalive гарантированно рабо
 - Тип: секунды
 - Значение по умолчанию: 30
 - Можно менять на лету: да
 Интервал проверки живости вебсокет-подключений к etcd.
 ## client_dirty_limit
 - Тип: целое число
 - Значение по умолчанию: 33554432
 При работе без immediate_commit=all - это лимит объёма "грязных" (не
 зафиксированных fsync-ом) данных, при достижении которого клиент будет
 принудительно вызывать fsync и фиксировать данные. Также стоит иметь в виду,
 что в этом случае до момента fsync клиент хранит копию незафиксированных
 данных в памяти, то есть, настройка влияет на потребление памяти клиентами.
 Параметр не влияет на сами OSD.
--- a/docs/config/osd.en.md
+++ b/docs/config/osd.en.md
@ -7,11 +7,9 @@
 # Runtime OSD Parameters
 These parameters only apply to OSDs, are not fixed at the moment of OSD drive
-initialization and can be changed - either with an OSD restart or, for some of
+initialization and can be changed with an OSD restart.
 them, even without restarting by updating configuration in etcd.
 - [etcd_report_interval](#etcd_report_interval)
 - [etcd_stats_interval](#etcd_stats_interval)
 - [run_primary](#run_primary)
 - [osd_network](#osd_network)
 - [bind_address](#bind_address)
@ -19,7 +17,6 @@ them, even without restarting by updating configuration in etcd.
 - [autosync_interval](#autosync_interval)
 - [autosync_writes](#autosync_writes)
 - [recovery_queue_depth](#recovery_queue_depth)
 - [recovery_sleep_us](#recovery_sleep_us)
 - [recovery_pg_switch](#recovery_pg_switch)
 - [recovery_sync_batch](#recovery_sync_batch)
 - [readonly](#readonly)
@ -33,9 +30,6 @@ them, even without restarting by updating configuration in etcd.
 - [max_flusher_count](#max_flusher_count)
 - [inmemory_metadata](#inmemory_metadata)
 - [inmemory_journal](#inmemory_journal)
 - [data_io](#data_io)
 - [meta_io](#meta_io)
 - [journal_io](#journal_io)
 - [journal_sector_buffer_count](#journal_sector_buffer_count)
 - [journal_no_same_sector_overwrites](#journal_no_same_sector_overwrites)
 - [throttle_small_writes](#throttle_small_writes)
@ -44,43 +38,17 @@ them, even without restarting by updating configuration in etcd.
 - [throttle_target_parallelism](#throttle_target_parallelism)
 - [throttle_threshold_us](#throttle_threshold_us)
 - [osd_memlock](#osd_memlock)
 - [auto_scrub](#auto_scrub)
 - [no_scrub](#no_scrub)
 - [scrub_interval](#scrub_interval)
 - [scrub_queue_depth](#scrub_queue_depth)
 - [scrub_sleep](#scrub_sleep)
 - [scrub_list_limit](#scrub_list_limit)
 - [scrub_find_best](#scrub_find_best)
 - [scrub_ec_max_bruteforce](#scrub_ec_max_bruteforce)
 - [recovery_tune_interval](#recovery_tune_interval)
 - [recovery_tune_util_low](#recovery_tune_util_low)
 - [recovery_tune_util_high](#recovery_tune_util_high)
 - [recovery_tune_client_util_low](#recovery_tune_client_util_low)
 - [recovery_tune_client_util_high](#recovery_tune_client_util_high)
 - [recovery_tune_agg_interval](#recovery_tune_agg_interval)
 - [recovery_tune_sleep_min_us](#recovery_tune_sleep_min_us)
 - [recovery_tune_sleep_cutoff_us](#recovery_tune_sleep_cutoff_us)
 ## etcd_report_interval
 - Type: seconds
 - Default: 5
-Interval at which OSDs report their liveness to etcd. Affects OSD lease time
+Interval at which OSDs report their state to etcd. Affects OSD lease time
 and thus the failover speed. Lease time is equal to this parameter value
 plus max_etcd_attempts * etcd_quick_timeout because it should be guaranteed
 that every OSD always refreshes its lease in time.
 ## etcd_stats_interval
 - Type: seconds
 - Default: 30
 Interval at which OSDs report their statistics to etcd. Highly affects the
 imposed load on etcd, because statistics include a key for every OSD and
 for every PG. At the same time, low statistic intervals make `vitastor-cli`
 statistics more responsive.
 ## run_primary
 - Type: boolean
@ -123,7 +91,6 @@ OSD by hand.
 - Type: seconds
 - Default: 5
 - Can be changed online: yes
 Time interval at which automatic fsyncs/flushes are issued by each OSD when
 the immediate_commit mode if disabled. fsyncs are required because without
@ -136,7 +103,6 @@ issue fsyncs at all.
 - Type: integer
 - Default: 128
 - Can be changed online: yes
 Same as autosync_interval, but sets the maximum number of uncommitted write
 operations before issuing an fsync operation internally.
@ -144,30 +110,16 @@ operations before issuing an fsync operation internally.
 ## recovery_queue_depth
 - Type: integer
- Default: 1
+- Default: 4
 - Can be changed online: yes
-Maximum recovery and rebalance operations initiated by each OSD in parallel.
+Maximum recovery operations per one primary OSD at any given moment of time.
-Note that each OSD talks to a lot of other OSDs so actual number of parallel
+Currently it's the only parameter available to tune the speed or recovery
-recovery operations per each OSD is greater than just recovery_queue_depth.
+and rebalancing, but it's planned to implement more.
 Increasing this parameter can speedup recovery if [auto-tuning](#recovery_tune_interval)
 allows it or if it is disabled.
 ## recovery_sleep_us
 - Type: microseconds
 - Default: 0
 - Can be changed online: yes
 Delay for all recovery- and rebalance- related operations. If non-zero,
 such operations are artificially slowed down to reduce the impact on
 client I/O.
 ## recovery_pg_switch
 - Type: integer
 - Default: 128
 - Can be changed online: yes
 Number of recovery operations before switching to recovery of the next PG.
 The idea is to mix all PGs during recovery for more even space and load
@ -178,7 +130,6 @@ Degraded PGs are anyway scanned first.
 - Type: integer
 - Default: 16
 - Can be changed online: yes
 Maximum number of recovery operations before issuing an additional fsync.
@ -194,7 +145,6 @@ the underlying device. This may be useful for recovery purposes.
 - Type: boolean
 - Default: false
 - Can be changed online: yes
 Disable automatic background recovery of objects. Note that it doesn't
 affect implicit recovery of objects happening during writes - a write is
@ -204,7 +154,6 @@ always made to a full set of at least pg_minsize OSDs.
 - Type: boolean
 - Default: false
 - Can be changed online: yes
 Disable background movement of data between different OSDs. Disabling it
 means that PGs in the `has_misplaced` state will be left in it indefinitely.
@ -213,7 +162,6 @@ means that PGs in the `has_misplaced` state will be left in it indefinitely.
 - Type: seconds
 - Default: 3
 - Can be changed online: yes
 Time interval at which OSDs print simple human-readable operation
 statistics on stdout.
@ -222,7 +170,6 @@ statistics on stdout.
 - Type: seconds
 - Default: 10
 - Can be changed online: yes
 Time interval at which OSDs dump slow or stuck operations on stdout, if
 they're any. Also it's the time after which an operation is considered
@ -232,7 +179,6 @@ they're any. Also it's the time after which an operation is considered
 - Type: seconds
 - Default: 60
 - Can be changed online: yes
 Number of seconds after which a deleted inode is removed from OSD statistics.
@ -240,7 +186,6 @@ Number of seconds after which a deleted inode is removed from OSD statistics.
 - Type: integer
 - Default: 128
 - Can be changed online: yes
 Parallel client write operation limit per one OSD. Operations that exceed
 this limit are pushed to a temporary queue instead of being executed
@ -250,7 +195,6 @@ immediately.
 - Type: integer
 - Default: 1
 - Can be changed online: yes
 Flusher is a micro-thread that moves data from the journal to the data
 area of the device. Their number is auto-tuned between minimum and maximum.
@ -260,7 +204,6 @@ Minimum number is set by this parameter.
 - Type: integer
 - Default: 256
 - Can be changed online: yes
 Maximum number of journal flushers (see above min_flusher_count).
@ -290,60 +233,6 @@ is typically very small because it's sufficient to have 16-32 MB journal
 for SSD OSDs. However, in theory it's possible that you'll want to turn it
 off for hybrid (HDD+SSD) OSDs with large journals on quick devices.
 ## data_io
 - Type: string
 - Default: direct
 I/O mode for *data*. One of "direct", "cached" or "directsync". Corresponds
 to O_DIRECT, O_SYNC and O_DIRECT|O_SYNC, respectively.
 Choose "cached" to use Linux page cache. This may improve read performance
 for hot data and slower disks - HDDs and maybe SATA SSDs - but will slightly
 decrease write performance for fast disks because page cache is an overhead
 itself.
 Choose "directsync" to use [immediate_commit](layout-cluster.ru.md#immediate_commit)
 (which requires disable_data_fsync) with drives having write-back cache
 which can't be turned off, for example, Intel Optane. Also note that *some*
 desktop SSDs (for example, HP EX950) may ignore O_SYNC thus making
 disable_data_fsync unsafe even with "directsync".
 ## meta_io
 - Type: string
 - Default: direct
 I/O mode for *metadata*. One of "direct", "cached" or "directsync".
 "cached" may improve read performance, but only under the following conditions:
 1. your drives are relatively slow (HDD, SATA SSD), and
 2. checksums are enabled, and
 3. [inmemory_metadata](#inmemory_metadata) is disabled.
 Under all these conditions, metadata blocks are read from disk on every
 read request to verify checksums and caching them may reduce this extra
 read load. Without (3) metadata is never read from the disk after starting,
 and without (2) metadata blocks are read from disk only during journal
 flushing.
 "directsync" is the same as above.
 If the same device is used for data and metadata, meta_io by default is set
 to the same value as [data_io](#data_io).
 ## journal_io
 - Type: string
 - Default: direct
 I/O mode for *journal*. One of "direct", "cached" or "directsync".
 Here, "cached" may only improve read performance for recent writes and
 only if [inmemory_journal](#inmemory_journal) is turned off.
 If the same device is used for metadata and journal, journal_io by default
 is set to the same value as [meta_io](#meta_io).
 ## journal_sector_buffer_count
 - Type: integer
@ -371,7 +260,6 @@ Most (99%) other SSDs don't need this option.
 - Type: boolean
 - Default: false
 - Can be changed online: yes
 Enable soft throttling of small journaled writes. Useful for hybrid OSDs
 with fast journal/metadata devices and slow data devices. The idea is that
@ -389,7 +277,6 @@ fills up.
 - Type: integer
 - Default: 100
 - Can be changed online: yes
 Target maximum number of throttled operations per second under the condition
 of full journal. Set it to approximate random write iops of your data devices
@ -399,7 +286,6 @@ of full journal. Set it to approximate random write iops of your data devices
 - Type: integer
 - Default: 100
 - Can be changed online: yes
 Target maximum bandwidth in MB/s of throttled operations per second under
 the condition of full journal. Set it to approximate linear write
@ -409,7 +295,6 @@ performance of your data devices (HDDs).
 - Type: integer
 - Default: 1
 - Can be changed online: yes
 Target maximum parallelism of throttled operations under the condition of
 full journal. Set it to approximate internal parallelism of your data
@ -419,7 +304,6 @@ devices (1 for HDDs, 4-8 for SSDs).
 - Type: microseconds
 - Default: 50
 - Can be changed online: yes
 Minimal computed delay to be applied to throttled operations. Usually
 doesn't need to be changed.
@ -429,190 +313,4 @@ doesn't need to be changed.
 - Type: boolean
 - Default: false
-Lock all OSD memory to prevent it from being unloaded into swap with
+Lock all OSD memory to prevent it from being unloaded into swap with mlockall(). Requires sufficient ulimit -l (max locked memory).
 mlockall(). Requires sufficient ulimit -l (max locked memory).
 ## auto_scrub
 - Type: boolean
 - Default: false
 - Can be changed online: yes
 Data scrubbing is the process of background verification of copies to find
 and repair corrupted blocks. It's not run automatically by default since
 it's a new feature. Set this parameter to true to enable automatic scrubs.
 This parameter makes OSDs automatically schedule data scrubbing of clean PGs
 every `scrub_interval` (see below). You can also start/schedule scrubbing
 manually by setting `next_scrub` JSON key to the desired UNIX time of the
 next scrub in `/pg/history/...` values in etcd.
 ## no_scrub
 - Type: boolean
 - Default: false
 - Can be changed online: yes
 Temporarily disable scrubbing and stop running scrubs.
 ## scrub_interval
 - Type: string
 - Default: 30d
 - Can be changed online: yes
 Default automatic scrubbing interval for all pools. Numbers without suffix
 are treated as seconds, possible unit suffixes include 's' (seconds),
 'm' (minutes), 'h' (hours), 'd' (days), 'M' (months) and 'y' (years).
 ## scrub_queue_depth
 - Type: integer
 - Default: 1
 - Can be changed online: yes
 Number of parallel scrubbing operations per one OSD.
 ## scrub_sleep
 - Type: milliseconds
 - Default: 0
 - Can be changed online: yes
 Additional interval between two consecutive scrubbing operations on one OSD.
 Can be used to slow down scrubbing if it affects user load too much.
 ## scrub_list_limit
 - Type: integer
 - Default: 1000
 - Can be changed online: yes
 Number of objects to list in one listing operation during scrub.
 ## scrub_find_best
 - Type: boolean
 - Default: true
 - Can be changed online: yes
 Find and automatically restore best versions of objects with unmatched
 copies. In replicated setups, the best version is the version with most
 matching replicas. In EC setups, the best version is the subset of data
 and parity chunks without mismatches.
 The hypothetical situation where you might want to disable it is when
 you have 3 replicas and you are paranoid that 2 HDDs out of 3 may silently
 corrupt an object in the same way (for example, zero it out) and only
 1 HDD will remain good. In this case disabling scrub_find_best may help
 you to recover the data! See also scrub_ec_max_bruteforce below.
 ## scrub_ec_max_bruteforce
 - Type: integer
 - Default: 100
 - Can be changed online: yes
 Vitastor can locate corrupted chunks in EC setups with more than 1 parity
 chunk by brute-forcing all possible error locations. This configuration
 value limits the maximum number of checked combinations. You can try to
 increase it if you have EC N+K setup with N and K large enough for
 combination count `C(N+K-1, K-1) = (N+K-1)! / (K-1)! / N!` to be greater
 than the default 100.
 If there are too many possible combinations or if multiple combinations give
 correct results then objects are marked inconsistent and aren't recovered
 automatically.
 In replicated setups bruteforcing isn't needed, Vitastor just assumes that
 the variant with most available equal copies is correct. For example, if
 you have 3 replicas and 1 of them differs, this one is considered to be
 corrupted. But if there is no "best" version with more copies than all
 others have then the object is also marked as inconsistent.
 ## recovery_tune_interval
 - Type: seconds
 - Default: 1
 - Can be changed online: yes
 Interval at which OSD re-considers client and recovery load and automatically
 adjusts [recovery_sleep_us](#recovery_sleep_us). Recovery auto-tuning is
 disabled if recovery_tune_interval is set to 0.
 Auto-tuning targets utilization. Utilization is a measure of load and is
 equal to the product of iops and average latency (so it may be greater
 than 1). You set "low" and "high" client utilization thresholds and two
 corresponding target recovery utilization levels. OSD calculates desired
 recovery utilization from client utilization using linear interpolation
 and auto-tunes recovery operation delay to make actual recovery utilization
 match desired.
 This allows to reduce recovery/rebalance impact on client operations. It is
 of course impossible to remove it completely, but it should become adequate.
 In some tests rebalance could earlier drop client write speed from 1.5 GB/s
 to 50-100 MB/s, with default auto-tuning settings it now only reduces
 to ~1 GB/s.
 ## recovery_tune_util_low
 - Type: number
 - Default: 0.1
 - Can be changed online: yes
 Desired recovery/rebalance utilization when client load is high, i.e. when
 it is at or above recovery_tune_client_util_high.
 ## recovery_tune_util_high
 - Type: number
 - Default: 1
 - Can be changed online: yes
 Desired recovery/rebalance utilization when client load is low, i.e. when
 it is at or below recovery_tune_client_util_low.
 ## recovery_tune_client_util_low
 - Type: number
 - Default: 0
 - Can be changed online: yes
 Client utilization considered "low".
 ## recovery_tune_client_util_high
 - Type: number
 - Default: 0.5
 - Can be changed online: yes
 Client utilization considered "high".
 ## recovery_tune_agg_interval
 - Type: integer
 - Default: 10
 - Can be changed online: yes
 The number of last auto-tuning iterations to use for calculating the
 delay as average. Lower values result in quicker response to client
 load change, higher values result in more stable delay. Default value of 10
 is usually fine.
 ## recovery_tune_sleep_min_us
 - Type: microseconds
 - Default: 10
 - Can be changed online: yes
 Minimum possible value for auto-tuned recovery_sleep_us. Lower values
 are changed to 0.
 ## recovery_tune_sleep_cutoff_us
 - Type: microseconds
 - Default: 10000000
 - Can be changed online: yes
 Maximum possible value for auto-tuned recovery_sleep_us. Higher values
 are treated as outliers and ignored in aggregation.
--- a/docs/config/osd.ru.md
+++ b/docs/config/osd.ru.md
@ -8,11 +8,9 @@
 Данные параметры используются только OSD, но, в отличие от дисковых параметров,
 не фиксируются в момент инициализации дисков OSD и могут быть изменены в любой
-момент с помощью перезапуска OSD, а некоторые и без перезапуска, с помощью
+момент с перезапуском OSD.
 изменения конфигурации в etcd.
 - [etcd_report_interval](#etcd_report_interval)
 - [etcd_stats_interval](#etcd_stats_interval)
 - [run_primary](#run_primary)
 - [osd_network](#osd_network)
 - [bind_address](#bind_address)
@ -20,7 +18,6 @@
 - [autosync_interval](#autosync_interval)
 - [autosync_writes](#autosync_writes)
 - [recovery_queue_depth](#recovery_queue_depth)
 - [recovery_sleep_us](#recovery_sleep_us)
 - [recovery_pg_switch](#recovery_pg_switch)
 - [recovery_sync_batch](#recovery_sync_batch)
 - [readonly](#readonly)
@ -34,9 +31,6 @@
 - [max_flusher_count](#max_flusher_count)
 - [inmemory_metadata](#inmemory_metadata)
 - [inmemory_journal](#inmemory_journal)
 - [data_io](#data_io)
 - [meta_io](#meta_io)
 - [journal_io](#journal_io)
 - [journal_sector_buffer_count](#journal_sector_buffer_count)
 - [journal_no_same_sector_overwrites](#journal_no_same_sector_overwrites)
 - [throttle_small_writes](#throttle_small_writes)
@ -45,43 +39,17 @@
 - [throttle_target_parallelism](#throttle_target_parallelism)
 - [throttle_threshold_us](#throttle_threshold_us)
 - [osd_memlock](#osd_memlock)
 - [auto_scrub](#auto_scrub)
 - [no_scrub](#no_scrub)
 - [scrub_interval](#scrub_interval)
 - [scrub_queue_depth](#scrub_queue_depth)
 - [scrub_sleep](#scrub_sleep)
 - [scrub_list_limit](#scrub_list_limit)
 - [scrub_find_best](#scrub_find_best)
 - [scrub_ec_max_bruteforce](#scrub_ec_max_bruteforce)
 - [recovery_tune_interval](#recovery_tune_interval)
 - [recovery_tune_util_low](#recovery_tune_util_low)
 - [recovery_tune_util_high](#recovery_tune_util_high)
 - [recovery_tune_client_util_low](#recovery_tune_client_util_low)
 - [recovery_tune_client_util_high](#recovery_tune_client_util_high)
 - [recovery_tune_agg_interval](#recovery_tune_agg_interval)
 - [recovery_tune_sleep_min_us](#recovery_tune_sleep_min_us)
 - [recovery_tune_sleep_cutoff_us](#recovery_tune_sleep_cutoff_us)
 ## etcd_report_interval
 - Тип: секунды
 - Значение по умолчанию: 5
-Интервал, с которым OSD сообщает о том, что жив, в etcd. Значение параметра
+Интервал, с которым OSD обновляет своё состояние в etcd. Значение параметра
-влияет на время резервации (lease) OSD и поэтому - на скорость переключения
+влияет на время резервации (lease) OSD и поэтому на скорость переключения
 при падении OSD. Время lease равняется значению этого параметра плюс
 max_etcd_attempts * etcd_quick_timeout.
 ## etcd_stats_interval
 - Тип: секунды
 - Значение по умолчанию: 30
 Интервал, с которым OSD обновляет свою статистику в etcd. Сильно влияет на
 создаваемую нагрузку на etcd, потому что статистика содержит по ключу на
 каждый OSD и на каждую PG. В то же время низкий интервал делает
 статистику, печатаемую `vitastor-cli`, отзывчивей.
 ## run_primary
 - Тип: булево (да/нет)
@ -125,7 +93,6 @@ RUNNING), подходящий под заданную маску. Также н
 - Тип: секунды
 - Значение по умолчанию: 5
 - Можно менять на лету: да
 Временной интервал отправки автоматических fsync-ов (операций очистки кэша)
 каждым OSD для случая, когда режим immediate_commit отключён. fsync-и нужны
@ -138,7 +105,6 @@ OSD, чтобы успевать очищать журнал - без них OSD
 - Тип: целое число
 - Значение по умолчанию: 128
 - Можно менять на лету: да
 Аналогично autosync_interval, но задаёт не временной интервал, а
 максимальное количество незафиксированных операций записи перед
@ -147,31 +113,17 @@ OSD, чтобы успевать очищать журнал - без них OSD
 ## recovery_queue_depth
 - Тип: целое число
- Значение по умолчанию: 1
+- Значение по умолчанию: 4
 - Можно менять на лету: да
-Максимальное число параллельных операций восстановления, инициируемых одним
+Максимальное число операций восстановления на одном первичном OSD в любой
-OSD в любой момент времени. Имейте в виду, что каждый OSD обычно работает с
+момент времени. На данный момент единственный параметр, который можно менять
-многими другими OSD, так что на практике параллелизм восстановления больше,
+для ускорения или замедления восстановления и перебалансировки данных, но
-чем просто recovery_queue_depth. Увеличение значения этого параметра может
+в планах реализация других параметров.
 ускорить восстановление если [автотюнинг скорости](#recovery_tune_interval)
 разрешает это или если он отключён.
 ## recovery_sleep_us
 - Тип: микросекунды
 - Значение по умолчанию: 0
 - Можно менять на лету: да
 Delay for all recovery- and rebalance- related operations. If non-zero,
 such operations are artificially slowed down to reduce the impact on
 client I/O.
 ## recovery_pg_switch
 - Тип: целое число
 - Значение по умолчанию: 128
 - Можно менять на лету: да
 Число операций восстановления перед переключением на восстановление другой PG.
 Идея заключается в том, чтобы восстанавливать все PG одновременно для более
@ -183,7 +135,6 @@ client I/O.
 - Тип: целое число
 - Значение по умолчанию: 16
 - Можно менять на лету: да
 Максимальное число операций восстановления перед дополнительным fsync.
@ -199,7 +150,6 @@ client I/O.
 - Тип: булево (да/нет)
 - Значение по умолчанию: false
 - Можно менять на лету: да
 Отключить автоматическое фоновое восстановление объектов. Обратите внимание,
 что эта опция не отключает восстановление объектов, происходящее при
@ -210,7 +160,6 @@ OSD.
 - Тип: булево (да/нет)
 - Значение по умолчанию: false
 - Можно менять на лету: да
 Отключить фоновое перемещение объектов между разными OSD. Отключение
 означает, что PG, находящиеся в состоянии `has_misplaced`, будут оставлены
@ -220,7 +169,6 @@ OSD.
 - Тип: секунды
 - Значение по умолчанию: 3
 - Можно менять на лету: да
 Временной интервал, с которым OSD печатают простую человекочитаемую
 статистику выполнения операций в стандартный вывод.
@ -229,7 +177,6 @@ OSD.
 - Тип: секунды
 - Значение по умолчанию: 10
 - Можно менять на лету: да
 Временной интервал, с которым OSD выводят в стандартный вывод список
 медленных или зависших операций, если таковые имеются. Также время, при
@ -239,7 +186,6 @@ OSD.
 - Тип: секунды
 - Значение по умолчанию: 60
 - Можно менять на лету: да
 Число секунд, через которое удалённые инод удаляется и из статистики OSD.
@ -247,7 +193,6 @@ OSD.
 - Тип: целое число
 - Значение по умолчанию: 128
 - Можно менять на лету: да
 Максимальное число одновременных клиентских операций записи на один OSD.
 Операции, превышающие этот лимит, не исполняются сразу, а сохраняются во
@ -257,7 +202,6 @@ OSD.
 - Тип: целое число
 - Значение по умолчанию: 1
 - Можно менять на лету: да
 Flusher - это микро-поток (корутина), которая копирует данные из журнала в
 основную область устройства данных. Их число настраивается динамически между
@ -267,7 +211,6 @@ Flusher - это микро-поток (корутина), которая коп
 - Тип: целое число
 - Значение по умолчанию: 256
 - Можно менять на лету: да
 Максимальное число микро-потоков очистки журнала (см. выше min_flusher_count).
@ -298,63 +241,6 @@ Flusher - это микро-поток (корутина), которая коп
 параметра может оказаться полезным для гибридных OSD (HDD+SSD) с большими
 журналами, расположенными на быстром по сравнению с HDD устройстве.
 ## data_io
 - Тип: строка
 - Значение по умолчанию: direct
 Режим ввода-вывода для *данных*. Одно из значений "direct", "cached" или
 "directsync", означающих O_DIRECT, O_SYNC и O_DIRECT|O_SYNC, соответственно.
 Выберите "cached", чтобы использовать системный кэш Linux (page cache) при
 чтении и записи. Это может улучшить скорость чтения горячих данных с
 относительно медленных дисков - HDD и, возможно, SATA SSD - но немного
 снижает производительность записи для быстрых дисков, так как кэш сам по
 себе тоже добавляет накладные расходы.
 Выберите "directsync", если хотите задействовать
 [immediate_commit](layout-cluster.ru.md#immediate_commit) (требующий
 включенияd disable_data_fsync) на дисках с неотключаемым кэшем. Пример таких
 дисков - Intel Optane. При этом также стоит иметь в виду, что *некоторые*
 настольные SSD (например, HP EX950) игнорируют флаг O_SYNC, делая отключение
 fsync небезопасным даже с режимом "directsync".
 ## meta_io
 - Тип: строка
 - Значение по умолчанию: direct
 Режим ввода-вывода для *метаданных*. Одно из значений "direct", "cached" или
 "directsync".
 "cached" может улучшить скорость чтения, если:
 1. у вас медленные диски (HDD, SATA SSD)
 2. контрольные суммы включены
 3. параметр [inmemory_metadata](#inmemory_metadata) отключён.
 При этих условиях блоки метаданных читаются с диска при каждом запросе чтения
 для проверки контрольных сумм и их кэширование может снизить дополнительную
 нагрузку на диск. Без (3) метаданные никогда не читаются с диска после
 запуска OSD, а без (2) блоки метаданных читаются только при сбросе журнала.
 Если одно и то же устройство используется для данных и метаданных, режим
 ввода-вывода метаданных по умолчанию устанавливается равным [data_io](#data_io).
 ## journal_io
 - Тип: строка
 - Значение по умолчанию: direct
 Режим ввода-вывода для *журнала*. Одно из значений "direct", "cached" или
 "directsync".
 Здесь "cached" может улучшить скорость чтения только недавно записанных
 данных и только если параметр [inmemory_journal](#inmemory_journal)
 отключён.
 Если одно и то же устройство используется для метаданных и журнала,
 режим ввода-вывода журнала по умолчанию устанавливается равным
 [meta_io](#meta_io).
 ## journal_sector_buffer_count
 - Тип: целое число
@ -384,7 +270,6 @@ fsync небезопасным даже с режимом "directsync".
 - Тип: булево (да/нет)
 - Значение по умолчанию: false
 - Можно менять на лету: да
 Разрешить мягкое ограничение скорости журналируемой записи. Полезно для
 гибридных OSD с быстрыми устройствами метаданных и медленными устройствами
@ -403,7 +288,6 @@ fsync небезопасным даже с режимом "directsync".
 - Тип: целое число
 - Значение по умолчанию: 100
 - Можно менять на лету: да
 Расчётное максимальное число ограничиваемых операций в секунду при условии
 отсутствия свободного места в журнале. Устанавливайте приблизительно равным
@ -414,7 +298,6 @@ fsync небезопасным даже с режимом "directsync".
 - Тип: целое число
 - Значение по умолчанию: 100
 - Можно менять на лету: да
 Расчётный максимальный размер в МБ/с ограничиваемых операций в секунду при
 условии отсутствия свободного места в журнале. Устанавливайте приблизительно
@ -425,7 +308,6 @@ fsync небезопасным даже с режимом "directsync".
 - Тип: целое число
 - Значение по умолчанию: 1
 - Можно менять на лету: да
 Расчётный максимальный параллелизм ограничиваемых операций в секунду при
 условии отсутствия свободного места в журнале. Устанавливайте приблизительно
@ -436,7 +318,6 @@ fsync небезопасным даже с режимом "directsync".
 - Тип: микросекунды
 - Значение по умолчанию: 50
 - Можно менять на лету: да
 Минимальная применимая к ограничиваемым операциям задержка. Обычно не
 требует изменений.
@ -446,203 +327,4 @@ fsync небезопасным даже с режимом "directsync".
 - Тип: булево (да/нет)
 - Значение по умолчанию: false
-Блокировать всю память OSD с помощью mlockall, чтобы запретить её выгрузку
+Блокировать всю память OSD с помощью mlockall, чтобы запретить её выгрузку в пространство подкачки. Требует достаточного значения ulimit -l (лимита заблокированной памяти).
 в пространство подкачки. Требует достаточного значения ulimit -l (лимита
 заблокированной памяти).
 ## auto_scrub
 - Тип: булево (да/нет)
 - Значение по умолчанию: false
 - Можно менять на лету: да
 Скраб - процесс фоновой проверки копий данных, предназначенный, чтобы
 находить и исправлять повреждённые блоки. По умолчанию эти проверки ещё не
 запускаются автоматически, так как являются новой функцией. Чтобы включить
 автоматическое планирование скрабов, установите данный параметр в true.
 Включённый параметр заставляет OSD автоматически планировать фоновую
 проверку чистых PG раз в `scrub_interval` (см. ниже). Вы также можете
 запустить или запланировать проверку вручную, установив значение ключа JSON
 `next_scrub` внутри ключей etcd `/pg/history/...` в UNIX-время следующей
 желаемой проверки.
 ## no_scrub
 - Тип: булево (да/нет)
 - Значение по умолчанию: false
 - Можно менять на лету: да
 Временно отключить и остановить запущенные скрабы.
 ## scrub_interval
 - Тип: строка
 - Значение по умолчанию: 30d
 - Можно менять на лету: да
 Интервал автоматической фоновой проверки по умолчанию для всех пулов.
 Значения без указанной единицы измерения считаются в секундах, допустимые
 символы единиц измерения в конце: 's' (секунды),
 'm' (минуты), 'h' (часы), 'd' (дни), 'M' (месяца) или 'y' (годы).
 ## scrub_queue_depth
 - Тип: целое число
 - Значение по умолчанию: 1
 - Можно менять на лету: да
 Число параллельных операций фоновой проверки на один OSD.
 ## scrub_sleep
 - Тип: миллисекунды
 - Значение по умолчанию: 0
 - Можно менять на лету: да
 Дополнительный интервал ожидания после фоновой проверки каждого объекта на
 одном OSD. Может использоваться для замедления скраба, если он слишком
 сильно влияет на пользовательскую нагрузку.
 ## scrub_list_limit
 - Тип: целое число
 - Значение по умолчанию: 1000
 - Можно менять на лету: да
 Размер загружаемых за одну операцию списков объектов в процессе фоновой
 проверки.
 ## scrub_find_best
 - Тип: булево (да/нет)
 - Значение по умолчанию: true
 - Можно менять на лету: да
 Находить и автоматически восстанавливать "лучшие версии" объектов с
 несовпадающими копиями/частями. При использовании репликации "лучшая"
 версия - версия, доступная в большем числе экземпляров, чем другие. При
 использовании кодов коррекции ошибок "лучшая" версия - это подмножество
 частей данных и чётности, полностью соответствующих друг другу.
 Гипотетическая ситуация, в которой вы можете захотеть отключить этот
 поиск - это если у вас 3 реплики и вы боитесь, что 2 диска из 3 могут
 незаметно и одинаково повредить данные одного и того же объекта, например,
 занулив его, и только 1 диск останется неповреждённым. В этой ситуации
 отключение этого параметра поможет вам восстановить данные! Смотрите также
 описание следующего параметра - scrub_ec_max_bruteforce.
 ## scrub_ec_max_bruteforce
 - Тип: целое число
 - Значение по умолчанию: 100
 - Можно менять на лету: да
 Vitastor старается определить повреждённые части объектов при использовании
 EC (кодов коррекции ошибок) с более, чем 1 диском чётности, путём перебора
 всех возможных комбинаций ошибочных частей. Данное значение конфигурации
 ограничивает число перебираемых комбинаций. Вы можете попробовать поднять
 его, если используете схему кодирования EC N+K с N и K, достаточно большими
 для того, чтобы число сочетаний `C(N+K-1, K-1) = (N+K-1)! / (K-1)! / N!`
 было больше, чем стандартное значение 100.
 Если возможных комбинаций слишком много или если корректная комбинаций не
 определяется однозначно, объекты помечаются неконсистентными (inconsistent)
 и не восстанавливаются автоматически.
 При использовании репликации перебор не нужен, Vitastor просто предполагает,
 что вариант объекта с наибольшим количеством одинаковых копий корректен.
 Например, если вы используете 3 реплики и 1 из них отличается, эта 1 копия
 считается некорректной. Однако, если "лучшую" версию с числом доступных
 копий большим, чем у всех других версий, найти невозможно, то объект тоже
 маркируется неконсистентным.
 ## recovery_tune_interval
 - Тип: секунды
 - Значение по умолчанию: 1
 - Можно менять на лету: да
 Интервал, с которым OSD пересматривает клиентскую нагрузку и нагрузку
 восстановления и автоматически подстраивает [recovery_sleep_us](#recovery_sleep_us).
 Автотюнинг (автоподстройка) отключается, если recovery_tune_interval
 устанавливается в значение 0.
 Автотюнинг регулирует утилизацию. Утилизация является мерой нагрузки
 и равна произведению числа операций в секунду и средней задержки
 (то есть, она может быть выше 1). Вы задаёте два уровня клиентской
 утилизации - "низкий" и "высокий" (low и high) и два соответствующих
 целевых уровня утилизации операциями восстановления. OSD рассчитывает
 желаемый уровень утилизации восстановления линейной интерполяцией от
 клиентской утилизации и подстраивает задержку операций восстановления
 так, чтобы фактическая утилизация восстановления совпадала с желаемой.
 Это позволяет снизить влияние восстановления и ребаланса на клиентские
 операции. Конечно, невозможно исключить такое влияние полностью, но оно
 должно становиться адекватнее. В некоторых тестах перебалансировка могла
 снижать клиентскую скорость записи с 1.5 ГБ/с до 50-100 МБ/с, а теперь, с
 настройками автотюнинга по умолчанию, она снижается только до ~1 ГБ/с.
 ## recovery_tune_util_low
 - Тип: число
 - Значение по умолчанию: 0.1
 - Можно менять на лету: да
 Желаемая утилизация восстановления в моменты, когда клиентская нагрузка
 высокая, то есть, находится на уровне или выше recovery_tune_client_util_high.
 ## recovery_tune_util_high
 - Тип: число
 - Значение по умолчанию: 1
 - Можно менять на лету: да
 Желаемая утилизация восстановления в моменты, когда клиентская нагрузка
 низкая, то есть, находится на уровне или ниже recovery_tune_client_util_low.
 ## recovery_tune_client_util_low
 - Тип: число
 - Значение по умолчанию: 0
 - Можно менять на лету: да
 Клиентская утилизация, которая считается "низкой".
 ## recovery_tune_client_util_high
 - Тип: число
 - Значение по умолчанию: 0.5
 - Можно менять на лету: да
 Клиентская утилизация, которая считается "высокой".
 ## recovery_tune_agg_interval
 - Тип: целое число
 - Значение по умолчанию: 10
 - Можно менять на лету: да
 Число последних итераций автоподстройки для расчёта задержки как среднего
 значения. Меньшие значения параметра ускоряют отклик на изменение нагрузки,
 большие значения делают задержку стабильнее. Значение по умолчанию 10
 обычно нормальное и не требует изменений.
 ## recovery_tune_sleep_min_us
 - Тип: микросекунды
 - Значение по умолчанию: 10
 - Можно менять на лету: да
 Минимальное возможное значение авто-подстроенного recovery_sleep_us.
 Меньшие значения заменяются на 0.
 ## recovery_tune_sleep_cutoff_us
 - Тип: микросекунды
 - Значение по умолчанию: 10000000
 - Можно менять на лету: да
 Максимальное возможное значение авто-подстроенного recovery_sleep_us.
 Большие значения считаются случайными выбросами и игнорируются в
 усреднении.
--- a/docs/config/pool.en.md
+++ b/docs/config/pool.en.md
@ -40,7 +40,6 @@ Parameters:
 - [root_node](#root_node)
 - [osd_tags](#osd_tags)
 - [primary_affinity_tags](#primary_affinity_tags)
 - [scrub_interval](#scrub_interval)
 Examples:
@ -205,8 +204,9 @@ This parameter usually doesn't require to be changed.
 - Default: 131072
 Block size for this pool. The value from /vitastor/config/global is used when
-unspecified. Only OSDs with matching block_size are used for each pool. If you
+unspecified. If your cluster has OSDs with different block sizes then pool must
-want to further restrict OSDs for the pool, use [osd_tags](#osd_tags).
+be restricted by [osd_tags](#osd_tags) to only include OSDs with matching block
 size.
 Read more about this parameter in [Cluster-Wide Disk Layout Parameters](layout-cluster.en.md#block_size).
@ -215,9 +215,10 @@ Read more about this parameter in [Cluster-Wide Disk Layout Parameters](layout-c
 - Type: integer
 - Default: 4096
-"Sector" size of virtual disks in this pool. The value from /vitastor/config/global
+"Sector" size of virtual disks in this pool. The value from
-is used when unspecified. Similarly to block_size, only OSDs with matching
+/vitastor/config/global is used when unspecified. Similar to block_size, the
-bitmap_granularity are used for each pool.
+pool must be restricted by [osd_tags](#osd_tags) to only include OSDs with
 matching bitmap_granularity.
 Read more about this parameter in [Cluster-Wide Disk Layout Parameters](layout-cluster.en.md#bitmap_granularity).
@ -227,11 +228,10 @@ Read more about this parameter in [Cluster-Wide Disk Layout Parameters](layout-c
 - Default: none
 Immediate commit setting for this pool. The value from /vitastor/config/global
-is used when unspecified. Similarly to block_size, only OSDs with compatible
+is used when unspecified. Similar to block_size, the pool must be restricted by
-bitmap_granularity are used for each pool. "Compatible" means that a pool with
+[osd_tags](#osd_tags) to only include OSDs with compatible immediate_commit.
-non-immediate commit will use OSDs with immediate commit enabled, but not vice
+Compatible means that a pool with non-immediate commit will work with OSDs with
-versa. I.e., pools with "none" use all OSDs, pools with "small" only use OSDs
+immediate commit enabled, but not vice versa.
 with "all" or "small", and pools with "all" only use OSDs with "all".
 Read more about this parameter in [Cluster-Wide Disk Layout Parameters](layout-cluster.en.md#immediate_commit).
@ -272,13 +272,6 @@ Specifies OSD tags to prefer putting primary OSDs in this pool to.
 Note that for EC/XOR pools Vitastor always prefers to put primary OSD on one
 of the OSDs containing a data chunk for a PG.
 ## scrub_interval
 - Type: time interval (number + unit s/m/h/d/M/y)
 Automatic scrubbing interval for this pool. Overrides
 [global scrub_interval setting](osd.en.md#scrub_interval).
 # Examples
 ## Replicated pool
--- a/docs/config/pool.ru.md
+++ b/docs/config/pool.ru.md
@ -39,7 +39,6 @@
 - [root_node](#root_node)
 - [osd_tags](#osd_tags)
 - [primary_affinity_tags](#primary_affinity_tags)
 - [scrub_interval](#scrub_interval)
 Примеры:
@ -208,9 +207,8 @@ PG в Vitastor эферемерны, то есть вы можете менят
 Размер блока для данного пула. Если не задан, используется значение из
 /vitastor/config/global. Если в вашем кластере есть OSD с разными размерами
-блока, пул будет использовать только OSD с размером блока, равным размеру блока
+блока, пул должен быть ограничен только OSD, блок которых равен блоку пула,
-пула. Если вы хотите сильнее ограничить набор используемых для пула OSD -
+с помощью [osd_tags](#osd_tags).
 используйте [osd_tags](#osd_tags).
 О самом параметре читайте в разделе [Дисковые параметры уровня кластера](layout-cluster.ru.md#block_size).
@ -220,8 +218,9 @@ PG в Vitastor эферемерны, то есть вы можете менят
 - По умолчанию: 4096
 Размер "сектора" виртуальных дисков в данном пуле. Если не задан, используется
-значение из /vitastor/config/global. Аналогично block_size, каждый пул будет
+значение из /vitastor/config/global. Аналогично block_size, пул должен быть
-использовать только OSD с совпадающей с пулом настройкой bitmap_granularity.
+ограничен OSD со значением bitmap_granularity, равным значению пула, с помощью
 [osd_tags](#osd_tags).
 О самом параметре читайте в разделе [Дисковые параметры уровня кластера](layout-cluster.ru.md#bitmap_granularity).
@ -231,13 +230,11 @@ PG в Vitastor эферемерны, то есть вы можете менят
 - По умолчанию: none
 Настройка мгновенного коммита для данного пула. Если не задана, используется
-значение из /vitastor/config/global. Аналогично block_size, каждый пул будет
+значение из /vitastor/config/global. Аналогично block_size, пул должен быть
-использовать только OSD с *совместимыми* настройками immediate_commit.
+ограничен OSD со значением bitmap_granularity, совместимым со значением пула, с
-"Совместимыми" означает, что пул с отключенным мгновенным коммитом будет
+помощью [osd_tags](#osd_tags). Совместимость означает, что пул с отключенным
-использовать OSD с включённым мгновенным коммитом, но не наоборот. То есть,
+мгновенным коммитом может работать на OSD с включённым мгновенным коммитом, но
-пул со значением "none" будет использовать все OSD, пул со "small" будет
+не наоборот.
 использовать OSD с "all" или "small", а пул с "all" будет использовать только
 OSD с "all".
 О самом параметре читайте в разделе [Дисковые параметры уровня кластера](layout-cluster.ru.md#immediate_commit).
@ -279,13 +276,6 @@ OSD с "all".
 для PG этого пула. Имейте в виду, что для EC-пулов Vitastor также всегда
 предпочитает помещать первичный OSD на один из OSD с данными, а не с чётностью.
 ## scrub_interval
 - Тип: временной интервал (число + единица измерения s/m/h/d/M/y)
 Интервал скраба, то есть, автоматической фоновой проверки данных для данного пула.
 Переопределяет [глобальную настройку scrub_interval](osd.ru.md#scrub_interval).
 # Примеры
 ## Реплицированный пул
--- a/docs/config/src/client.en.md
+++ b/docs/config/src/client.en.md
@ -1,4 +0,0 @@
 # Client Parameters
 These parameters apply only to Vitastor clients (QEMU, fio, NBD and so on) and
 affect their interaction with the cluster.
--- a/docs/config/src/client.ru.md
+++ b/docs/config/src/client.ru.md
@ -1,4 +0,0 @@
 # Параметры клиентского кода
 Данные параметры применяются только к клиентам Vitastor (QEMU, fio, NBD и т.п.) и
 затрагивают логику их работы с кластером.
--- a/docs/config/src/client.yml
+++ b/docs/config/src/client.yml
@ -1,168 +0,0 @@
 - name: client_max_dirty_bytes
  type: int
  default: 33554432
  online: true
  info: |
    Without [immediate_commit](layout-cluster.en.md#immediate_commit)=all this parameter sets the limit of "dirty"
    (not committed by fsync) data allowed by the client before forcing an
    additional fsync and committing the data. Also note that the client always
    holds a copy of uncommitted data in memory so this setting also affects
    RAM usage of clients.
  info_ru: |
    При работе без [immediate_commit](layout-cluster.ru.md#immediate_commit)=all - это лимит объёма "грязных" (не
    зафиксированных fsync-ом) данных, при достижении которого клиент будет
    принудительно вызывать fsync и фиксировать данные. Также стоит иметь в виду,
    что в этом случае до момента fsync клиент хранит копию незафиксированных
    данных в памяти, то есть, настройка влияет на потребление памяти клиентами.
 - name: client_max_dirty_ops
  type: int
  default: 1024
  online: true
  info: |
    Same as client_max_dirty_bytes, but instead of total size, limits the number
    of uncommitted write operations.
  info_ru: |
    Аналогично client_max_dirty_bytes, но ограничивает количество
    незафиксированных операций записи вместо их общего объёма.
 - name: client_enable_writeback
  type: bool
  default: false
  online: true
  info: |
    This parameter enables client-side write buffering. This means that write
    requests are accumulated in memory for a short time before being sent to
    a Vitastor cluster which allows to send them in parallel and increase
    performance of some applications. Writes are buffered until client forces
    a flush with fsync() or until the amount of buffered writes exceeds the
    limit.
    Write buffering significantly increases performance of some applications,
    for example, CrystalDiskMark under Windows (LOL :-D), but also any other
    applications if they do writes in one of two non-optimal ways: either if
    they do a lot of small (4 kb or so) sequential writes, or if they do a lot
    of small random writes, but without any parallelism or asynchrony, and also
    without calling fsync().
    With write buffering enabled, you can expect around 22000 T1Q1 random write
    iops in QEMU more or less regardless of the quality of your SSDs, and this
    number is in fact bound by QEMU itself rather than Vitastor (check it
    yourself by adding a "driver=null-co" disk in QEMU). Without write
    buffering, the current record is 9900 iops, but the number is usually
    even lower with non-ideal hardware, for example, it may be 5000 iops.
    Even when this parameter is enabled, write buffering isn't enabled until
    the client explicitly allows it, because enabling it without the client
    being aware of the fact that his writes may be buffered may lead to data
    loss. Because of this, older versions of clients don't support write
    buffering at all, newer versions of the QEMU driver allow write buffering
    only if it's enabled in disk settings with `-blockdev cache.direct=false`,
    and newer versions of FIO only allow write buffering if you don't specify
    `-direct=1`. NBD and NFS drivers allow write buffering by default.
    You can overcome this restriction too with the `client_writeback_allowed`
    parameter, but you shouldn't do that unless you **really** know what you
    are doing.
  info_ru: |
    Данный параметр разрешает включать буферизацию записи в памяти. Буферизация
    означает, что операции записи отправляются на кластер Vitastor не сразу, а
    могут небольшое время накапливаться в памяти и сбрасываться сразу пакетами,
    до тех пор, пока либо не будет превышен лимит неотправленных записей, либо
    пока клиент не вызовет fsync.
    Буферизация значительно повышает производительность некоторых приложений,
    например, CrystalDiskMark в Windows (ха-ха :-D), но также и любых других,
    которые пишут на диск неоптимально: либо последовательно, но мелкими блоками
    (например, по 4 кб), либо случайно, но без параллелизма и без fsync - то
    есть, например, отправляя 128 операций записи в разные места диска, но не
    все сразу с помощью асинхронного I/O, а по одной.
    В QEMU с буферизацией записи можно ожидать показателя примерно 22000
    операций случайной записи в секунду в 1 поток и с глубиной очереди 1 (T1Q1)
    без fsync, почти вне зависимости от того, насколько хороши ваши диски - эта
    цифра упирается в сам QEMU. Без буферизации рекорд пока что - 9900 операций
    в секунду, но на железе похуже может быть и поменьше, например, 5000 операций
    в секунду.
    При этом, даже если данный параметр включён, буферизация не включается, если
    явно не разрешена клиентом, т.к. если клиент не знает, что запросы записи
    буферизуются, это может приводить к потере данных. Поэтому в старых версиях
    клиентских драйверов буферизация записи не включается вообще, в новых
    версиях QEMU-драйвера включается, только если разрешена опцией диска
    `-blockdev cache.direct=false`, а в fio - только если нет опции `-direct=1`.
    В NBD и NFS драйверах буферизация записи разрешена по умолчанию.
    Можно обойти и это ограничение с помощью параметра `client_writeback_allowed`,
    но делать так не надо, если только вы не уверены в том, что делаете, на все
    100%. :-)
 - name: client_max_buffered_bytes
  type: int
  default: 33554432
  online: true
  info: |
    Maximum total size of buffered writes which triggers write-back when reached.
  info_ru: |
    Максимальный общий размер буферизованных записей, при достижении которого
    начинается процесс сброса данных на сервер.
 - name: client_max_buffered_ops
  type: int
  default: 1024
  online: true
  info: |
    Maximum number of buffered writes which triggers write-back when reached.
    Multiple consecutive modified data regions are counted as 1 write here.
  info_ru: |
    Максимальное количество буферизованных записей, при достижении которого
    начинается процесс сброса данных на сервер. При этом несколько
    последовательных изменённых областей здесь считаются 1 записью.
 - name: client_max_writeback_iodepth
  type: int
  default: 256
  online: true
  info: |
    Maximum number of parallel writes when flushing buffered data to the server.
  info_ru: |
    Максимальное число параллельных операций записи при сбросе буферов на сервер.
 - name: nbd_timeout
  type: sec
  default: 300
  online: false
  info: |
    Timeout for I/O operations for [NBD](../usage/nbd.en.md). If an operation
    executes for longer than this timeout, including when your cluster is just
    temporarily down for more than timeout, the NBD device will detach by itself
    (and possibly break the mounted file system).
    You can set timeout to 0 to never detach, but in that case you won't be
    able to remove the kernel device at all if the NBD process dies - you'll have
    to reboot the host.
  info_ru: |
    Таймаут для операций чтения/записи через [NBD](../usage/nbd.ru.md). Если
    операция выполняется дольше таймаута, включая временную недоступность
    кластера на время, большее таймаута, NBD-устройство отключится само собой
    (и, возможно, сломает примонтированную ФС).
    Вы можете установить таймаут в 0, чтобы никогда не отключать устройство по
    таймауту, но в этом случае вы вообще не сможете удалить устройство, если
    процесс NBD умрёт - вам придётся перезагружать сервер.
 - name: nbd_max_devices
  type: int
  default: 64
  online: false
  info: |
    Maximum number of NBD devices in the system. This value is passed as
    `nbds_max` parameter for the nbd kernel module when vitastor-nbd autoloads it.
  info_ru: |
    Максимальное число NBD-устройств в системе. Данное значение передаётся
    модулю ядра nbd как параметр `nbds_max`, когда его загружает vitastor-nbd.
 - name: nbd_max_part
  type: int
  default: 3
  online: false
  info: |
    Maximum number of partitions per NBD device. This value is passed as
    `max_part` parameter for the nbd kernel module when vitastor-nbd autoloads it.
    Note that (nbds_max)*(1+max_part) usually can't exceed 256.
  info_ru: |
    Максимальное число разделов на одном NBD-устройстве. Данное значение передаётся
    модулю ядра nbd как параметр `max_part`, когда его загружает vitastor-nbd.
    Имейте в виду, что (nbds_max)*(1+max_part) обычно не может превышать 256.
--- a/docs/config/src/common.yml
+++ b/docs/config/src/common.yml
@ -11,21 +11,13 @@
 - name: etcd_address
  type: string or array of strings
  type_ru: строка или массив строк
  online: true
  info: |
    etcd connection endpoint(s). Multiple endpoints may be delimited by "," or
    specified in a JSON array `["10.0.115.10:2379/v3","10.0.115.11:2379/v3"]`.
    Note that https is not supported for etcd connections yet.
    etcd connection endpoints can be changed online by updating global
    configuration in etcd itself - this allows to switch the cluster to new
    etcd addresses without downtime.
  info_ru: |
    Адрес(а) подключения к etcd. Несколько адресов могут разделяться запятой
    или указываться в виде JSON-массива `["10.0.115.10:2379/v3","10.0.115.11:2379/v3"]`.
    Адреса подключения к etcd можно поменять на лету, обновив конфигурацию в
    самом etcd - это позволяет переключить кластер на новые etcd без остановки.
 - name: etcd_prefix
  type: string
  default: "/vitastor"
@ -39,6 +31,5 @@
 - name: log_level
  type: int
  default: 0
  online: true
  info: Log level. Raise if you want more verbose output.
  info_ru: Уровень логгирования. Повысьте, если хотите более подробный вывод.
--- a/docs/config/src/include.js
+++ b/docs/config/src/include.js
@ -1,145 +0,0 @@
 #!/usr/bin/nodejs
 const fsp = require('fs').promises;
 run(process.argv).catch(console.error);
 async function run(argv)
 {
    if (argv.length < 3)
    {
        console.log('Markdown preprocessor\nUSAGE: ./include.js file.md');
        return;
    }
    const index_file = await fsp.realpath(argv[2]);
    const re = /(\{\{[\s\S]*?\}\}|\[[^\]]+\]\([^\)]+\)|(?:^|\n)#[^\n]+)/;
    let text = await fsp.readFile(index_file, { encoding: 'utf-8' });
    text = text.split(re);
    let included = {};
    let heading = 0, heading_name = '', m;
    for (let i = 0; i < text.length; i++)
    {
        if (text[i].substr(0, 2) == '{{')
        {
            // Inclusion
            let incfile = text[i].substr(2, text[i].length-4);
            let section = null;
            let indent = heading;
            incfile = incfile.replace(/\s*\|\s*indent\s*=\s*(-?\d+)\s*$/, (m, m1) => { indent = parseInt(m1); return ''; });
            incfile = incfile.replace(/\s*#\s*([^#]+)$/, (m, m1) => { section = m1; return ''; });
            let inc_heading = section;
            incfile = rel2abs(index_file, incfile);
            let inc = await fsp.readFile(incfile, { encoding: 'utf-8' });
            inc = inc.trim().replace(/^[\s\S]+?\n#/, '#'); // remove until the first header
            inc = inc.split(re);
            const indent_str = new Array(indent+1).join('#');
            let section_start = -1, section_end = -1;
            for (let j = 0; j < inc.length; j++)
            {
                if ((m = /^(\n?)(#+\s*)([\s\S]+)$/.exec(inc[j])))
                {
                    if (!inc_heading)
                    {
                        inc_heading = m[3].trim();
                    }
                    if (section)
                    {
                        if (m[3].trim() == section)
                            section_start = j;
                        else if (section_start >= 0)
                        {
                            section_end = j;
                            break;
                        }
                    }
                    inc[j] = m[1] + indent_str + m[2] + m[3];
                }
                else if ((m = /^(\[[^\]]+\]\()([^\)]+)(\))$/.exec(inc[j])) && !/^https?:(\/\/)|^#/.exec(m[2]))
                {
                    const abs_m2 = rel2abs(incfile, m[2]);
                    const rel_m = abs2rel(__filename, abs_m2);
                    if (rel_m.substr(0, 9) == '../../../') // outside docs
                        inc[j] = m[1] + 'https://git.yourcmc.ru/vitalif/vitastor/src/branch/master/'+rel2abs('docs/config/src/include.js', rel_m) + m[3];
                    else
                        inc[j] = m[1] + abs_m2 + m[3];
                }
            }
            if (section)
            {
                inc = section_start >= 0 ? inc.slice(section_start, section_end < 0 ? inc.length : section_end) : [];
            }
            if (inc.length)
            {
                if (!inc_heading)
                    inc_heading = heading_name||'';
                included[incfile+(section ? '#'+section : '')] = '#'+inc_heading.toLowerCase().replace(/\P{L}+/ug, '-').replace(/^-|-$/g, '');
                inc[0] = inc[0].replace(/^\s+/, '');
                inc[inc.length-1] = inc[inc.length-1].replace(/\s+$/, '');
            }
            text.splice(i, 1, ...inc);
            i = i + inc.length - 1;
        }
        else if ((m = /^\n?(#+)\s*([\s\S]+)$/.exec(text[i])))
        {
            // Heading
            heading = m[1].length;
            heading_name = m[2].trim();
        }
    }
    for (let i = 0; i < text.length; i++)
    {
        if ((m = /^(\[[^\]]+\]\()([^\)]+)(\))$/.exec(text[i])) && !/^https?:(\/\/)|^#/.exec(m[2]))
        {
            const p = m[2].indexOf('#');
            if (included[m[2]])
            {
                text[i] = m[1]+included[m[2]]+m[3];
            }
            else if (p >= 0 && included[m[2].substr(0, p)])
            {
                text[i] = m[1]+m[2].substr(p)+m[3];
            }
        }
    }
    console.log(text.join(''));
 }
 function rel2abs(ref, rel)
 {
    rel = [ ...ref.replace(/^(.*)\/[^\/]+$/, '$1').split(/\/+/), ...rel.split(/\/+/) ];
    return killdots(rel).join('/');
 }
 function abs2rel(ref, abs)
 {
    ref = ref.split(/\/+/);
    abs = abs.split(/\/+/);
    while (ref.length > 1 && ref[0] == abs[0])
    {
        ref.shift();
        abs.shift();
    }
    for (let i = 1; i < ref.length; i++)
    {
        abs.unshift('..');
    }
    return killdots(abs).join('/');
 }
 function killdots(rel)
 {
    for (let i = 0; i < rel.length; i++)
    {
        if (rel[i] == '.')
        {
            rel.splice(i, 1);
            i--;
        }
        else if (i >= 1 && rel[i] == '..' && rel[i-1] != '..')
        {
            rel.splice(i-1, 2);
            i -= 2;
        }
    }
    return rel;
 }
--- a/docs/config/src/included.en.md
+++ b/docs/config/src/included.en.md
@ -1,67 +0,0 @@
 # Vitastor
 {{../../../README.md#The Idea}}
 {{../../../README.md#Talks and presentations}}
 {{../../intro/features.en.md}}
 {{../../intro/quickstart.en.md}}
 {{../../intro/architecture.en.md}}
 ## Installation
 {{../../installation/packages.en.md}}
 {{../../installation/proxmox.en.md}}
 {{../../installation/openstack.en.md}}
 {{../../installation/kubernetes.en.md}}
 {{../../installation/source.en.md}}
 {{../../config.en.md|indent=1}}
 {{../../config/common.en.md|indent=2}}
 {{../../config/network.en.md|indent=2}}
 {{../../config/client.en.md|indent=2}}
 {{../../config/layout-cluster.en.md|indent=2}}
 {{../../config/layout-osd.en.md|indent=2}}
 {{../../config/osd.en.md|indent=2}}
 {{../../config/monitor.en.md|indent=2}}
 {{../../config/pool.en.md|indent=2}}
 {{../../config/inode.en.md|indent=2}}
 ## Usage
 {{../../usage/cli.en.md}}
 {{../../usage/disk.en.md}}
 {{../../usage/fio.en.md}}
 {{../../usage/nbd.en.md}}
 {{../../usage/qemu.en.md}}
 {{../../usage/nfs.en.md}}
 ## Performance
 {{../../performance/understanding.en.md}}
 {{../../performance/theoretical.en.md}}
 {{../../performance/comparison1.en.md}}
 {{../../intro/author.en.md|indent=1}}
--- a/docs/config/src/included.ru.md
+++ b/docs/config/src/included.ru.md
@ -1,67 +0,0 @@
 # Vitastor
 {{../../../README-ru.md#Идея|indent=0}}
 {{../../../README-ru.md#Презентации и записи докладов|indent=0}}
 {{../../intro/features.ru.md}}
 {{../../intro/quickstart.ru.md}}
 {{../../intro/architecture.ru.md}}
 ## Установка
 {{../../installation/packages.ru.md}}
 {{../../installation/proxmox.ru.md}}
 {{../../installation/openstack.ru.md}}
 {{../../installation/kubernetes.ru.md}}
 {{../../installation/source.ru.md}}
 {{../../config.ru.md|indent=1}}
 {{../../config/common.ru.md|indent=2}}
 {{../../config/network.ru.md|indent=2}}
 {{../../config/client.ru.md|indent=2}}
 {{../../config/layout-cluster.ru.md|indent=2}}
 {{../../config/layout-osd.ru.md|indent=2}}
 {{../../config/osd.ru.md|indent=2}}
 {{../../config/monitor.ru.md|indent=2}}
 {{../../config/pool.ru.md|indent=2}}
 {{../../config/inode.ru.md|indent=2}}
 ## Использование
 {{../../usage/cli.ru.md}}
 {{../../usage/disk.ru.md}}
 {{../../usage/fio.ru.md}}
 {{../../usage/nbd.ru.md}}
 {{../../usage/qemu.ru.md}}
 {{../../usage/nfs.ru.md}}
 ## Производительность
 {{../../performance/understanding.ru.md}}
 {{../../performance/theoretical.ru.md}}
 {{../../performance/comparison1.ru.md}}
 {{../../intro/author.ru.md|indent=1}}
--- a/docs/config/src/layout-cluster.yml
+++ b/docs/config/src/layout-cluster.yml
@ -7,27 +7,26 @@
    in Vitastor, affects memory usage, write amplification and I/O load
    distribution effectiveness.
-    Recommended default block size is 128 KB for SSD and 1 MB for HDD. In fact,
+    Recommended default block size is 128 KB for SSD and 4 MB for HDD. In fact,
-    it's possible to use 1 MB for SSD too - it will lower memory usage, but
+    it's possible to use 4 MB for SSD too - it will lower memory usage, but
    may increase average WA and reduce linear performance.
    OSD memory usage is roughly (SIZE / BLOCK * 68 bytes) which is roughly
    544 MB per 1 TB of used disk space with the default 128 KB block size.
    With 1 MB it's 8 times lower.
  info_ru: |
    Размер объектов (блоков данных), на которые делятся физические и виртуальные
    диски в Vitastor (в рамках каждого пула). Одна из ключевых на данный момент
    настроек, влияет на потребление памяти, объём избыточной записи (write
    amplification) и эффективность распределения нагрузки по OSD.
-    Рекомендуемые по умолчанию размеры блока - 128 килобайт для SSD и 1 мегабайт
+    Рекомендуемые по умолчанию размеры блока - 128 килобайт для SSD и 4
-    для HDD. В принципе, для SSD можно тоже использовать блок размером 1 мегабайт,
+    мегабайта для HDD. В принципе, для SSD можно тоже использовать 4 мегабайта,
    это понизит использование памяти, но ухудшит распределение нагрузки и в
    среднем увеличит WA.
    Потребление памяти OSD составляет примерно (РАЗМЕР / БЛОК * 68 байт),
    т.е. примерно 544 МБ памяти на 1 ТБ занятого места на диске при
-    стандартном 128 КБ блоке. При 1 МБ блоке памяти нужно в 8 раз меньше.
+    стандартном 128 КБ блоке.
 - name: bitmap_granularity
  type: int
  default: 4096
@ -87,9 +86,8 @@
    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_journal_fsync and disable_meta_fsync, setting it to "all" also requires
-    [disable_meta_fsync](layout-osd.en.yml#disable_meta_fsync), setting it to
+    enabling disable_data_fsync.
    "all" also requires enabling [disable_data_fsync](layout-osd.en.yml#disable_data_fsync).
    TLDR: For optimal performance, set immediate_commit to "all" if you only use
    SSDs with supercapacitor-based power loss protection (nonvolatile
@ -141,9 +139,8 @@
    указано в спецификациях).
    Указание "all" или "small" в настройках / командной строке OSD требует
-    включения [disable_journal_fsync](layout-osd.ru.yml#disable_journal_fsync) и
+    включения disable_journal_fsync и disable_meta_fsync, значение "all" также
-    [disable_meta_fsync](layout-osd.ru.yml#disable_meta_fsync), значение "all"
+    требует включения disable_data_fsync.
    также требует включения [disable_data_fsync](layout-osd.ru.yml#disable_data_fsync).
    Итого, вкратце: для оптимальной производительности установите
    immediate_commit в значение "all", если вы используете в кластере только SSD
--- a/docs/config/src/layout-osd.yml
+++ b/docs/config/src/layout-osd.yml
@ -204,73 +204,3 @@
    Клиентам не обязательно знать про disk_alignment, так что помещать значение
    этого параметра в etcd в /vitastor/config/global не нужно.
 - name: data_csum_type
  type: string
  default: none
  info: |
    Data checksum type to use. May be "crc32c" or "none". Set to "crc32c" to
    enable data checksums.
  info_ru: |
    Тип используемых OSD контрольных сумм данных. Может быть "crc32c" или "none".
    Установите в "crc32c", чтобы включить расчёт и проверку контрольных сумм данных.
    Следует понимать, что контрольные суммы в зависимости от размера блока их
    расчёта либо увеличивают потребление памяти, либо снижают производительность.
    Подробнее смотрите в описании параметра [csum_block_size](#csum_block_size).
 - name: csum_block_size
  type: int
  default: 4096
  info: |
    Checksum calculation block size.
    Must be equal or a multiple of [bitmap_granularity](layout-cluster.en.md#bitmap_granularity)
    (which is usually 4 KB).
    Checksums increase metadata size by 4 bytes per each csum_block_size of data.
    Checksums are always a tradeoff:
    1. You either sacrifice +1 GB RAM per 1 TB of data
    2. Or you raise csum_block_size, for example, to 32k and sacrifice
       50% random write iops due to checksum read-modify-write
    3. Or you turn off [inmemory_metadata](osd.en.md#inmemory_metadata) and
       sacrifice 50% random read iops due to checksum reads
    All-flash clusters usually have enough RAM to use default csum_block_size,
    which uses 1 GB RAM per 1 TB of data. HDD clusters usually don't.
    Thus, recommended setups are:
    1. All-flash, 1 GB RAM per 1 TB data: default (csum_block_size=4k)
    2. All-flash, less RAM: csum_block_size=4k + inmemory_metadata=false
    3. Hybrid HDD+SSD: csum_block_size=4k + inmemory_metadata=false
    4. HDD-only, faster random read: csum_block_size=32k
    5. HDD-only, faster random write: csum_block_size=4k +
       inmemory_metadata=false + meta_io=cached
    See also [meta_io](osd.en.md#meta_io).
  info_ru: |
    Размер блока расчёта контрольных сумм.
    Должен быть равен или кратен [bitmap_granularity](layout-cluster.ru.md#bitmap_granularity)
    (который обычно равен 4 КБ).
    Контрольные суммы увеличивают размер метаданных на 4 байта на каждые
    csum_block_size данных.
    Контрольные суммы - это всегда компромисс:
    1. Вы либо жертвуете потреблением +1 ГБ памяти на 1 ТБ дискового пространства
    2. Либо вы повышаете csum_block_size до, скажем, 32k и жертвуете 50%
       скорости случайной записи из-за цикла чтения-изменения-записи для расчёта
       новых контрольных сумм
    3. Либо вы отключаете [inmemory_metadata](osd.ru.md#inmemory_metadata) и
       жертвуете 50% скорости случайного чтения из-за чтения контрольных сумм
       с диска
    Таким образом, рекомендуются следующие варианты настроек:
    1. All-flash, 1 ГБ памяти на 1 ТБ данных: по умолчанию (csum_block_size=4k)
    2. All-flash, меньше памяти: csum_block_size=4k + inmemory_metadata=false
    3. Гибридные HDD+SSD: csum_block_size=4k + inmemory_metadata=false
    4. Только HDD, быстрее случайное чтение: csum_block_size=32k
    5. Только HDD, быстрее случайная запись: csum_block_size=4k +
       inmemory_metadata=false + meta_io=cached
    Смотрите также [meta_io](osd.ru.md#meta_io).
--- a/docs/config/src/make.js
+++ b/docs/config/src/make.js
@ -14,7 +14,6 @@ const L = {
        toc_config: '[Configuration](../config.en.md)',
        toc_usage: 'Usage',
        toc_performance: 'Performance',
        online: 'Can be changed online: yes',
    },
    ru: {
        Documentation: 'Документация',
@ -29,7 +28,6 @@ const L = {
        toc_config: '[Конфигурация](../config.ru.md)',
        toc_usage: 'Использование',
        toc_performance: 'Производительность',
        online: 'Можно менять на лету: да',
    },
 };
 const types = {
@ -38,7 +36,6 @@ const types = {
        bool: 'boolean',
        int: 'integer',
        sec: 'seconds',
        float: 'number',
        ms: 'milliseconds',
        us: 'microseconds',
    },
@ -47,7 +44,6 @@ const types = {
        bool: 'булево (да/нет)',
        int: 'целое число',
        sec: 'секунды',
        float: 'число',
        ms: 'миллисекунды',
        us: 'микросекунды',
    },
@ -74,8 +70,6 @@ for (const file of params_files)
                out += `- ${L[lang]['Default'] || 'Default'}: ${c.default}\n`;
            if (c.min !== undefined)
                out += `- ${L[lang]['Minimum'] || 'Minimum'}: ${c.min}\n`;
            if (c.online)
                out += `- ${L[lang]['online'] || 'Can be changed online: yes'}\n`;
            out += `\n`+(c["info_"+lang] || c["info"]).replace(/\s+$/, '');
        }
        const head = fs.readFileSync(__dirname+'/'+file+'.'+lang+'.md', { encoding: 'utf-8' });
--- a/docs/config/src/monitor.yml
+++ b/docs/config/src/monitor.yml
@ -1,7 +1,7 @@
 - name: etcd_mon_ttl
  type: sec
-  min: 5
+  min: 10
-  default: 1
+  default: 30
  info: Monitor etcd lease refresh interval in seconds
  info_ru: Интервал обновления etcd резервации (lease) монитором
 - name: etcd_mon_timeout
--- a/docs/config/src/network.yml
+++ b/docs/config/src/network.yml
@ -48,38 +48,19 @@
  type: string
  info: |
    RDMA device name to use for Vitastor OSD communications (for example,
-    "rocep5s0f0"). Now Vitastor supports all adapters, even ones without
+    "rocep5s0f0"). Please note that Vitastor RDMA requires Implicit On-Demand
-    ODP support, like Mellanox ConnectX-3 and non-Mellanox cards.
+    Paging (Implicit ODP) and Scatter/Gather (SG) support from the RDMA device
-
+    to work. For example, Mellanox ConnectX-3 and older adapters don't have
-    Versions up to Vitastor 1.2.0 required ODP which is only present in
+    Implicit ODP, so they're unsupported by Vitastor. Run `ibv_devinfo -v` as
-    Mellanox ConnectX >= 4. See also [rdma_odp](#rdma_odp).
+    root to list available RDMA devices and their features.
    Run `ibv_devinfo -v` as root to list available RDMA devices and their
    features.
    Remember that you also have to configure your network switches if you use
    RoCE/RoCEv2, otherwise you may experience unstable performance. Refer to
    the manual of your network vendor for details about setting up the switch
    for RoCEv2 correctly. Usually it means setting up Lossless Ethernet with
    PFC (Priority Flow Control) and ECN (Explicit Congestion Notification).
  info_ru: |
    Название RDMA-устройства для связи с Vitastor OSD (например, "rocep5s0f0").
-    Сейчас Vitastor поддерживает все модели адаптеров, включая те, у которых
+    Имейте в виду, что поддержка RDMA в Vitastor требует функций устройства
-    нет поддержки ODP, то есть вы можете использовать RDMA с ConnectX-3 и
+    Implicit On-Demand Paging (Implicit ODP) и Scatter/Gather (SG). Например,
-    картами производства не Mellanox.
+    адаптеры Mellanox ConnectX-3 и более старые не поддерживают Implicit ODP и
-
+    потому не поддерживаются в Vitastor. Запустите `ibv_devinfo -v` от имени
-    Версии Vitastor до 1.2.0 включительно требовали ODP, который есть только
+    суперпользователя, чтобы посмотреть список доступных RDMA-устройств, их
-    на Mellanox ConnectX 4 и более новых. См. также [rdma_odp](#rdma_odp).
+    параметры и возможности.
    Запустите `ibv_devinfo -v` от имени суперпользователя, чтобы посмотреть
    список доступных RDMA-устройств, их параметры и возможности.
    Обратите внимание, что если вы используете RoCE/RoCEv2, вам также необходимо
    правильно настроить для него коммутаторы, иначе вы можете столкнуться с
    нестабильной производительностью. Подробную информацию о настройке
    коммутатора для RoCEv2 ищите в документации производителя. Обычно это
    подразумевает настройку сети без потерь на основе PFC (Priority Flow
    Control) и ECN (Explicit Congestion Notification).
 - name: rdma_port_num
  type: int
  default: 1
@ -133,97 +114,42 @@
    так что менять этот параметр обычно не нужно.
 - name: rdma_max_msg
  type: int
-  default: 132096
+  default: 1048576
  info: Maximum size of a single RDMA send or receive operation in bytes.
  info_ru: Максимальный размер одной RDMA-операции отправки или приёма.
 - name: rdma_max_recv
  type: int
  default: 16
  info: |
    Maximum number of RDMA receive buffers per connection (RDMA requires
    preallocated buffers to receive data). Each buffer is `rdma_max_msg` bytes
    in size. So this setting directly affects memory usage: a single Vitastor
    RDMA client uses `rdma_max_recv * rdma_max_msg * OSD_COUNT` bytes of memory.
    Default is roughly 2 MB * number of OSDs.
  info_ru: |
    Максимальное число буферов для RDMA-приёма данных на одно соединение
    (RDMA требует заранее выделенных буферов для приёма данных). Каждый буфер
    имеет размер `rdma_max_msg` байт. Таким образом, настройка прямо влияет на
    потребление памяти - один Vitastor-клиент с RDMA использует
    `rdma_max_recv * rdma_max_msg * ЧИСЛО_OSD` байт памяти, по умолчанию -
    примерно 2 МБ * число OSD.
 - name: rdma_max_send
  type: int
  default: 8
  info: |
-    Maximum number of outstanding RDMA send operations per connection. Should be
+    Maximum number of parallel RDMA receive operations. Note that this number
-    less than `rdma_max_recv` so the receiving side doesn't run out of buffers.
+    of receive buffers `rdma_max_msg` in size are allocated for each client,
-    Doesn't affect memory usage - additional memory isn't allocated for send
+    so this setting actually affects memory usage. This is because RDMA receive
-    operations.
+    operations are (sadly) still not zero-copy in Vitastor. It may be fixed in
    later versions.
  info_ru: |
-    Максимальное число RDMA-операций отправки, отправляемых в очередь одного
+    Максимальное число параллельных RDMA-операций получения данных. Следует
-    соединения. Желательно, чтобы оно было меньше `rdma_max_recv`, чтобы
+    иметь в виду, что данное число буферов размером `rdma_max_msg` выделяется
-    у принимающей стороны в процессе работы не заканчивались буферы на приём.
+    для каждого подключённого клиентского соединения, так что данная настройка
-    Не влияет на потребление памяти - дополнительная память на операции отправки
+    влияет на потребление памяти. Это так потому, что RDMA-приём данных в
-    не выделяется.
+    Vitastor, увы, всё равно не является zero-copy, т.е. всё равно 1 раз
- name: rdma_odp
+    копирует данные в памяти. Данная особенность, возможно, будет исправлена в
-  type: bool
+    более новых версиях Vitastor.
  default: false
  online: false
  info: |
    Use RDMA with On-Demand Paging. ODP is currently only available on Mellanox
    ConnectX-4 and newer adapters. ODP allows to not register memory explicitly
    for RDMA adapter to be able to use it. This, in turn, allows to skip memory
    copying during sending. One would think this should improve performance, but
    **in reality** RDMA performance with ODP is **drastically** worse. Example
    3-node cluster with 8 NVMe in each node and 2*25 GBit/s ConnectX-6 RDMA network
    without ODP pushes 3950000 read iops, but only 239000 iops with ODP...
    This happens because Mellanox ODP implementation seems to be based on
    message retransmissions when the adapter doesn't know about the buffer yet -
    it likely uses standard "RNR retransmissions" (RNR = receiver not ready)
    which is generally slow in RDMA/RoCE networks. Here's a presentation about
    it from ISPASS-2021 conference: https://tkygtr6.github.io/pub/ISPASS21_slides.pdf
    ODP support is retained in the code just in case a good ODP implementation
    appears one day.
  info_ru: |
    Использовать RDMA с On-Demand Paging. ODP - функция, доступная пока что
    исключительно на адаптерах Mellanox ConnectX-4 и более новых. ODP позволяет
    не регистрировать память для её использования RDMA-картой. Благодаря этому
    можно не копировать данные при отправке их в сеть и, казалось бы, это должно
    улучшать производительность - но **по факту** получается так, что
    производительность только ухудшается, причём сильно. Пример - на 3-узловом
    кластере с 8 NVMe в каждом узле и сетью 2*25 Гбит/с на чтение с RDMA без ODP
    удаётся снять 3950000 iops, а с ODP - всего 239000 iops...
    Это происходит из-за того, что реализация ODP у Mellanox неоптимальная и
    основана на повторной передаче сообщений, когда карте не известен буфер -
    вероятно, на стандартных "RNR retransmission" (RNR = receiver not ready).
    А данные повторные передачи в RDMA/RoCE - всегда очень медленная штука.
    Презентация на эту тему с конференции ISPASS-2021: https://tkygtr6.github.io/pub/ISPASS21_slides.pdf
    Возможность использования ODP сохранена в коде на случай, если вдруг в один
    прекрасный день появится хорошая реализация ODP.
 - name: peer_connect_interval
  type: sec
  min: 1
  default: 5
  online: true
  info: Interval before attempting to reconnect to an unavailable OSD.
  info_ru: Время ожидания перед повторной попыткой соединиться с недоступным OSD.
 - name: peer_connect_timeout
  type: sec
  min: 1
  default: 5
  online: true
  info: Timeout for OSD connection attempts.
  info_ru: Максимальное время ожидания попытки соединения с OSD.
 - name: osd_idle_timeout
  type: sec
  min: 1
  default: 5
  online: true
  info: |
    OSD connection inactivity time after which clients and other OSDs send
    keepalive requests to check state of the connection.
@ -234,7 +160,6 @@
  type: sec
  min: 1
  default: 5
  online: true
  info: |
    Maximum time to wait for OSD keepalive responses. If an OSD doesn't respond
    within this time, the connection to it is dropped and a reconnection attempt
@ -245,9 +170,8 @@
    повторная попытка соединения.
 - name: up_wait_retry_interval
  type: ms
-  min: 10
+  min: 50
-  default: 50
+  default: 500
  online: true
  info: |
    OSDs respond to clients with a special error code when they receive I/O
    requests for a PG that's not synchronized and started. This parameter sets
@ -261,7 +185,6 @@
 - name: max_etcd_attempts
  type: int
  default: 5
  online: true
  info: |
    Maximum number of attempts for etcd requests which can't be retried
    indefinitely.
@ -271,7 +194,6 @@
 - name: etcd_quick_timeout
  type: ms
  default: 1000
  online: true
  info: |
    Timeout for etcd requests which should complete quickly, like lease refresh.
  info_ru: |
@ -280,7 +202,6 @@
 - name: etcd_slow_timeout
  type: ms
  default: 5000
  online: true
  info: Timeout for etcd requests which are allowed to wait for some time.
  info_ru: |
    Максимальное время выполнения запросов к etcd, для которых не обязательно
@ -288,7 +209,6 @@
 - name: etcd_keepalive_timeout
  type: sec
  default: max(30, etcd_report_interval*2)
  online: true
  info: |
    Timeout for etcd connection HTTP Keep-Alive. Should be higher than
    etcd_report_interval to guarantee that keepalive actually works.
@ -298,9 +218,27 @@
 - name: etcd_ws_keepalive_timeout
  type: sec
  default: 30
  online: true
  info: |
    etcd websocket ping interval required to keep the connection alive and
    detect disconnections quickly.
  info_ru: |
    Интервал проверки живости вебсокет-подключений к etcd.
 - name: client_dirty_limit
  type: int
  default: 33554432
  info: |
    Without immediate_commit=all this parameter sets the limit of "dirty"
    (not committed by fsync) data allowed by the client before forcing an
    additional fsync and committing the data. Also note that the client always
    holds a copy of uncommitted data in memory so this setting also affects
    RAM usage of clients.
    This parameter doesn't affect OSDs themselves.
  info_ru: |
    При работе без immediate_commit=all - это лимит объёма "грязных" (не
    зафиксированных fsync-ом) данных, при достижении которого клиент будет
    принудительно вызывать fsync и фиксировать данные. Также стоит иметь в виду,
    что в этом случае до момента fsync клиент хранит копию незафиксированных
    данных в памяти, то есть, настройка влияет на потребление памяти клиентами.
    Параметр не влияет на сами OSD.
--- a/docs/config/src/osd.en.md
+++ b/docs/config/src/osd.en.md
@ -1,5 +1,4 @@
 # Runtime OSD Parameters
 These parameters only apply to OSDs, are not fixed at the moment of OSD drive
-initialization and can be changed - either with an OSD restart or, for some of
+initialization and can be changed with an OSD restart.
 them, even without restarting by updating configuration in etcd.
--- a/docs/config/src/osd.ru.md
+++ b/docs/config/src/osd.ru.md
@ -2,5 +2,4 @@
 Данные параметры используются только OSD, но, в отличие от дисковых параметров,
 не фиксируются в момент инициализации дисков OSD и могут быть изменены в любой
-момент с помощью перезапуска OSD, а некоторые и без перезапуска, с помощью
+момент с перезапуском OSD.
 изменения конфигурации в etcd.
--- a/docs/config/src/osd.yml
+++ b/docs/config/src/osd.yml
@ -2,28 +2,15 @@
  type: sec
  default: 5
  info: |
-    Interval at which OSDs report their liveness to etcd. Affects OSD lease time
+    Interval at which OSDs report their state to etcd. Affects OSD lease time
    and thus the failover speed. Lease time is equal to this parameter value
    plus max_etcd_attempts * etcd_quick_timeout because it should be guaranteed
    that every OSD always refreshes its lease in time.
  info_ru: |
-    Интервал, с которым OSD сообщает о том, что жив, в etcd. Значение параметра
+    Интервал, с которым OSD обновляет своё состояние в etcd. Значение параметра
-    влияет на время резервации (lease) OSD и поэтому - на скорость переключения
+    влияет на время резервации (lease) OSD и поэтому на скорость переключения
    при падении OSD. Время lease равняется значению этого параметра плюс
    max_etcd_attempts * etcd_quick_timeout.
 - name: etcd_stats_interval
  type: sec
  default: 30
  info: |
    Interval at which OSDs report their statistics to etcd. Highly affects the
    imposed load on etcd, because statistics include a key for every OSD and
    for every PG. At the same time, low statistic intervals make `vitastor-cli`
    statistics more responsive.
  info_ru: |
    Интервал, с которым OSD обновляет свою статистику в etcd. Сильно влияет на
    создаваемую нагрузку на etcd, потому что статистика содержит по ключу на
    каждый OSD и на каждую PG. В то же время низкий интервал делает
    статистику, печатаемую `vitastor-cli`, отзывчивей.
 - name: run_primary
  type: bool
  default: true
@ -79,7 +66,6 @@
 - name: autosync_interval
  type: sec
  default: 5
  online: true
  info: |
    Time interval at which automatic fsyncs/flushes are issued by each OSD when
    the immediate_commit mode if disabled. fsyncs are required because without
@ -97,7 +83,6 @@
 - name: autosync_writes
  type: int
  default: 128
  online: true
  info: |
    Same as autosync_interval, but sets the maximum number of uncommitted write
    operations before issuing an fsync operation internally.
@ -107,33 +92,19 @@
    принудительной отправкой fsync-а.
 - name: recovery_queue_depth
  type: int
-  default: 1
+  default: 4
  online: true
  info: |
-    Maximum recovery and rebalance operations initiated by each OSD in parallel.
+    Maximum recovery operations per one primary OSD at any given moment of time.
-    Note that each OSD talks to a lot of other OSDs so actual number of parallel
+    Currently it's the only parameter available to tune the speed or recovery
-    recovery operations per each OSD is greater than just recovery_queue_depth.
+    and rebalancing, but it's planned to implement more.
    Increasing this parameter can speedup recovery if [auto-tuning](#recovery_tune_interval)
    allows it or if it is disabled.
  info_ru: |
-    Максимальное число параллельных операций восстановления, инициируемых одним
+    Максимальное число операций восстановления на одном первичном OSD в любой
-    OSD в любой момент времени. Имейте в виду, что каждый OSD обычно работает с
+    момент времени. На данный момент единственный параметр, который можно менять
-    многими другими OSD, так что на практике параллелизм восстановления больше,
+    для ускорения или замедления восстановления и перебалансировки данных, но
-    чем просто recovery_queue_depth. Увеличение значения этого параметра может
+    в планах реализация других параметров.
    ускорить восстановление если [автотюнинг скорости](#recovery_tune_interval)
    разрешает это или если он отключён.
 - name: recovery_sleep_us
  type: us
  default: 0
  online: true
  info: |
    Delay for all recovery- and rebalance- related operations. If non-zero,
    such operations are artificially slowed down to reduce the impact on
    client I/O.
 - name: recovery_pg_switch
  type: int
  default: 128
  online: true
  info: |
    Number of recovery operations before switching to recovery of the next PG.
    The idea is to mix all PGs during recovery for more even space and load
@ -148,7 +119,6 @@
 - name: recovery_sync_batch
  type: int
  default: 16
  online: true
  info: Maximum number of recovery operations before issuing an additional fsync.
  info_ru: Максимальное число операций восстановления перед дополнительным fsync.
 - name: readonly
@ -163,7 +133,6 @@
 - name: no_recovery
  type: bool
  default: false
  online: true
  info: |
    Disable automatic background recovery of objects. Note that it doesn't
    affect implicit recovery of objects happening during writes - a write is
@ -176,7 +145,6 @@
 - name: no_rebalance
  type: bool
  default: false
  online: true
  info: |
    Disable background movement of data between different OSDs. Disabling it
    means that PGs in the `has_misplaced` state will be left in it indefinitely.
@ -187,7 +155,6 @@
 - name: print_stats_interval
  type: sec
  default: 3
  online: true
  info: |
    Time interval at which OSDs print simple human-readable operation
    statistics on stdout.
@ -197,7 +164,6 @@
 - name: slow_log_interval
  type: sec
  default: 10
  online: true
  info: |
    Time interval at which OSDs dump slow or stuck operations on stdout, if
    they're any. Also it's the time after which an operation is considered
@ -209,7 +175,6 @@
 - name: inode_vanish_time
  type: sec
  default: 60
  online: true
  info: |
    Number of seconds after which a deleted inode is removed from OSD statistics.
  info_ru: |
@ -217,7 +182,6 @@
 - name: max_write_iodepth
  type: int
  default: 128
  online: true
  info: |
    Parallel client write operation limit per one OSD. Operations that exceed
    this limit are pushed to a temporary queue instead of being executed
@ -229,7 +193,6 @@
 - name: min_flusher_count
  type: int
  default: 1
  online: true
  info: |
    Flusher is a micro-thread that moves data from the journal to the data
    area of the device. Their number is auto-tuned between minimum and maximum.
@ -241,7 +204,6 @@
 - name: max_flusher_count
  type: int
  default: 256
  online: true
  info: |
    Maximum number of journal flushers (see above min_flusher_count).
  info_ru: |
@ -285,96 +247,6 @@
    достаточно 16- или 32-мегабайтного журнала. Однако в теории отключение
    параметра может оказаться полезным для гибридных OSD (HDD+SSD) с большими
    журналами, расположенными на быстром по сравнению с HDD устройстве.
 - name: data_io
  type: string
  default: direct
  info: |
    I/O mode for *data*. One of "direct", "cached" or "directsync". Corresponds
    to O_DIRECT, O_SYNC and O_DIRECT|O_SYNC, respectively.
    Choose "cached" to use Linux page cache. This may improve read performance
    for hot data and slower disks - HDDs and maybe SATA SSDs - but will slightly
    decrease write performance for fast disks because page cache is an overhead
    itself.
    Choose "directsync" to use [immediate_commit](layout-cluster.ru.md#immediate_commit)
    (which requires disable_data_fsync) with drives having write-back cache
    which can't be turned off, for example, Intel Optane. Also note that *some*
    desktop SSDs (for example, HP EX950) may ignore O_SYNC thus making
    disable_data_fsync unsafe even with "directsync".
  info_ru: |
    Режим ввода-вывода для *данных*. Одно из значений "direct", "cached" или
    "directsync", означающих O_DIRECT, O_SYNC и O_DIRECT|O_SYNC, соответственно.
    Выберите "cached", чтобы использовать системный кэш Linux (page cache) при
    чтении и записи. Это может улучшить скорость чтения горячих данных с
    относительно медленных дисков - HDD и, возможно, SATA SSD - но немного
    снижает производительность записи для быстрых дисков, так как кэш сам по
    себе тоже добавляет накладные расходы.
    Выберите "directsync", если хотите задействовать
    [immediate_commit](layout-cluster.ru.md#immediate_commit) (требующий
    включенияd disable_data_fsync) на дисках с неотключаемым кэшем. Пример таких
    дисков - Intel Optane. При этом также стоит иметь в виду, что *некоторые*
    настольные SSD (например, HP EX950) игнорируют флаг O_SYNC, делая отключение
    fsync небезопасным даже с режимом "directsync".
 - name: meta_io
  type: string
  default: direct
  info: |
    I/O mode for *metadata*. One of "direct", "cached" or "directsync".
    "cached" may improve read performance, but only under the following conditions:
    1. your drives are relatively slow (HDD, SATA SSD), and
    2. checksums are enabled, and
    3. [inmemory_metadata](#inmemory_metadata) is disabled.
    Under all these conditions, metadata blocks are read from disk on every
    read request to verify checksums and caching them may reduce this extra
    read load. Without (3) metadata is never read from the disk after starting,
    and without (2) metadata blocks are read from disk only during journal
    flushing.
    "directsync" is the same as above.
    If the same device is used for data and metadata, meta_io by default is set
    to the same value as [data_io](#data_io).
  info_ru: |
    Режим ввода-вывода для *метаданных*. Одно из значений "direct", "cached" или
    "directsync".
    "cached" может улучшить скорость чтения, если:
    1. у вас медленные диски (HDD, SATA SSD)
    2. контрольные суммы включены
    3. параметр [inmemory_metadata](#inmemory_metadata) отключён.
    При этих условиях блоки метаданных читаются с диска при каждом запросе чтения
    для проверки контрольных сумм и их кэширование может снизить дополнительную
    нагрузку на диск. Без (3) метаданные никогда не читаются с диска после
    запуска OSD, а без (2) блоки метаданных читаются только при сбросе журнала.
    Если одно и то же устройство используется для данных и метаданных, режим
    ввода-вывода метаданных по умолчанию устанавливается равным [data_io](#data_io).
 - name: journal_io
  type: string
  default: direct
  info: |
    I/O mode for *journal*. One of "direct", "cached" or "directsync".
    Here, "cached" may only improve read performance for recent writes and
    only if [inmemory_journal](#inmemory_journal) is turned off.
    If the same device is used for metadata and journal, journal_io by default
    is set to the same value as [meta_io](#meta_io).
  info_ru: |
    Режим ввода-вывода для *журнала*. Одно из значений "direct", "cached" или
    "directsync".
    Здесь "cached" может улучшить скорость чтения только недавно записанных
    данных и только если параметр [inmemory_journal](#inmemory_journal)
    отключён.
    Если одно и то же устройство используется для метаданных и журнала,
    режим ввода-вывода журнала по умолчанию устанавливается равным
    [meta_io](#meta_io).
 - name: journal_sector_buffer_count
  type: int
  default: 32
@ -412,7 +284,6 @@
 - name: throttle_small_writes
  type: bool
  default: false
  online: true
  info: |
    Enable soft throttling of small journaled writes. Useful for hybrid OSDs
    with fast journal/metadata devices and slow data devices. The idea is that
@ -441,7 +312,6 @@
 - name: throttle_target_iops
  type: int
  default: 100
  online: true
  info: |
    Target maximum number of throttled operations per second under the condition
    of full journal. Set it to approximate random write iops of your data devices
@ -454,7 +324,6 @@
 - name: throttle_target_mbs
  type: int
  default: 100
  online: true
  info: |
    Target maximum bandwidth in MB/s of throttled operations per second under
    the condition of full journal. Set it to approximate linear write
@ -467,7 +336,6 @@
 - name: throttle_target_parallelism
  type: int
  default: 1
  online: true
  info: |
    Target maximum parallelism of throttled operations under the condition of
    full journal. Set it to approximate internal parallelism of your data
@ -480,7 +348,6 @@
 - name: throttle_threshold_us
  type: us
  default: 50
  online: true
  info: |
    Minimal computed delay to be applied to throttled operations. Usually
    doesn't need to be changed.
@ -490,260 +357,10 @@
 - name: osd_memlock
  type: bool
  default: false
-  info: |
+  info: >
    Lock all OSD memory to prevent it from being unloaded into swap with
    mlockall(). Requires sufficient ulimit -l (max locked memory).
-  info_ru: |
+  info_ru: >
    Блокировать всю память OSD с помощью mlockall, чтобы запретить её выгрузку
    в пространство подкачки. Требует достаточного значения ulimit -l (лимита
    заблокированной памяти).
 - name: auto_scrub
  type: bool
  default: false
  online: true
  info: |
    Data scrubbing is the process of background verification of copies to find
    and repair corrupted blocks. It's not run automatically by default since
    it's a new feature. Set this parameter to true to enable automatic scrubs.
    This parameter makes OSDs automatically schedule data scrubbing of clean PGs
    every `scrub_interval` (see below). You can also start/schedule scrubbing
    manually by setting `next_scrub` JSON key to the desired UNIX time of the
    next scrub in `/pg/history/...` values in etcd.
  info_ru: |
    Скраб - процесс фоновой проверки копий данных, предназначенный, чтобы
    находить и исправлять повреждённые блоки. По умолчанию эти проверки ещё не
    запускаются автоматически, так как являются новой функцией. Чтобы включить
    автоматическое планирование скрабов, установите данный параметр в true.
    Включённый параметр заставляет OSD автоматически планировать фоновую
    проверку чистых PG раз в `scrub_interval` (см. ниже). Вы также можете
    запустить или запланировать проверку вручную, установив значение ключа JSON
    `next_scrub` внутри ключей etcd `/pg/history/...` в UNIX-время следующей
    желаемой проверки.
 - name: no_scrub
  type: bool
  default: false
  online: true
  info: |
    Temporarily disable scrubbing and stop running scrubs.
  info_ru: |
    Временно отключить и остановить запущенные скрабы.
 - name: scrub_interval
  type: string
  default: 30d
  online: true
  info: |
    Default automatic scrubbing interval for all pools. Numbers without suffix
    are treated as seconds, possible unit suffixes include 's' (seconds),
    'm' (minutes), 'h' (hours), 'd' (days), 'M' (months) and 'y' (years).
  info_ru: |
    Интервал автоматической фоновой проверки по умолчанию для всех пулов.
    Значения без указанной единицы измерения считаются в секундах, допустимые
    символы единиц измерения в конце: 's' (секунды),
    'm' (минуты), 'h' (часы), 'd' (дни), 'M' (месяца) или 'y' (годы).
 - name: scrub_queue_depth
  type: int
  default: 1
  online: true
  info: |
    Number of parallel scrubbing operations per one OSD.
  info_ru: |
    Число параллельных операций фоновой проверки на один OSD.
 - name: scrub_sleep
  type: ms
  default: 0
  online: true
  info: |
    Additional interval between two consecutive scrubbing operations on one OSD.
    Can be used to slow down scrubbing if it affects user load too much.
  info_ru: |
    Дополнительный интервал ожидания после фоновой проверки каждого объекта на
    одном OSD. Может использоваться для замедления скраба, если он слишком
    сильно влияет на пользовательскую нагрузку.
 - name: scrub_list_limit
  type: int
  default: 1000
  online: true
  info: |
    Number of objects to list in one listing operation during scrub.
  info_ru: |
    Размер загружаемых за одну операцию списков объектов в процессе фоновой
    проверки.
 - name: scrub_find_best
  type: bool
  default: true
  online: true
  info: |
    Find and automatically restore best versions of objects with unmatched
    copies. In replicated setups, the best version is the version with most
    matching replicas. In EC setups, the best version is the subset of data
    and parity chunks without mismatches.
    The hypothetical situation where you might want to disable it is when
    you have 3 replicas and you are paranoid that 2 HDDs out of 3 may silently
    corrupt an object in the same way (for example, zero it out) and only
    1 HDD will remain good. In this case disabling scrub_find_best may help
    you to recover the data! See also scrub_ec_max_bruteforce below.
  info_ru: |
    Находить и автоматически восстанавливать "лучшие версии" объектов с
    несовпадающими копиями/частями. При использовании репликации "лучшая"
    версия - версия, доступная в большем числе экземпляров, чем другие. При
    использовании кодов коррекции ошибок "лучшая" версия - это подмножество
    частей данных и чётности, полностью соответствующих друг другу.
    Гипотетическая ситуация, в которой вы можете захотеть отключить этот
    поиск - это если у вас 3 реплики и вы боитесь, что 2 диска из 3 могут
    незаметно и одинаково повредить данные одного и того же объекта, например,
    занулив его, и только 1 диск останется неповреждённым. В этой ситуации
    отключение этого параметра поможет вам восстановить данные! Смотрите также
    описание следующего параметра - scrub_ec_max_bruteforce.
 - name: scrub_ec_max_bruteforce
  type: int
  default: 100
  online: true
  info: |
    Vitastor can locate corrupted chunks in EC setups with more than 1 parity
    chunk by brute-forcing all possible error locations. This configuration
    value limits the maximum number of checked combinations. You can try to
    increase it if you have EC N+K setup with N and K large enough for
    combination count `C(N+K-1, K-1) = (N+K-1)! / (K-1)! / N!` to be greater
    than the default 100.
    If there are too many possible combinations or if multiple combinations give
    correct results then objects are marked inconsistent and aren't recovered
    automatically.
    In replicated setups bruteforcing isn't needed, Vitastor just assumes that
    the variant with most available equal copies is correct. For example, if
    you have 3 replicas and 1 of them differs, this one is considered to be
    corrupted. But if there is no "best" version with more copies than all
    others have then the object is also marked as inconsistent.
  info_ru: |
    Vitastor старается определить повреждённые части объектов при использовании
    EC (кодов коррекции ошибок) с более, чем 1 диском чётности, путём перебора
    всех возможных комбинаций ошибочных частей. Данное значение конфигурации
    ограничивает число перебираемых комбинаций. Вы можете попробовать поднять
    его, если используете схему кодирования EC N+K с N и K, достаточно большими
    для того, чтобы число сочетаний `C(N+K-1, K-1) = (N+K-1)! / (K-1)! / N!`
    было больше, чем стандартное значение 100.
    Если возможных комбинаций слишком много или если корректная комбинаций не
    определяется однозначно, объекты помечаются неконсистентными (inconsistent)
    и не восстанавливаются автоматически.
    При использовании репликации перебор не нужен, Vitastor просто предполагает,
    что вариант объекта с наибольшим количеством одинаковых копий корректен.
    Например, если вы используете 3 реплики и 1 из них отличается, эта 1 копия
    считается некорректной. Однако, если "лучшую" версию с числом доступных
    копий большим, чем у всех других версий, найти невозможно, то объект тоже
    маркируется неконсистентным.
 - name: recovery_tune_interval
  type: sec
  default: 1
  online: true
  info: |
    Interval at which OSD re-considers client and recovery load and automatically
    adjusts [recovery_sleep_us](#recovery_sleep_us). Recovery auto-tuning is
    disabled if recovery_tune_interval is set to 0.
    Auto-tuning targets utilization. Utilization is a measure of load and is
    equal to the product of iops and average latency (so it may be greater
    than 1). You set "low" and "high" client utilization thresholds and two
    corresponding target recovery utilization levels. OSD calculates desired
    recovery utilization from client utilization using linear interpolation
    and auto-tunes recovery operation delay to make actual recovery utilization
    match desired.
    This allows to reduce recovery/rebalance impact on client operations. It is
    of course impossible to remove it completely, but it should become adequate.
    In some tests rebalance could earlier drop client write speed from 1.5 GB/s
    to 50-100 MB/s, with default auto-tuning settings it now only reduces
    to ~1 GB/s.
  info_ru: |
    Интервал, с которым OSD пересматривает клиентскую нагрузку и нагрузку
    восстановления и автоматически подстраивает [recovery_sleep_us](#recovery_sleep_us).
    Автотюнинг (автоподстройка) отключается, если recovery_tune_interval
    устанавливается в значение 0.
    Автотюнинг регулирует утилизацию. Утилизация является мерой нагрузки
    и равна произведению числа операций в секунду и средней задержки
    (то есть, она может быть выше 1). Вы задаёте два уровня клиентской
    утилизации - "низкий" и "высокий" (low и high) и два соответствующих
    целевых уровня утилизации операциями восстановления. OSD рассчитывает
    желаемый уровень утилизации восстановления линейной интерполяцией от
    клиентской утилизации и подстраивает задержку операций восстановления
    так, чтобы фактическая утилизация восстановления совпадала с желаемой.
    Это позволяет снизить влияние восстановления и ребаланса на клиентские
    операции. Конечно, невозможно исключить такое влияние полностью, но оно
    должно становиться адекватнее. В некоторых тестах перебалансировка могла
    снижать клиентскую скорость записи с 1.5 ГБ/с до 50-100 МБ/с, а теперь, с
    настройками автотюнинга по умолчанию, она снижается только до ~1 ГБ/с.
 - name: recovery_tune_util_low
  type: float
  default: 0.1
  online: true
  info: |
    Desired recovery/rebalance utilization when client load is high, i.e. when
    it is at or above recovery_tune_client_util_high.
  info_ru: |
    Желаемая утилизация восстановления в моменты, когда клиентская нагрузка
    высокая, то есть, находится на уровне или выше recovery_tune_client_util_high.
 - name: recovery_tune_util_high
  type: float
  default: 1
  online: true
  info: |
    Desired recovery/rebalance utilization when client load is low, i.e. when
    it is at or below recovery_tune_client_util_low.
  info_ru: |
    Желаемая утилизация восстановления в моменты, когда клиентская нагрузка
    низкая, то есть, находится на уровне или ниже recovery_tune_client_util_low.
 - name: recovery_tune_client_util_low
  type: float
  default: 0
  online: true
  info: Client utilization considered "low".
  info_ru: Клиентская утилизация, которая считается "низкой".
 - name: recovery_tune_client_util_high
  type: float
  default: 0.5
  online: true
  info: Client utilization considered "high".
  info_ru: Клиентская утилизация, которая считается "высокой".
 - name: recovery_tune_agg_interval
  type: int
  default: 10
  online: true
  info: |
    The number of last auto-tuning iterations to use for calculating the
    delay as average. Lower values result in quicker response to client
    load change, higher values result in more stable delay. Default value of 10
    is usually fine.
  info_ru: |
    Число последних итераций автоподстройки для расчёта задержки как среднего
    значения. Меньшие значения параметра ускоряют отклик на изменение нагрузки,
    большие значения делают задержку стабильнее. Значение по умолчанию 10
    обычно нормальное и не требует изменений.
 - name: recovery_tune_sleep_min_us
  type: us
  default: 10
  online: true
  info: |
    Minimum possible value for auto-tuned recovery_sleep_us. Lower values
    are changed to 0.
  info_ru: |
    Минимальное возможное значение авто-подстроенного recovery_sleep_us.
    Меньшие значения заменяются на 0.
 - name: recovery_tune_sleep_cutoff_us
  type: us
  default: 10000000
  online: true
  info: |
    Maximum possible value for auto-tuned recovery_sleep_us. Higher values
    are treated as outliers and ignored in aggregation.
  info_ru: |
    Максимальное возможное значение авто-подстроенного recovery_sleep_us.
    Большие значения считаются случайными выбросами и игнорируются в
    усреднении.
--- a/docs/installation/kubernetes.en.md
+++ b/docs/installation/kubernetes.en.md
@ -17,27 +17,4 @@ and apply all `NNN-*.yaml` manifests to your Kubernetes installation:
 for i in ./???-*.yaml; do kubectl apply -f $i; done
 ```
-After that you'll be able to create PersistentVolumes.
+After that you'll be able to create PersistentVolumes. See example in [csi/deploy/example-pvc.yaml](../../csi/deploy/example-pvc.yaml).
 **Important:** For best experience, use Linux kernel at least 5.15 with [VDUSE](../usage/qemu.en.md#vduse)
 kernel modules enabled (vdpa, vduse, virtio-vdpa). If your distribution doesn't
 have them pre-built - build them yourself ([instructions](../usage/qemu.en.md#vduse)),
 I promise it's worth it :-). When VDUSE is unavailable, CSI driver uses [NBD](../usage/nbd.en.md)
 to map Vitastor devices. NBD is slower and prone to timeout issues: if Vitastor
 cluster becomes unresponsible for more than [nbd_timeout](../config/client.en.md#nbd_timeout),
 the NBD device detaches and breaks pods using it.
 ## Features
 Vitastor CSI supports:
 - Kubernetes starting with 1.20 (or 1.17 for older vitastor-csi <= 1.1.0)
 - Filesystem RWO (ReadWriteOnce) volumes. Example: [PVC](../../csi/deploy/example-pvc.yaml), [pod](../../csi/deploy/example-test-pod.yaml)
 - Raw block RWX (ReadWriteMany) volumes. Example: [PVC](../../csi/deploy/example-pvc-block.yaml), [pod](../../csi/deploy/example-test-pod-block.yaml)
 - Volume expansion
 - Volume snapshots. Example: [snapshot class](../../csi/deploy/example-snapshot-class.yaml), [snapshot](../../csi/deploy/example-snapshot.yaml), [clone](../../csi/deploy/example-snapshot-clone.yaml)
 - [VDUSE](../usage/qemu.en.md#vduse) (preferred) and [NBD](../usage/nbd.en.md) device mapping methods
 - Upgrades with VDUSE - new handler processes are restarted when CSI pods are restarted themselves
 - VDUSE daemon auto-restart - handler processes are automatically restarted if they crash due to a bug in Vitastor client code
 - Multiple clusters by using multiple configuration files in ConfigMap.
 Remember that to use snapshots with CSI you also have to install [Snapshot Controller and CRDs](https://kubernetes-csi.github.io/docs/snapshot-controller.html#deployment).
--- a/docs/installation/kubernetes.ru.md
+++ b/docs/installation/kubernetes.ru.md
@ -8,36 +8,13 @@
 У Vitastor есть CSI-плагин для Kubernetes, поддерживающий RWO, а также блочные RWX, тома.
-Для установки возьмите манифесты из директории [csi/deploy/](../../csi/deploy/), поместите
+Для установки возьмите манифесты из директории [csi/deploy/](../csi/deploy/), поместите
-вашу конфигурацию подключения к Vitastor в [csi/deploy/001-csi-config-map.yaml](../../csi/deploy/001-csi-config-map.yaml),
+вашу конфигурацию подключения к Vitastor в [csi/deploy/001-csi-config-map.yaml](../csi/deploy/001-csi-config-map.yaml),
-настройте StorageClass в [csi/deploy/009-storage-class.yaml](../../csi/deploy/009-storage-class.yaml)
+настройте StorageClass в [csi/deploy/009-storage-class.yaml](../csi/deploy/009-storage-class.yaml)
 и примените все `NNN-*.yaml` к вашей инсталляции Kubernetes.
 ```
 for i in ./???-*.yaml; do kubectl apply -f $i; done
 ```
-После этого вы сможете создавать PersistentVolume.
+После этого вы сможете создавать PersistentVolume. Пример смотрите в файле [csi/deploy/example-pvc.yaml](../csi/deploy/example-pvc.yaml).
 **Важно:** Лучше всего использовать ядро Linux версии не менее 5.15 с включёнными модулями
 [VDUSE](../usage/qemu.ru.md#vduse) (vdpa, vduse, virtio-vdpa). Если в вашем дистрибутиве
 они не собраны из коробки - соберите их сами, обещаю, что это стоит того ([инструкция](../usage/qemu.ru.md#vduse)) :-).
 Когда VDUSE недоступно, CSI-плагин использует [NBD](../usage/nbd.ru.md) для подключения
 дисков, а NBD медленнее и имеет проблему таймаута - если кластер остаётся недоступным
 дольше, чем [nbd_timeout](../config/client.ru.md#nbd_timeout), NBD-устройство отключается
 и ломает поды, использующие его.
 ## Возможности
 CSI-плагин Vitastor поддерживает:
 - Версии Kubernetes, начиная с 1.20 (или с 1.17 для более старых vitastor-csi <= 1.1.0)
 - Файловые RWO (ReadWriteOnce) тома. Пример: [PVC](../../csi/deploy/example-pvc.yaml), [под](../../csi/deploy/example-test-pod.yaml)
 - Сырые блочные RWX (ReadWriteMany) тома. Пример: [PVC](../../csi/deploy/example-pvc-block.yaml), [под](../../csi/deploy/example-test-pod-block.yaml)
 - Расширение размера томов
 - Снимки томов. Пример: [класс снимков](../../csi/deploy/example-snapshot-class.yaml), [снимок](../../csi/deploy/example-snapshot.yaml), [клон снимка](../../csi/deploy/example-snapshot-clone.yaml)
 - Способы подключения устройств [VDUSE](../usage/qemu.ru.md#vduse) (предпочитаемый) и [NBD](../usage/nbd.ru.md)
 - Обновление при использовании VDUSE - новые процессы-обработчики устройств успешно перезапускаются вместе с самими подами CSI
 - Автоперезауск демонов VDUSE - процесс-обработчик автоматически перезапустится, если он внезапно упадёт из-за бага в коде клиента Vitastor
 - Несколько кластеров через задание нескольких файлов конфигурации в ConfigMap.
 Не забывайте, что для использования снимков нужно сначала установить [контроллер снимков и CRD](https://kubernetes-csi.github.io/docs/snapshot-controller.html#deployment).
--- a/docs/installation/openstack.en.md
+++ b/docs/installation/openstack.en.md
@ -36,5 +36,5 @@ vitastor_pool_id = 1
 image_upload_use_cinder_backend = True
 ```
-To put Glance images in Vitastor, use [volume-backed images](https://docs.openstack.org/cinder/pike/admin/blockstorage-volume-backed-image.html),
+To put Glance images in Vitastor, use [https://docs.openstack.org/cinder/pike/admin/blockstorage-volume-backed-image.html](volume-backed images),
 although the support has not been verified yet.
--- a/docs/installation/openstack.ru.md
+++ b/docs/installation/openstack.ru.md
@ -36,5 +36,5 @@ image_upload_use_cinder_backend = True
 ```
 Чтобы помещать в Vitastor Glance-образы, нужно использовать
-[образы на основе томов Cinder](https://docs.openstack.org/cinder/pike/admin/blockstorage-volume-backed-image.html),
+[https://docs.openstack.org/cinder/pike/admin/blockstorage-volume-backed-image.html](образы на основе томов Cinder),
 однако, поддержка этой функции ещё не проверялась.
--- a/docs/installation/packages.en.md
+++ b/docs/installation/packages.en.md
@ -9,32 +9,26 @@
 ## Debian
 - Trust Vitastor package signing key:
-  `wget https://vitastor.io/debian/pubkey.gpg -O /etc/apt/trusted.gpg.d/vitastor.gpg`
+  `wget -q -O - https://vitastor.io/debian/pubkey | sudo apt-key add -`
 - Add Vitastor package repository to your /etc/apt/sources.list:
-  - Debian 12 (Bookworm/Sid): `deb https://vitastor.io/debian bookworm main`
+  - Debian 11 (Bullseye/Sid): `deb https://vitastor.io/debian bullseye main`
  - Debian 11 (Bullseye): `deb https://vitastor.io/debian bullseye main`
  - Debian 10 (Buster): `deb https://vitastor.io/debian buster main`
  - Add `-oldstable` to bookworm/bullseye/buster in this line to install the last
    stable version from 0.9.x branch instead of 1.x
 - For Debian 10 (Buster) also enable backports repository:
  `deb http://deb.debian.org/debian buster-backports main`
- Install packages: `apt update; apt install vitastor lp-solve etcd linux-image-amd64 qemu-system-x86`
+- Install packages: `apt update; apt install vitastor lp-solve etcd linux-image-amd64 qemu`
 ## CentOS
 - Add Vitastor package repository:
-  - CentOS 7: `yum install https://vitastor.io/rpms/centos/7/vitastor-release.rpm`
+  - CentOS 7: `yum install https://vitastor.io/rpms/centos/7/vitastor-release-1.0-1.el7.noarch.rpm`
-  - CentOS 8: `dnf install https://vitastor.io/rpms/centos/8/vitastor-release.rpm`
+  - CentOS 8: `dnf install https://vitastor.io/rpms/centos/8/vitastor-release-1.0-1.el8.noarch.rpm`
  - AlmaLinux 9 and other RHEL 9 clones (Rocky, Oracle...): `dnf install https://vitastor.io/rpms/centos/9/vitastor-release.rpm`
 - Enable EPEL: `yum/dnf install epel-release`
 - Enable additional CentOS repositories:
  - CentOS 7: `yum install centos-release-scl`
  - CentOS 8: `dnf install centos-release-advanced-virtualization`
  - RHEL 9 clones: not required
 - Enable elrepo-kernel:
  - CentOS 7: `yum install https://www.elrepo.org/elrepo-release-7.el7.elrepo.noarch.rpm`
  - CentOS 8: `dnf install https://www.elrepo.org/elrepo-release-8.el8.elrepo.noarch.rpm`
  - RHEL 9 clones: `dnf install https://www.elrepo.org/elrepo-release-9.el9.elrepo.noarch.rpm`
 - Install packages: `yum/dnf install vitastor lpsolve etcd kernel-ml qemu-kvm`
 ## Installation requirements
@ -48,10 +42,3 @@
 - etcd 3.4.15 or newer. Earlier versions won't work because of various bugs,
  for example [#12402](https://github.com/etcd-io/etcd/pull/12402).
 - node.js 10 or newer
 ## Version archive
 All previous Vitastor and other components (QEMU, etcd...) package builds
 can be found here:
 https://vitastor.io/archive/
--- a/docs/installation/packages.ru.md
+++ b/docs/installation/packages.ru.md
@ -9,32 +9,26 @@
 ## Debian
 - Добавьте ключ репозитория Vitastor:
-  `wget https://vitastor.io/debian/pubkey.gpg -O /etc/apt/trusted.gpg.d/vitastor.gpg`
+  `wget -q -O - https://vitastor.io/debian/pubkey | sudo apt-key add -`
 - Добавьте репозиторий Vitastor в /etc/apt/sources.list:
-  - Debian 12 (Bookworm/Sid): `deb https://vitastor.io/debian bookworm main`
+  - Debian 11 (Bullseye/Sid): `deb https://vitastor.io/debian bullseye main`
  - Debian 11 (Bullseye): `deb https://vitastor.io/debian bullseye main`
  - Debian 10 (Buster): `deb https://vitastor.io/debian buster main`
  - Добавьте `-oldstable` к слову bookworm/bullseye/buster в этой строке, чтобы
    установить последнюю стабильную версию из ветки 0.9.x вместо 1.x
 - Для Debian 10 (Buster) также включите репозиторий backports:
  `deb http://deb.debian.org/debian buster-backports main`
- Установите пакеты: `apt update; apt install vitastor lp-solve etcd linux-image-amd64 qemu-system-x86`
+- Установите пакеты: `apt update; apt install vitastor lp-solve etcd linux-image-amd64 qemu`
 ## CentOS
 - Добавьте в систему репозиторий Vitastor:
-  - CentOS 7: `yum install https://vitastor.io/rpms/centos/7/vitastor-release.rpm`
+  - CentOS 7: `yum install https://vitastor.io/rpms/centos/7/vitastor-release-1.0-1.el7.noarch.rpm`
-  - CentOS 8: `dnf install https://vitastor.io/rpms/centos/8/vitastor-release.rpm`
+  - CentOS 8: `dnf install https://vitastor.io/rpms/centos/8/vitastor-release-1.0-1.el8.noarch.rpm`
  - AlmaLinux 9 и другие клоны RHEL 9 (Rocky, Oracle...): `dnf install https://vitastor.io/rpms/centos/9/vitastor-release.rpm`
 - Включите EPEL: `yum/dnf install epel-release`
 - Включите дополнительные репозитории CentOS:
  - CentOS 7: `yum install centos-release-scl`
  - CentOS 8: `dnf install centos-release-advanced-virtualization`
  - Клоны RHEL 9: не нужно
 - Включите elrepo-kernel:
  - CentOS 7: `yum install https://www.elrepo.org/elrepo-release-7.el7.elrepo.noarch.rpm`
  - CentOS 8: `dnf install https://www.elrepo.org/elrepo-release-8.el8.elrepo.noarch.rpm`
  - Клоны RHEL 9: `dnf install https://www.elrepo.org/elrepo-release-9.el9.elrepo.noarch.rpm`
 - Установите пакеты: `yum/dnf install vitastor lpsolve etcd kernel-ml qemu-kvm`
 ## Установочные требования
@ -47,10 +41,3 @@
 - etcd 3.4.15 или новее. Более старые версии не будут работать из-за разных багов,
  например, [#12402](https://github.com/etcd-io/etcd/pull/12402).
 - node.js 10 или новее
 ## Архив предыдущих версий
 Все предыдущие сборки пакетов Vitastor и других компонентов, таких, как QEMU
 и etcd, можно скачать по следующей ссылке:
 https://vitastor.io/archive/
--- a/docs/installation/proxmox.en.md
+++ b/docs/installation/proxmox.en.md
@ -6,10 +6,10 @@
 # Proxmox VE
-To enable Vitastor support in Proxmox Virtual Environment (6.4-8.1 are supported):
+To enable Vitastor support in Proxmox Virtual Environment (6.4-7.3 are supported):
 - Add the corresponding Vitastor Debian repository into sources.list on Proxmox hosts:
-  bookworm for 8.1, pve8.0 for 8.0, bullseye for 7.4, pve7.3 for 7.3, pve7.2 for 7.2, pve7.1 for 7.1, buster for 6.4
+  buster for 6.4, bullseye for 7.3, pve7.1 for 7.1, pve7.2 for 7.2
 - Install vitastor-client, pve-qemu-kvm, pve-storage-vitastor (* or see note) packages from Vitastor repository
 - Define storage in `/etc/pve/storage.cfg` (see below)
 - Block network access from VMs to Vitastor network (to OSDs and etcd),
@ -25,7 +25,7 @@ vitastor: vitastor
    vitastor_pool testpool
    # path to the configuration file
    vitastor_config_path /etc/vitastor/vitastor.conf
-    # etcd address(es), OPTIONAL, required only if missing in the configuration file
+    # etcd address(es), required only if missing in the configuration file
    vitastor_etcd_address 192.168.7.2:2379/v3
    # prefix for keys in etcd
    vitastor_etcd_prefix /vitastor
@ -35,5 +35,5 @@ vitastor: vitastor
    vitastor_nbd 0
 ```
-\* Note: you can also manually copy [patches/VitastorPlugin.pm](../../patches/VitastorPlugin.pm) to Proxmox hosts
+\* Note: you can also manually copy [patches/VitastorPlugin.pm](patches/VitastorPlugin.pm) to Proxmox hosts
 as `/usr/share/perl5/PVE/Storage/Custom/VitastorPlugin.pm` instead of installing pve-storage-vitastor.
--- a/docs/installation/proxmox.ru.md
+++ b/docs/installation/proxmox.ru.md
@ -1,15 +1,15 @@
-[Документация](../../README-ru.md#документация) → Установка → Proxmox VE
+[Документация](../../README-ru.md#документация) → Установка → Proxmox
 -----
 [Read in English](proxmox.en.md)
-# Proxmox VE
+# Proxmox
-Чтобы подключить Vitastor к Proxmox Virtual Environment (поддерживаются версии 6.4-8.1):
+Чтобы подключить Vitastor к Proxmox Virtual Environment (поддерживаются версии 6.4-7.3):
 - Добавьте соответствующий Debian-репозиторий Vitastor в sources.list на хостах Proxmox:
-  bookworm для 8.1, pve8.0 для 8.0, bullseye для 7.4, pve7.3 для 7.3, pve7.2 для 7.2, pve7.1 для 7.1, buster для 6.4
+  buster для 6.4, bullseye для 7.3, pve7.1 для 7.1, pve7.2 для 7.2
 - Установите пакеты vitastor-client, pve-qemu-kvm, pve-storage-vitastor (* или см. сноску) из репозитория Vitastor
 - Определите тип хранилища в `/etc/pve/storage.cfg` (см. ниже)
 - Обязательно заблокируйте доступ от виртуальных машин к сети Vitastor (OSD и etcd), т.к. Vitastor (пока) не поддерживает аутентификацию
@ -24,7 +24,7 @@ vitastor: vitastor
    vitastor_pool testpool
    # Путь к файлу конфигурации
    vitastor_config_path /etc/vitastor/vitastor.conf
-    # Адрес(а) etcd, ОПЦИОНАЛЬНЫ, нужны, только если не указаны в vitastor.conf
+    # Адрес(а) etcd, нужны, только если не указаны в vitastor.conf
    vitastor_etcd_address 192.168.7.2:2379/v3
    # Префикс ключей метаданных в etcd
    vitastor_etcd_prefix /vitastor
@ -35,5 +35,5 @@ vitastor: vitastor
 ```
 \* Примечание: вместо установки пакета pve-storage-vitastor вы можете вручную скопировать файл
-[patches/VitastorPlugin.pm](../../patches/VitastorPlugin.pm) на хосты Proxmox как
+[patches/VitastorPlugin.pm](patches/VitastorPlugin.pm) на хосты Proxmox как
 `/usr/share/perl5/PVE/Storage/Custom/VitastorPlugin.pm`.
--- a/docs/installation/source.en.md
+++ b/docs/installation/source.en.md
@ -21,7 +21,7 @@
 ## Basic instructions
-Download source, for example using git: `git clone --recurse-submodules https://git.yourcmc.ru/vitalif/vitastor/`
+Download source, for example using git: `git clone --recurse-submodules https://yourcmc.ru/git/vitalif/vitastor/`
 Get `fio` source and symlink it into `<vitastor>/fio`. If you don't want to build fio engine,
 you can disable it by passing `-DWITH_FIO=no` to cmake.
@ -41,7 +41,7 @@ It's recommended to build the QEMU driver (qemu_driver.c) in-tree, as a part of
 QEMU build process. To do that:
 - Install vitastor client library headers (from source or from vitastor-client-dev package)
 - Take a corresponding patch from `patches/qemu-*-vitastor.patch` and apply it to QEMU source
- Copy `src/qemu_driver.c` to QEMU source directory as `block/vitastor.c`
+- Copy `src/qemu_driver.c` to QEMU source directory as `block/block-vitastor.c`
 - Build QEMU as usual
 But it is also possible to build it out-of-tree. To do that:
--- a/docs/installation/source.ru.md
+++ b/docs/installation/source.ru.md
@ -21,7 +21,7 @@
 ## Базовая инструкция
-Скачайте исходные коды, например, из git: `git clone --recurse-submodules https://git.yourcmc.ru/vitalif/vitastor/`
+Скачайте исходные коды, например, из git: `git clone --recurse-submodules https://yourcmc.ru/git/vitalif/vitastor/`
 Скачайте исходные коды пакета `fio`, распакуйте их и создайте символическую ссылку на них
 в директории исходников Vitastor: `<vitastor>/fio`. Либо, если вы не хотите собирать плагин fio,
@ -41,7 +41,7 @@ cmake .. && make -j8 install
 Драйвер QEMU (qemu_driver.c) рекомендуется собирать вместе с самим QEMU. Для этого:
 - Установите заголовки клиентской библиотеки Vitastor (из исходников или из пакета vitastor-client-dev)
 - Возьмите соответствующий патч из `patches/qemu-*-vitastor.patch` и примените его к исходникам QEMU
- Скопируйте [src/qemu_driver.c](../../src/qemu_driver.c) в директорию исходников QEMU как `block/vitastor.c`
+- Скопируйте [src/qemu_driver.c](../../src/qemu_driver.c) в директорию исходников QEMU как `block/block-vitastor.c`
 - Соберите QEMU как обычно
 Однако в целях отладки драйвер также можно собирать отдельно от QEMU. Для этого:
@ -60,7 +60,7 @@ cmake .. && make -j8 install
      * Для QEMU 2.0+: `<qemu>/qapi-types.h` &rarr; `<vitastor>/qemu/b/qemu/qapi-types.h`
   - `config-host.h` и `qapi` нужны, т.к. в них содержатся автогенерируемые заголовки
 - Сконфигурируйте cmake Vitastor с `WITH_QEMU=yes` (`cmake .. -DWITH_QEMU=yes`) и, если вы
-  используете RHEL-подобный дистрибутив, также с `QEMU_PLUGINDIR=qemu-kvm`.
+  используете RHEL-подобый дистрибутив, также с `QEMU_PLUGINDIR=qemu-kvm`.
 - После этого в процессе сборки Vitastor также будет собираться подходящий для вашей
  версии QEMU `block-vitastor.so`.
 - Таким образом можно использовать драйвер даже с немодифицированным QEMU, но в этом случае
--- a/docs/intro/architecture.en.md
+++ b/docs/intro/architecture.en.md
@ -44,7 +44,7 @@
  depends linearly on drive capacity and data store block size which is 128 KB by default.
  With 128 KB blocks metadata takes around 512 MB per 1 TB (which is still less than Ceph wants).
  Journal is also kept in memory by default, but in SSD-only clusters it's only 32 MB, and in SSD+HDD
-  clusters, where it's beneficial to increase it, [inmemory_journal](../config/osd.en.md#inmemory_journal) can be disabled.
+  clusters, where it's beneficial to increase it, [inmemory_journal](docs/config/osd.en.md#inmemory_journal) can be disabled.
 - Vitastor storage layer doesn't have internal copy-on-write or redirect-write. I know that maybe
  it's possible to create a good copy-on-write storage, but it's much harder and makes performance
  less deterministic, so CoW isn't used in Vitastor.
--- a/docs/intro/architecture.ru.md
+++ b/docs/intro/architecture.ru.md
@ -54,8 +54,7 @@
  виртуальные диски, их снимки и клоны.
 - **Драйвер 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 нет
@ -157,7 +156,7 @@
  блока хранилища (block_size, по умолчанию 128 КБ). С 128 КБ блоком потребление памяти
  составляет примерно 512 МБ на 1 ТБ данных. Журналы по умолчанию тоже хранятся в памяти,
  но в SSD-кластерах нужный размер журнала составляет всего 32 МБ, а в гибридных (SSD+HDD)
-  кластерах, в которых есть смысл делать журналы больше, можно отключить [inmemory_journal](../config/osd.ru.md#inmemory_journal).
+  кластерах, в которых есть смысл делать журналы больше, можно отключить [inmemory_journal](../docs/config/osd.ru.md#inmemory_journal).
 - В Vitastor нет внутреннего copy-on-write. Я считаю, что реализация CoW-хранилища гораздо сложнее,
  поэтому сложнее добиться устойчиво хороших результатов. Возможно, в один прекрасный день
  я придумаю красивый алгоритм для CoW-хранилища, но пока нет — внутреннего CoW в Vitastor не будет.
--- a/docs/intro/features.en.md
+++ b/docs/intro/features.en.md
@ -29,16 +29,12 @@
 - Snapshots and copy-on-write image clones
 - [Write throttling to smooth random write workloads in SSD+HDD configurations](../config/osd.en.md#throttle_small_writes)
 - [RDMA/RoCEv2 support via libibverbs](../config/network.en.md#rdma_device)
 - [Scrubbing](../config/osd.en.md#auto_scrub) (verification of copies)
 - [Checksums](../config/layout-osd.en.md#data_csum_type)
 - [Client write-back cache](../config/client.en.md#client_enable_writeback)
 - [Intelligent recovery auto-tuning](../config/osd.en.md#recovery_tune_interval)
 ## Plugins and tools
 - [Debian and CentOS packages](../installation/packages.en.md)
 - [Image management CLI (vitastor-cli)](../usage/cli.en.md)
- [Disk management CLI (vitastor-disk)](../usage/disk.en.md)
+- [Disk management CLI (vitastor-disk)](docs/usage/disk.en.md)
 - Generic user-space client library
 - [Native QEMU driver](../usage/qemu.en.md)
 - [Loadable fio engine for benchmarks](../usage/fio.en.md)
@ -52,15 +48,15 @@
 The following features are planned for the future:
 - File system
 - Control plane optimisation
 - Other administrative tools
 - Web GUI
 - OpenNebula plugin
- iSCSI and NVMeoF gateways
+- iSCSI proxy
 - Multi-threaded client
 - Faster failover
- S3
+- Scrubbing without checksums (verification of replicas)
 - Checksums
 - Tiered storage (SSD caching)
 - NVDIMM support
 - Compression (possibly)
 - Read caching using system page cache (possibly)
--- a/docs/intro/features.ru.md
+++ b/docs/intro/features.ru.md
@ -13,7 +13,7 @@
 ## Серверные функции
 - Базовая часть - надёжное кластерное блочное хранилище без единой точки отказа
- [Производительность](../performance/comparison1.ru.md) ;-D
+- [Производительность](../comparison1.ru.md) ;-D
 - [Несколько схем отказоустойчивости](../config/pool.ru.md#scheme): репликация, XOR n+1 (1 диск чётности), коды коррекции ошибок
  Рида-Соломона на основе библиотек jerasure и ISA-L с любым числом дисков данных и чётности в группе
 - Конфигурация через простые человекочитаемые JSON-структуры в etcd
@ -31,16 +31,12 @@
 - Снапшоты и copy-on-write клоны
 - [Сглаживание производительности случайной записи в SSD+HDD конфигурациях](../config/osd.ru.md#throttle_small_writes)
 - [Поддержка RDMA/RoCEv2 через libibverbs](../config/network.ru.md#rdma_device)
 - [Фоновая проверка целостности](../config/osd.ru.md#auto_scrub) (сверка копий)
 - [Контрольные суммы](../config/layout-osd.ru.md#data_csum_type)
 - [Буферизация записи на стороне клиента](../config/client.ru.md#client_enable_writeback)
 - [Интеллектуальная автоподстройка скорости восстановления](../config/osd.ru.md#recovery_tune_interval)
 ## Драйверы и инструменты
 - [Пакеты для Debian и CentOS](../installation/packages.ru.md)
 - [Консольный интерфейс управления образами (vitastor-cli)](../usage/cli.ru.md)
- [Инструмент управления дисками (vitastor-disk)](../usage/disk.ru.md)
+- [Инструмент управления дисками (vitastor-disk)](docs/usage/disk.ru.md)
 - Общая пользовательская клиентская библиотека для работы с кластером
 - [Драйвер диска для QEMU](../usage/qemu.ru.md)
 - [Драйвер диска для утилиты тестирования производительности fio](../usage/fio.ru.md)
@ -52,15 +48,14 @@
 ## Планы развития
 - Файловая система
 - Оптимизация слоя управления
 - Другие инструменты администрирования
 - Web-интерфейс
 - Плагин для OpenNebula
- iSCSI и NVMeoF прокси
+- iSCSI-прокси
 - Многопоточный клиент
 - Более быстрое переключение при отказах
- S3
+- Фоновая проверка целостности без контрольных сумм (сверка реплик)
 - Контрольные суммы
 - Поддержка SSD-кэширования (tiered storage)
 - Поддержка NVDIMM
 - Возможно, сжатие
--- a/docs/intro/quickstart.en.md
+++ b/docs/intro/quickstart.en.md
@ -7,7 +7,6 @@
 # Quick Start
 - [Preparation](#preparation)
 - [Recommended drives](#recommended-drives)
 - [Configure monitors](#configure-monitors)
 - [Configure OSDs](#configure-osds)
 - [Create a pool](#create-a-pool)
@ -20,20 +19,10 @@
 - Get some SATA or NVMe SSDs with capacitors (server-grade drives). You can use desktop SSDs
  with lazy fsync, but prepare for inferior single-thread latency. Read more about capacitors
  [here](../config/layout-cluster.en.md#immediate_commit).
 - If you want to use HDDs, get modern HDDs with Media Cache or SSD Cache: HGST Ultrastar,
  Toshiba MG08, Seagate EXOS or something similar. If your drives don't have such cache then
  you also need small SSDs for journal and metadata (even 2 GB per 1 TB of HDD space is enough).
 - Get a fast network (at least 10 Gbit/s). Something like Mellanox ConnectX-4 with RoCEv2 is ideal.
 - Disable CPU powersaving: `cpupower idle-set -D 0 && cpupower frequency-set -g performance`.
 - [Install Vitastor packages](../installation/packages.en.md).
 ## Recommended drives
 - SATA SSD: Micron 5100/5200/5300/5400, Samsung PM863/PM883/PM893, Intel D3-S4510/4520/4610/4620, Kingston DC500M
 - NVMe: Micron 9100/9200/9300/9400, Micron 7300/7450, Samsung PM983/PM9A3, Samsung PM1723/1735/1743,
  Intel DC-P3700/P4500/P4600, Intel D7-P5500/P5600, Intel Optane, Kingston DC1000B/DC1500M
 - HDD: HGST Ultrastar, Toshiba MG06/MG07/MG08, Seagate EXOS
 ## Configure monitors
 On the monitor hosts:
@ -56,10 +45,7 @@ On the monitor hosts:
  }
  ```
 - Initialize OSDs:
-  - SSD-only or HDD-only: `vitastor-disk prepare /dev/sdXXX [/dev/sdYYY ...]`.
+  - SSD-only: `vitastor-disk prepare /dev/sdXXX [/dev/sdYYY ...]`
    Add `--disable_data_fsync off` to leave disk write cache enabled if you use
    desktop SSDs without capacitors. Do NOT add `--disable_data_fsync off` if you
    use HDDs or SSD+HDD.
  - Hybrid, SSD+HDD: `vitastor-disk prepare --hybrid /dev/sdXXX [/dev/sdYYY ...]`.
    Pass all your devices (HDD and SSD) to this script &mdash; it will partition disks and initialize journals on its own.
    This script skips HDDs which are already partitioned so if you want to use non-empty disks for
@ -67,9 +53,7 @@ On the monitor hosts:
    but some free unpartitioned space must be available because the script creates new partitions for journals.
 - You can change OSD configuration in units or in `vitastor.conf`.
  Check [Configuration Reference](../config.en.md) for parameter descriptions.
- If all your drives have capacitors, and even if not, but if you ran `vitastor-disk`
+- If all your drives have capacitors, create global configuration in etcd: \
  without `--disable_data_fsync off` at the first step, then put the following
  setting into etcd: \
  `etcdctl --endpoints=... put /vitastor/config/global '{"immediate_commit":"all"}'`
 - Start all OSDs: `systemctl start vitastor.target`
@ -86,15 +70,11 @@ For EC pools the configuration should look like the following:
 ```
 etcdctl --endpoints=... put /vitastor/config/pools '{"2":{"name":"ecpool",
-  "scheme":"ec","pg_size":4,"parity_chunks":2,"pg_minsize":2,"pg_count":256,"failure_domain":"host"}}'
+  "scheme":"ec","pg_size":4,"parity_chunks":2,"pg_minsize":2,"pg_count":256,"failure_domain":"host"}'
 ```
 After you do this, one of the monitors will configure PGs and OSDs will start them.
 If you use HDDs you should also add `"block_size": 1048576` to pool configuration.
 The other option is to add it into /vitastor/config/global, in this case it will
 apply to all pools by default.
 ## Check cluster status
 `vitastor-cli status`
--- a/docs/intro/quickstart.ru.md
+++ b/docs/intro/quickstart.ru.md
@ -7,7 +7,6 @@
 # Быстрый старт
 - [Подготовка](#подготовка)
 - [Рекомендуемые диски](#рекомендуемые-диски)
 - [Настройте мониторы](#настройте-мониторы)
 - [Настройте OSD](#настройте-osd)
 - [Создайте пул](#создайте-пул)
@ -20,20 +19,10 @@
 - Возьмите серверы с SSD (SATA или NVMe), желательно с конденсаторами (серверные SSD). Можно
  использовать и десктопные SSD, включив режим отложенного fsync, но производительность будет хуже.
  О конденсаторах читайте [здесь](../config/layout-cluster.ru.md#immediate_commit).
 - Если хотите использовать HDD, берите современные модели с Media или SSD кэшем - HGST Ultrastar,
  Toshiba MG08, Seagate EXOS или что-то похожее. Если такого кэша у ваших дисков нет,
  обязательно возьмите SSD под метаданные и журнал (маленькие, буквально 2 ГБ на 1 ТБ HDD-места).
 - Возьмите быструю сеть, минимум 10 гбит/с. Идеал - что-то вроде Mellanox ConnectX-4 с RoCEv2.
 - Для лучшей производительности отключите энергосбережение CPU: `cpupower idle-set -D 0 && cpupower frequency-set -g performance`.
 - [Установите пакеты Vitastor](../installation/packages.ru.md).
 ## Рекомендуемые диски
 - SATA SSD: Micron 5100/5200/5300/5400, Samsung PM863/PM883/PM893, Intel D3-S4510/4520/4610/4620, Kingston DC500M
 - NVMe: Micron 9100/9200/9300/9400, Micron 7300/7450, Samsung PM983/PM9A3, Samsung PM1723/1735/1743,
  Intel DC-P3700/P4500/P4600, Intel D7-P5500/P5600, Intel Optane, Kingston DC1000B/DC1500M
 - HDD: HGST Ultrastar, Toshiba MG06/MG07/MG08, Seagate EXOS
 ## Настройте мониторы
 На хостах, выделенных под мониторы:
@ -56,10 +45,7 @@
  }
  ```
 - Инициализуйте OSD:
-  - Только SSD или только HDD: `vitastor-disk prepare /dev/sdXXX [/dev/sdYYY ...]`.
+  - SSD: `vitastor-disk prepare /dev/sdXXX [/dev/sdYYY ...]`
    Если вы используете десктопные SSD без конденсаторов, добавьте опцию `--disable_data_fsync off`,
    чтобы оставить кэш записи диска включённым. НЕ добавляйте эту опцию, если используете
    жёсткие диски (HDD).
  - Гибридные, SSD+HDD: `vitastor-disk prepare --hybrid /dev/sdXXX [/dev/sdYYY ...]`.
    Передайте все ваши SSD и HDD скрипту в командной строке подряд, скрипт автоматически выделит
    разделы под журналы на SSD и данные на HDD. Скрипт пропускает HDD, на которых уже есть разделы
@ -68,11 +54,8 @@
    для журналов, на SSD должно быть доступно свободное нераспределённое место.
 - Вы можете менять параметры OSD в юнитах systemd или в `vitastor.conf`. Описания параметров
  смотрите в [справке по конфигурации](../config.ru.md).
- Если все ваши диски - серверные с конденсаторами, и даже если нет, но при этом
+- Если все ваши диски - серверные с конденсаторами, пропишите это в глобальную конфигурацию в etcd: \
-  вы не добавляли опцию `--disable_data_fsync off` на первом шаге, а `vitastor-disk`
+  `etcdctl --endpoints=... put /vitastor/config/global '{"immediate_commit":"all"}'`
  не ругался на невозможность отключения кэша дисков, пропишите следующую настройку
  в глобальную конфигурацию в etcd: \
  `etcdctl --endpoints=... put /vitastor/config/global '{"immediate_commit":"all"}'`.
 - Запустите все OSD: `systemctl start vitastor.target`
 ## Создайте пул
@ -88,15 +71,11 @@ etcdctl --endpoints=... put /vitastor/config/pools '{"1":{"name":"testpool",
 ```
 etcdctl --endpoints=... put /vitastor/config/pools '{"2":{"name":"ecpool",
-  "scheme":"ec","pg_size":4,"parity_chunks":2,"pg_minsize":2,"pg_count":256,"failure_domain":"host"}}'
+  "scheme":"ec","pg_size":4,"parity_chunks":2,"pg_minsize":2,"pg_count":256,"failure_domain":"host"}'
 ```
 После этого один из мониторов должен сконфигурировать PG, а OSD должны запустить их.
 Если вы используете HDD-диски, то добавьте в конфигурацию пулов опцию `"block_size": 1048576`.
 Также эту опцию можно добавить в /vitastor/config/global, в этом случае она будет
 применяться ко всем пулам по умолчанию.
 ## Проверьте состояние кластера
 `vitastor-cli status`
--- a/docs/performance/theoretical.en.md
+++ b/docs/performance/theoretical.en.md
@ -11,26 +11,19 @@ Replicated setups:
 - Single-threaded write+fsync latency:
  - With immediate commit: 2 network roundtrips + 1 disk write.
  - With lazy commit: 4 network roundtrips + 1 disk write + 1 disk flush.
- Linear read: `min(total network bandwidth, sum(disk read MB/s))`.
+- Saturated parallel read iops: min(network bandwidth, sum(disk read iops)).
- Linear write: `min(total network bandwidth, sum(disk write MB/s / number of replicas))`.
+- Saturated parallel write iops: min(network bandwidth, sum(disk write iops / number of replicas / write amplification)).
 - Saturated parallel read iops: `min(total network bandwidth, sum(disk read iops))`.
 - Saturated parallel write iops: `min(total network bandwidth / number of replicas, sum(disk write iops / number of replicas / (write amplification = 4)))`.
-EC/XOR setups (EC N+K):
+EC/XOR setups:
 - Single-threaded (T1Q1) read latency: 1.5 network roundtrips + 1 disk read.
 - Single-threaded write+fsync latency:
  - With immediate commit: 3.5 network roundtrips + 1 disk read + 2 disk writes.
  - With lazy commit: 5.5 network roundtrips + 1 disk read + 2 disk writes + 2 disk fsyncs.
-  - 0.5 in actually `(N-1)/N` which means that an additional roundtrip doesn't happen when
+  - 0.5 in actually (k-1)/k which means that an additional roundtrip doesn't happen when
    the read sub-operation can be served locally.
- Linear read: `min(total network bandwidth, sum(disk read MB/s))`.
+- Saturated parallel read iops: min(network bandwidth, sum(disk read iops)).
- Linear write: `min(total network bandwidth, sum(disk write MB/s * N/(N+K)))`.
+- Saturated parallel write iops: min(network bandwidth, sum(disk write iops * number of data drives / (number of data + parity drives) / write amplification)).
- Saturated parallel read iops: `min(total network bandwidth, sum(disk read iops))`.
+  In fact, you should put disk write iops under the condition of ~10% reads / ~90% writes in this formula.
 - Saturated parallel write iops: roughly `total iops / (N+K) / WA`. More exactly,
  `min(total network bandwidth * N/(N+K), sum(disk randrw iops / (N*4 + K*5 + 1)))` with
  random read/write mix corresponding to `(N-1)/(N*4 + K*5 + 1)*100 % reads`.
  - For example, with EC 2+1 it is: `(7% randrw iops) / 14`.
  - With EC 6+3 it is: `(12.5% randrw iops) / 40`.
 Write amplification for 4 KB blocks is usually 3-5 in Vitastor:
 1. Journal block write
@ -42,24 +35,15 @@ Write amplification for 4 KB blocks is usually 3-5 in Vitastor:
 If you manage to get an SSD which handles 512 byte blocks well (Optane?) you may
 lower 1, 3 and 4 to 512 bytes (1/8 of data size) and get WA as low as 2.375.
 Implemented NVDIMM support can basically eliminate WA at all - all extra writes will
 go to DRAM memory. But this requires a test cluster with NVDIMM - please contact me
 if you want to provide me with such cluster for tests.
 Lazy fsync also reduces WA for parallel workloads because journal blocks are only
 written when they fill up or fsync is requested.
 ## In Practice
-In practice, using tests from [Understanding Performance](understanding.en.md), decent TCP network,
+In practice, using tests from [Understanding Performance](understanding.en.md)
-good server-grade SSD/NVMe drives and disabled CPU power saving, you should head for:
+and good server-grade SSD/NVMe drives, you should head for:
 - At least 5000 T1Q1 replicated read and write iops (maximum 0.2ms latency)
 - At least 5000 T1Q1 EC read IOPS and at least 2200 EC write IOPS (maximum 0.45ms latency)
 - At least ~80k parallel read iops or ~30k write iops per 1 core (1 OSD)
 - Disk-speed or wire-speed linear reads and writes, whichever is the bottleneck in your case
 Lower results may mean that you have bad drives, bad network or some kind of misconfiguration.
 Current latency records:
 - 9668 T1Q1 replicated write iops (0.103 ms latency) with TCP and NVMe
 - 9143 T1Q1 replicated read iops (0.109 ms latency) with TCP and NVMe
--- a/docs/performance/theoretical.ru.md
+++ b/docs/performance/theoretical.ru.md
@ -11,27 +11,20 @@
 - Запись+fsync в 1 поток:
  - С мгновенным сбросом: 2 RTT + 1 запись.
  - С отложенным ("ленивым") сбросом: 4 RTT + 1 запись + 1 fsync.
- Линейное чтение: сумма МБ/с чтения всех дисков, либо общая производительность сети (сумма пропускной способности сети всех нод), если в сеть упрётся раньше.
+- Параллельное чтение: сумма IOPS всех дисков либо производительность сети, если в сеть упрётся раньше.
- Линейная запись: сумма МБ/с записи всех дисков / число реплик, либо производительность сети / число реплик, если в сеть упрётся раньше.
+- Параллельная запись: сумма IOPS всех дисков / число реплик / WA либо производительность сети, если в сеть упрётся раньше.
 - Параллельное случайное мелкое чтение: сумма IOPS чтения всех дисков, либо производительность сети, если в сеть упрётся раньше.
 - Параллельная случайная мелкая запись: сумма IOPS записи всех дисков / число реплик / WA, либо производительность сети / число реплик, если в сеть упрётся раньше.
-При использовании кодов коррекции ошибок (EC N+K):
+При использовании кодов коррекции ошибок (EC):
 - Задержка чтения в 1 поток (T1Q1): 1.5 RTT + 1 чтение.
 - Запись+fsync в 1 поток:
  - С мгновенным сбросом: 3.5 RTT + 1 чтение + 2 записи.
  - С отложенным ("ленивым") сбросом: 5.5 RTT + 1 чтение + 2 записи + 2 fsync.
- Под 0.5 на самом деле подразумевается (N-1)/N, где N - число дисков данных,
+- Под 0.5 на самом деле подразумевается (k-1)/k, где k - число дисков данных,
  что означает, что дополнительное обращение по сети не нужно, когда операция
  чтения обслуживается локально.
- Линейное чтение: сумма МБ/с чтения всех дисков, либо общая производительность сети, если в сеть упрётся раньше.
+- Параллельное чтение: сумма IOPS всех дисков либо производительность сети, если в сеть упрётся раньше.
- Линейная запись: сумма МБ/с записи всех дисков * N/(N+K), либо производительность сети * N / (N+K), если в сеть упрётся раньше.
+- Параллельная запись: сумма IOPS всех дисков / общее число дисков данных и чётности / WA либо производительность сети, если в сеть упрётся раньше.
- Параллельное случайное мелкое чтение: сумма IOPS чтения всех дисков либо производительность сети, если в сеть упрётся раньше.
+  Примечание: IOPS дисков в данном случае надо брать в смешанном режиме чтения/записи в пропорции, аналогичной формулам выше.
 - Параллельная случайная мелкая запись: грубо `(сумма IOPS / (N+K) / WA)`. Если точнее, то:
  сумма смешанного IOPS всех дисков при `(N-1)/(N*4 + K*5 + 1)*100 %` чтения, делённая на `(N*4 + K*5 + 1)`.
  Либо, производительность сети * N/(N+K), если в сеть упрётся раньше.
  - Например, при EC 2+1 это: `(сумма IOPS при 7% чтения) / 14`.
  - При EC 6+3 это: `(сумма IOPS при 12.5% чтения) / 40`.
 WA (мультипликатор записи) для 4 КБ блоков в Vitastor обычно составляет 3-5:
 1. Запись метаданных в журнал
@ -43,25 +36,6 @@ WA (мультипликатор записи) для 4 КБ блоков в Vit
 Если вы найдёте SSD, хорошо работающий с 512-байтными блоками данных (Optane?),
 то 1, 3 и 4 можно снизить до 512 байт (1/8 от размера данных) и получить WA всего 2.375.
 Если реализовать поддержку NVDIMM, то WA можно, условно говоря, ликвидировать вообще - все
 дополнительные операции записи смогут обслуживаться DRAM памятью. Но для этого необходим
 тестовый кластер с NVDIMM - пишите, если готовы предоставить такой для тестов.
 Кроме того, WA снижается при использовании отложенного/ленивого сброса при параллельной
 нагрузке, т.к. блоки журнала записываются на диск только когда они заполняются или явным
 образом запрашивается fsync.
 ## На практике
 На практике, используя тесты fio со страницы [Понимание сути производительности систем хранения](understanding.ru.md),
 нормальную TCP-сеть, хорошие серверные SSD/NVMe, при отключённом энергосбережении процессоров вы можете рассчитывать на:
 - От 5000 IOPS в 1 поток (T1Q1) и на чтение, и на запись при использовании репликации (задержка до 0.2мс)
 - От 5000 IOPS в 1 поток (T1Q1) на чтение и 2200 IOPS в 1 поток на запись при использовании EC (задержка до 0.45мс)
 - От 80000 IOPS на чтение в параллельном режиме на 1 ядро, от 30000 IOPS на запись на 1 ядро (на 1 OSD)
 - Скорость параллельного линейного чтения и записи, равная меньшему значению из скорости дисков или сети
 Худшие результаты означают, что у вас либо медленные диски, либо медленная сеть, либо что-то неправильно настроено.
 Зафиксированный на данный момент рекорд задержки:
 - 9668 IOPS (0.103 мс задержка) в 1 поток (T1Q1) на запись с TCP и NVMe при использовании репликации
 - 9143 IOPS (0.109 мс задержка) в 1 поток (T1Q1) на чтение с TCP и NVMe при использовании репликации
--- a/docs/usage/cli.en.md
+++ b/docs/usage/cli.en.md
@ -14,22 +14,18 @@ It supports the following commands:
 - [df](#df)
 - [ls](#ls)
 - [create](#create)
 - [snap-create](#create)
 - [modify](#modify)
 - [rm](#rm)
 - [flatten](#flatten)
 - [rm-data](#rm-data)
 - [merge-data](#merge-data)
 - [describe](#describe)
 - [fix](#fix)
 - [alloc-osd](#alloc-osd)
 - [rm-osd](#rm-osd)
 Global options:
 ```
--config_file FILE   Path to Vitastor configuration file
+--etcd_address ADDR  Etcd connection address
 --etcd_address URL   Etcd connection address
 --iodepth N          Send N operations in parallel to each OSD when possible (default 32)
 --parallel_osds M    Work with M osds in parallel when possible (default 4)
 --progress 1|0       Report progress (default 1)
@ -127,8 +123,6 @@ vitastor-cli snap-create [-p|--pool <id|name>] <image>@<snapshot>
 Create a snapshot of image `<name>` (either form can be used). May be used live if only a single writer is active.
 See also about [how to export snapshots](qemu.en.md#exporting-snapshots).
 ## modify
 `vitastor-cli modify <name> [--rename <new-name>] [--resize <size>] [--readonly | --readwrite] [-f|--force]`
@ -177,51 +171,6 @@ Merge layer data without changing metadata. Merge `<from>`..`<to>` to `<target>`
 `<to>` must be a child of `<from>` and `<target>` may be one of the layers between
 `<from>` and `<to>`, including `<from>` and `<to>`.
 ## describe
 `vitastor-cli describe [--osds <osds>] [--object-state <states>] [--pool <pool>]
    [--inode <ino>] [--min-inode <ino>] [--max-inode <ino>]
    [--min-offset <offset>] [--max-offset <offset>]`
 Describe unclean object locations in the cluster.
 ```
 --osds <osds>
    Only list objects from primary OSD(s) <osds>.
 --object-state <states>
    Only list objects in given state(s). State(s) may include:
    degraded, misplaced, incomplete, corrupted, inconsistent.
 --pool <pool name or number>
    Only list objects in the given pool.
 --inode, --min-inode, --max-inode
    Restrict listing to specific inode numbers.
 --min-offset, --max-offset
    Restrict listing to specific offsets inside inodes.
 ```
 ## fix
 `vitastor-cli fix [--objects <objects>] [--bad-osds <osds>] [--part <part>] [--check no]`
 Fix inconsistent objects in the cluster by deleting some copies.
 ```
 --objects <objects>
    Objects to fix, either in plain text or JSON format. If not specified,
    object list will be read from STDIN in one of the same formats.
    Plain text format: 0x<inode>:0x<stripe> <any delimiter> 0x<inode>:0x<stripe> ...
    JSON format: [{"inode":"0x...","stripe":"0x..."},...]
 --bad-osds <osds>
    Remove inconsistent copies/parts of objects from these OSDs, effectively
    marking them bad and allowing Vitastor to recover objects from other copies.
 --part <number>
    Only remove EC part <number> (from 0 to pg_size-1), required for extreme
    edge cases where one OSD has multiple parts of a EC object.
 --check no
    Do not recheck that requested objects are actually inconsistent,
    delete requested copies/parts anyway.
 ```
 ## alloc-osd
 `vitastor-cli alloc-osd`
--- a/docs/usage/cli.ru.md
+++ b/docs/usage/cli.ru.md
@ -15,7 +15,6 @@ vitastor-cli - интерфейс командной строки для адм
 - [df](#df)
 - [ls](#ls)
 - [create](#create)
 - [snap-create](#create)
 - [modify](#modify)
 - [rm](#rm)
 - [flatten](#flatten)
@ -27,8 +26,7 @@ vitastor-cli - интерфейс командной строки для адм
 Глобальные опции:
 ```
--config_file FILE   Путь к файлу конфигурации Vitastor
+--etcd_address ADDR  Адрес соединения с etcd
 --etcd_address URL   Адрес соединения с etcd
 --iodepth N          Отправлять параллельно N операций на каждый OSD (по умолчанию 32)
 --parallel_osds M    Работать параллельно с M OSD (по умолчанию 4)
 --progress 1|0       Печатать прогресс выполнения (по умолчанию 1)
@ -128,8 +126,6 @@ vitastor-cli snap-create [-p|--pool <id|name>] <image>@<snapshot>
 Создать снимок образа `<name>` (можно использовать любую форму команды). Снимок можно создавать без остановки
 клиентов, если пишущий клиент максимум 1.
 Смотрите также информацию о том, [как экспортировать снимки](qemu.ru.md#экспорт-снимков).
 ## modify
 `vitastor-cli modify <name> [--rename <new-name>] [--resize <size>] [--readonly | --readwrite] [-f|--force]`
@ -185,59 +181,6 @@ vitastor-cli snap-create [-p|--pool <id|name>] <image>@<snapshot>
 в целевой образ `<target>`. `<to>` должен быть дочерним образом `<from>`, а `<target>`
 должен быть одним из слоёв между `<from>` и `<to>`, включая сами `<from>` и `<to>`.
 ## describe
 `vitastor-cli describe [--osds <osds>] [--object-state <состояния>] [--pool <пул>]
    [--inode <номер>] [--min-inode <номер>] [--max-inode <номер>]
    [--min-offset <смещение>] [--max-offset <смещение>]`
 Описать состояние "грязных" объектов в кластере, то есть таких объектов, копии
 или части которых хранятся на наборе OSD, не равном целевому.
 ```
 --osds <osds>
    Перечислять только объекты с первичных OSD из списка <osds>.
 --object-state <состояния>
    Перечислять только объекты в указанных состояниях. Возможные состояния
    объектов:
    - degraded - деградированная избыточность
    - misplaced - перемещённый
    - incomplete - нечитаемый из-за потери большего числа частей, чем допустимо
    - corrupted - с одной или более повреждённой частью
    - inconsistent - неконсистентный, с неоднозначным расхождением копий/частей
 --pool <имя или ID пула>
    Перечислять только объекты из заданного пула.
 --inode, --min-inode, --max-inode
    Перечислять только объекты из указанных номеров инодов (образов).
 --min-offset, --max-offset
    Перечислять только объекты с заданных смещений внутри образов.
 ```
 ## fix
 `vitastor-cli fix [--objects <объекты>] [--bad-osds <osds>] [--part <номер>] [--check no]`
 Исправить неконсистентные (неоднозначные) объекты путём удаления части копий.
 ```
 --objects <объекты>
    Объекты для исправления - в простом текстовом или JSON формате. Если опция
    не указана, список объектов читается со стандартного ввода в тех же форматах.
    Простой формат: 0x<инод>:0x<смещение> <любой разделитель> 0x<инод>:0x<смещение> ...
    Формат JSON: [{"inode":"0x<инод>","stripe":"0x<смещение>"},...]
 --bad-osds <osds>
    Удалить неконсистентные копии/части объектов с данных OSD, таким образом
    признавая потерю этих копий и позволяя Vitastor-у восстановить объекты из
    других копий.
 --part <номер>
    Удалить только части EC с заданным номером (от 0 до pg_size-1). Нужно только
    в редких граничных случаях, когда один и тот же OSD содержит несколько частей
    одного EC-объекта.
 --check no
    Не перепроверять, что заданные объекты действительно в неконсистентном
    состоянии и просто удалять заданные части.
 ```
 ## alloc-osd
 `vitastor-cli alloc-osd`
--- a/docs/usage/disk.en.md
+++ b/docs/usage/disk.en.md
@ -1,4 +1,4 @@
-[Documentation](../../README.md#documentation) → Usage → Disk management tool
+[Documentation](../../README.md#documentation) → Usage → Disk Tool
 -----
@ -17,7 +17,6 @@ It supports the following commands:
 - [purge](#purge)
 - [read-sb](#read-sb)
 - [write-sb](#write-sb)
 - [update-sb](#update-sb)
 - [udev](#udev)
 - [exec-osd](#exec-osd)
 - [pre-exec](#pre-exec)
@ -87,8 +86,6 @@ Options (both modes):
 --journal_size 1G/32M      Set journal size (area or partition size)
 --block_size 1M/128k       Set blockstore object size
 --bitmap_granularity 4k    Set bitmap granularity
 --data_csum_type none      Set data checksum type (crc32c or none)
 --csum_block_size 4k       Set data checksum block size
 --data_device_block 4k     Override data device block size
 --meta_device_block 4k     Override metadata device block size
 --journal_device_block 4k  Override journal device block size
@ -103,9 +100,8 @@ checks the device cache status on start and tries to disable cache for SATA/SAS
 If it doesn't succeed it issues a warning in the system log.
 You can also pass other OSD options here as arguments and they'll be persisted
-in the superblock: cached_io_data, cached_io_meta, cached_io_journal,
+to the superblock: max_write_iodepth, max_write_iodepth, min_flusher_count,
-inmemory_metadata, inmemory_journal, max_write_iodepth,
+max_flusher_count, inmemory_metadata, inmemory_journal, journal_sector_buffer_count,
 min_flusher_count, max_flusher_count, journal_sector_buffer_count,
 journal_no_same_sector_overwrites, throttle_small_writes, throttle_target_iops,
 throttle_target_mbs, throttle_target_parallelism, throttle_threshold_us.
 See [Runtime OSD Parameters](../config/osd.en.md) for details.
@ -183,14 +179,6 @@ Try to read Vitastor OSD superblock from `<device>` and print it in JSON format.
 Read JSON from STDIN and write it into Vitastor OSD superblock on `<device>`.
 ## update-sb
 `vitastor-disk update-sb <device> [--force] [--<parameter> <value>] [...]`
 Read Vitastor OSD superblock from <device>, update parameters in it and write it back.
 `--force` allows to ignore validation errors.
 ## udev
 `vitastor-disk udev <device>`
@ -261,9 +249,7 @@ Options (see also [Cluster-Wide Disk Layout Parameters](../config/layout-cluster
 ```
 --object_size 128k       Set blockstore block size
 --bitmap_granularity 4k  Set bitmap granularity
--journal_size 16M       Set journal size
+--journal_size 32M       Set journal size
 --data_csum_type none    Set data checksum type (crc32c or none)
 --csum_block_size 4k     Set data checksum block size
 --device_block_size 4k   Set device block size
 --journal_offset 0       Set journal offset
 --device_size 0          Set device size
--- a/docs/usage/disk.ru.md
+++ b/docs/usage/disk.ru.md
@ -1,4 +1,4 @@
-[Документация](../../README-ru.md#документация) → Использование → Инструмент управления дисками
+[Документация](../../README-ru.md#документация) → Использование → Управление дисками
 -----
@ -17,7 +17,6 @@ vitastor-disk - инструмент командной строки для уп
 - [purge](#purge)
 - [read-sb](#read-sb)
 - [write-sb](#write-sb)
 - [update-sb](#update-sb)
 - [udev](#udev)
 - [exec-osd](#exec-osd)
 - [pre-exec](#pre-exec)
@ -88,8 +87,6 @@ vitastor-disk - инструмент командной строки для уп
 --journal_size 1G/32M      Задать размер журнала (области или раздела журнала)
 --block_size 1M/128k       Задать размер объекта хранилища
 --bitmap_granularity 4k    Задать гранулярность битовых карт
 --data_csum_type none      Задать тип контрольных сумм (crc32c или none)
 --csum_block_size 4k       Задать размер блока расчёта контрольных сумм
 --data_device_block 4k     Задать размер блока устройства данных
 --meta_device_block 4k     Задать размер блока метаданных
 --journal_device_block 4k  Задать размер блока журнала
@ -104,9 +101,8 @@ vitastor-disk - инструмент командной строки для уп
 это не удаётся, в системный журнал выводится предупреждение.
 Вы можете передать данной команде и некоторые другие опции OSD в качестве аргументов
-и они тоже будут сохранены в суперблок: cached_io_data, cached_io_meta,
+и они тоже будут сохранены в суперблок: max_write_iodepth, max_write_iodepth, min_flusher_count,
-cached_io_journal, inmemory_metadata, inmemory_journal, max_write_iodepth,
+max_flusher_count, inmemory_metadata, inmemory_journal, journal_sector_buffer_count,
 min_flusher_count, max_flusher_count, journal_sector_buffer_count,
 journal_no_same_sector_overwrites, throttle_small_writes, throttle_target_iops,
 throttle_target_mbs, throttle_target_parallelism, throttle_threshold_us.
 Читайте об этих параметрах подробнее в разделе [Изменяемые параметры OSD](../config/osd.ru.md).
@ -188,15 +184,6 @@ throttle_target_mbs, throttle_target_parallelism, throttle_threshold_us.
 Прочитать JSON со стандартного ввода и записать его в суперблок OSD на диск `<device>`.
 ## update-sb
 `vitastor-disk update-sb <device> [--force] [--<параметр> <значение>] [...]`
 Прочитать суперблок OSD с диска `<device>`, изменить в нём заданные параметры и записать обратно.
 Опция `--force` позволяет читать суперблок, даже если он считается некорректным
 из-за ошибок валидации.
 ## udev
 `vitastor-disk udev <device>`
@ -267,9 +254,7 @@ OSD отключены fsync-и.
 ```
 --object_size 128k       Размер блока хранилища
 --bitmap_granularity 4k  Гранулярность битовых карт
--journal_size 16M       Размер журнала
+--journal_size 32M       Размер журнала
 --data_csum_type none    Задать тип контрольных сумм (crc32c или none)
 --csum_block_size 4k     Задать размер блока расчёта контрольных сумм
 --device_block_size 4k   Размер блока устройства
 --journal_offset 0       Смещение журнала
 --device_size 0          Размер устройства
--- a/docs/usage/fio.en.md
+++ b/docs/usage/fio.en.md
@ -14,13 +14,10 @@ Vitastor has a fio driver which can be installed from the package vitastor-fio.
 Use the following command as an example to run tests with fio against a Vitastor cluster:
 ```
-fio -thread -ioengine=libfio_vitastor.so -name=test -bs=4M -direct=1 -iodepth=16 -rw=write -image=testimg
+fio -thread -ioengine=libfio_vitastor.so -name=test -bs=4M -direct=1 -iodepth=16 -rw=write -etcd=10.115.0.10:2379/v3 -image=testimg
 ```
 If you don't want to access your image by name, you can specify pool number, inode number and size
 (`-pool=1 -inode=1 -size=400G`) instead of the image name (`-image=testimg`).
-You can also specify etcd address(es) explicitly by adding `-etcd=10.115.0.10:2379/v3`, or you
+See exact fio commands to use for benchmarking [here](../performance/understanding.en.md#команды-fio).
 can override configuration file path by adding `-conf=/etc/vitastor/vitastor.conf`.
 See exact fio commands to use for benchmarking [here](../performance/understanding.en.md#fio-commands).
--- a/docs/usage/fio.ru.md
+++ b/docs/usage/fio.ru.md
@ -14,13 +14,10 @@
 Используйте следующую команду как пример для запуска тестов кластера Vitastor через fio:
 ```
-fio -thread -ioengine=libfio_vitastor.so -name=test -bs=4M -direct=1 -iodepth=16 -rw=write -image=testimg
+fio -thread -ioengine=libfio_vitastor.so -name=test -bs=4M -direct=1 -iodepth=16 -rw=write -etcd=10.115.0.10:2379/v3 -image=testimg
 ```
 Вместо обращения к образу по имени (`-image=testimg`) можно указать номер пула, номер инода и размер:
 `-pool=1 -inode=1 -size=400G`.
 Вы также можете задать адрес(а) подключения к etcd явно, добавив `-etcd=10.115.0.10:2379/v3`,
 или переопределить путь к файлу конфигурации, добавив `-conf=/etc/vitastor/vitastor.conf`.
 Конкретные команды fio для тестирования производительности можно посмотреть [здесь](../performance/understanding.ru.md#команды-fio).
--- a/docs/usage/nbd.en.md
+++ b/docs/usage/nbd.en.md
@ -11,42 +11,20 @@ NBD stands for "Network Block Device", but in fact it also functions as "BUSE"
 NBD slighly lowers the performance due to additional overhead, but performance still
 remains decent (see an example [here](../performance/comparison1.en.md#vitastor-0-4-0-nbd)).
-See also [VDUSE](qemu.en.md#vduse) as a better alternative to NBD.
+Vitastor Kubernetes CSI driver is based on NBD.
 Vitastor Kubernetes CSI driver uses NBD when VDUSE is unavailable.
 ## Map image
 To create a local block device for a Vitastor image run:
 ```
-vitastor-nbd map --image testimg
+vitastor-nbd map --etcd_address 10.115.0.10:2379/v3 --image testimg
 ```
 It will output a block device name like /dev/nbd0 which you can then use as a normal disk.
 You can also use `--pool <POOL> --inode <INODE> --size <SIZE>` instead of `--image <IMAGE>` if you want.
 vitastor-nbd supports all usual Vitastor configuration options like `--config_file <path_to_config>` plus NBD-specific:
 * `--nbd_timeout 300` \
  Timeout for I/O operations in seconds after exceeding which the kernel stops
  the device. You can set it to 0 to disable the timeout, but beware that you
  won't be able to stop the device at all if vitastor-nbd process dies.
 * `--nbd_max_devices 64 --nbd_max_part 3` \
  Options for the `nbd` kernel module when modprobing it (`nbds_max` and `max_part`).
  note that maximum allowed (nbds_max)*(1+max_part) is 256.
 * `--logfile /path/to/log/file.txt` \
  Write log messages to the specified file instead of dropping them (in background mode)
  or printing them to the standard output (in foreground mode).
 * `--dev_num N` \
  Use the specified device /dev/nbdN instead of automatic selection.
 * `--foreground 1` \
  Stay in foreground, do not daemonize.
 Note that `nbd_timeout`, `nbd_max_devices` and `nbd_max_part` options may also be specified
 in `/etc/vitastor/vitastor.conf` or in other configuration file specified with `--config_file`.
 ## Unmap image
 To unmap the device run:
@ -54,27 +32,3 @@ To unmap the device run:
 ```
 vitastor-nbd unmap /dev/nbd0
 ```
 ## List mapped images
 ```
 vitastor-nbd ls [--json]
 ```
 Example output (normal format):
 ```
 /dev/nbd0
 image: bench
 pid: 584536
 /dev/nbd1
 image: bench1
 pid: 584546
 ```
 Example output (JSON format):
 ```
 {"/dev/nbd0": {"image": "bench", "pid": 584536}, "/dev/nbd1": {"image": "bench1", "pid": 584546}}
 ```
--- a/docs/usage/nbd.ru.md
+++ b/docs/usage/nbd.ru.md
@ -14,16 +14,14 @@ NBD на данный момент необходимо, чтобы монтир
 NBD немного снижает производительность из-за дополнительных копирований памяти,
 но она всё равно остаётся на неплохом уровне (см. для примера [тест](../performance/comparison1.ru.md#vitastor-0-4-0-nbd)).
-Смотрите также [VDUSE](qemu.ru.md#vduse), как лучшую альтернативу NBD.
+CSI-драйвер Kubernetes Vitastor основан на NBD.
 CSI-драйвер Kubernetes Vitastor использует NBD, когда VDUSE недоступен.
 ## Подключить устройство
 Чтобы создать локальное блочное устройство для образа, выполните команду:
 ```
-vitastor-nbd map --image testimg
+vitastor-nbd map --etcd_address 10.115.0.10:2379/v3 --image testimg
 ```
 Команда напечатает название блочного устройства вида /dev/nbd0, которое потом можно
@ -32,32 +30,6 @@ vitastor-nbd map --image testimg
 Для обращения по номеру инода, аналогично другим командам, можно использовать опции
 `--pool <POOL> --inode <INODE> --size <SIZE>` вместо `--image testimg`.
 vitastor-nbd поддерживает все обычные опции Vitastor, например, `--config_file <path_to_config>`,
 плюс специфичные для NBD:
 * `--nbd_timeout 30` \
  Максимальное время выполнения любой операции чтения/записи в секундах, при
  превышении которого ядро остановит NBD-устройство. Вы можете установить опцию
  в 0, чтобы отключить ограничение времени, но имейте в виду, что в этом случае
  вы вообще не сможете отключить NBD-устройство при нештатном завершении процесса
  vitastor-nbd.
 * `--nbd_max_devices 64 --nbd_max_part 3` \
  Опции, передаваемые модулю ядра nbd, если его загружает vitastor-nbd
  (`nbds_max` и `max_part`). Имейте в виду, что (nbds_max)*(1+max_part)
  обычно не должно превышать 256.
 * `--logfile /path/to/log/file.txt` \
  Писать сообщения о процессе работы в заданный файл, вместо пропуска их
  при фоновом режиме запуска или печати на стандартный вывод при запуске
  в консоли с `--foreground 1`.
 * `--dev_num N` \
  Использовать заданное устройство `/dev/nbdN` вместо автоматического подбора.
 * `--foreground 1` \
  Не уводить процесс в фоновый режим.
 Обратите внимание, что опции `nbd_timeout`, `nbd_max_devices` и `nbd_max_part` можно
 также задавать в `/etc/vitastor/vitastor.conf` или в другом файле конфигурации,
 заданном опцией `--config_file`.
 ## Отключить устройство
 Для отключения устройства выполните:
@ -65,27 +37,3 @@ vitastor-nbd поддерживает все обычные опции Vitastor,
 ```
 vitastor-nbd unmap /dev/nbd0
 ```
 ## Вывести подключённые устройства
 ```
 vitastor-nbd ls [--json]
 ```
 Пример вывода в обычном формате:
 ```
 /dev/nbd0
 image: bench
 pid: 584536
 /dev/nbd1
 image: bench1
 pid: 584546
 ```
 Пример вывода в JSON-формате:
 ```
 {"/dev/nbd0": {"image": "bench", "pid": 584536}, "/dev/nbd1": {"image": "bench1", "pid": 584546}}
 ```
--- a/docs/usage/nfs.en.md
+++ b/docs/usage/nfs.en.md
@ -23,7 +23,7 @@ balancer or any failover method you want to in that case.
 vitastor-nfs usage:
 ```
-vitastor-nfs [STANDARD OPTIONS] [OTHER OPTIONS]
+vitastor-nfs [--etcd_address ADDR] [OTHER OPTIONS]
 --subdir <DIR>    export images prefixed <DIR>/ (default empty - export all images)
 --portmap 0       do not listen on port 111 (portmap/rpcbind, requires root)
@ -34,7 +34,7 @@ vitastor-nfs [STANDARD OPTIONS] [OTHER OPTIONS]
 --foreground 1    stay in foreground, do not daemonize
 ```
-Example start and mount commands (etcd_address is optional):
+Example start and mount commands:
 ```
 vitastor-nfs --etcd_address 192.168.5.10:2379 --portmap 0 --port 2050 --pool testpool
--- a/docs/usage/nfs.ru.md
+++ b/docs/usage/nfs.ru.md
@ -22,18 +22,18 @@
 Использование vitastor-nfs:
 ```
-vitastor-nfs [СТАНДАРТНЫЕ ОПЦИИ] [ДРУГИЕ ОПЦИИ]
+vitastor-nfs [--etcd_address ADDR] [ДРУГИЕ ОПЦИИ]
 --subdir <DIR>    экспортировать "поддиректорию" - образы с префиксом имени <DIR>/ (по умолчанию пусто - экспортировать все образы)
 --portmap 0       отключить сервис portmap/rpcbind на порту 111 (по умолчанию включён и требует root привилегий)
 --bind <IP>       принимать соединения по адресу <IP> (по умолчанию 0.0.0.0 - на всех)
 --nfspath <PATH>  установить путь NFS-экспорта в <PATH> (по умолчанию /)
 --port <PORT>     использовать порт <PORT> для NFS-сервисов (по умолчанию 2049)
--pool <POOL>     использовать пул <POOL> для новых образов (обязательно, если пул в кластере не один)
+--pool <POOL>     исползовать пул <POOL> для новых образов (обязательно, если пул в кластере не один)
 --foreground 1    не уходить в фон после запуска
 ```
-Пример монтирования Vitastor через NFS (etcd_address необязателен):
+Пример монтирования Vitastor через NFS:
 ```
 vitastor-nfs --etcd_address 192.168.5.10:2379 --portmap 0 --port 2050 --pool testpool
--- a/docs/usage/qemu.en.md
+++ b/docs/usage/qemu.en.md
@ -16,16 +16,13 @@ Old syntax (-drive):
 ```
 qemu-system-x86_64 -enable-kvm -m 1024 \
-    -drive 'file=vitastor:image=debian9',
+    -drive 'file=vitastor:etcd_host=192.168.7.2\:2379/v3:image=debian9',
        format=raw,if=none,id=drive-virtio-disk0,cache=none \
    -device 'virtio-blk-pci,scsi=off,bus=pci.0,addr=0x5,drive=drive-virtio-disk0,
        id=virtio-disk0,bootindex=1,write-cache=off' \
    -vnc 0.0.0.0:0
 ```
 Etcd address may be specified explicitly by adding `:etcd_host=192.168.7.2\:2379/v3` to `file=`.
 Configuration file path may be overriden by adding `:config_path=/etc/vitastor/vitastor.conf`.
 New syntax (-blockdev):
 ```
@ -37,157 +34,15 @@ qemu-system-x86_64 -enable-kvm -m 1024 \
    -vnc 0.0.0.0:0
 ```
 With a separate I/O thread:
 ```
 qemu-system-x86_64 -enable-kvm -m 1024 \
    -object iothread,id=vitastor1 \
    -blockdev '{"node-name":"drive-virtio-disk0","driver":"vitastor","image":"debian9",
        "cache":{"direct":true,"no-flush":false},"auto-read-only":true,"discard":"unmap"}' \
    -device 'virtio-blk-pci,iothread=vitastor1,scsi=off,bus=pci.0,addr=0x5,drive=drive-virtio-disk0,
        id=virtio-disk0,bootindex=1,write-cache=off' \
    -vnc 0.0.0.0:0
 ```
 You can also specify inode ID, pool and size manually instead of `:image=<IMAGE>` option: `:pool=<POOL>:inode=<INODE>:size=<SIZE>`.
 ## qemu-img
-For qemu-img, you should use `vitastor:image=<IMAGE>[:etcd_host=<HOST>]` as filename.
+For qemu-img, you should use `vitastor:etcd_host=<HOST>:image=<IMAGE>` as filename.
 For example, to upload a VM image into Vitastor, run:
 ```
-qemu-img convert -f qcow2 debian10.qcow2 -p -O raw 'vitastor:image=debian10'
+qemu-img convert -f qcow2 debian10.qcow2 -p -O raw 'vitastor:etcd_host=192.168.7.2\:2379/v3:image=debian10'
 ```
 You can also specify `:pool=<POOL>:inode=<INODE>:size=<SIZE>` instead of `:image=<IMAGE>`
 if you don't want to use inode metadata.
 ### Exporting snapshots
 Starting with 0.8.4, you can also export individual layers (snapshot diffs) using `qemu-img`.
 Suppose you have an image `testimg` and a snapshot `testimg@0` created with `vitastor-cli snap-create testimg@0`.
 Then you can export the `testimg@0` snapshot and the data written to `testimg` after creating
 the snapshot separately using the following commands (key points are using `skip-parents=1` and
 `-B backing_file` option):
 ```
 qemu-img convert -f raw 'vitastor:image=testimg@0' \
    -O qcow2 testimg_0.qcow2
 qemu-img convert -f raw 'vitastor:image=testimg:skip-parents=1' \
    -O qcow2 -o 'cluster_size=4k' -B testimg_0.qcow2 testimg.qcow2
 ```
 In fact, with `cluster_size=4k` any QCOW2 file can be used instead `-B testimg_0.qcow2`, even an empty one.
 QCOW2 `cluster_size=4k` option is required if you want `testimg.qcow2` to contain only the data
 overwritten  **exactly** in the child layer. With the default 64 KB QCOW2 cluster size you'll
 get a bit of extra data from parent layers, i.e. a 4 KB overwrite will result in `testimg.qcow2`
 containing 64 KB of data. And this extra data will be taken by `qemu-img` from the file passed
 in `-B` option, so you really need 4 KB cluster if you use an empty image in `-B`.
 After this procedure you'll get two chained QCOW2 images. To detach `testimg.qcow2` from
 its parent, run:
 ```
 qemu-img rebase -u -b '' testimg.qcow2
 ```
 This can be used for backups. Just note that exporting an image that is currently being written to
 is of course unsafe and doesn't produce a consistent result, so only export snapshots if you do this
 on a live VM.
 ## vhost-user-blk
 QEMU, starting with 6.0, includes support for attaching disks via a separate
 userspace worker process, called `vhost-user-blk`. It usually has slightly (20-30 us)
 lower latency.
 Example commands to use it with Vitastor:
 ```
 qemu-storage-daemon \
    --daemonize \
    --blockdev '{"node-name":"drive-virtio-disk1","driver":"vitastor","image":"testosd1","cache":{"direct":true,"no-flush":false},"auto-read-only":true,"discard":"unmap"}' \
    --export type=vhost-user-blk,id=vitastor1,node-name=drive-virtio-disk1,addr.type=unix,addr.path=/run/vitastor1-user-blk.sock,writable=on,num-queues=1
 qemu-system-x86_64 -enable-kvm -m 2048 -M accel=kvm,memory-backend=mem \
    -object memory-backend-memfd,id=mem,size=2G,share=on \
    -chardev socket,id=vitastor1,reconnect=1,path=/run/vitastor1-user-blk.sock \
    -device vhost-user-blk-pci,chardev=vitastor1,num-queues=1,config-wce=off \
    -vnc 0.0.0.0:0
 ```
 memfd memory-backend is crucial, vhost-user-blk does not work without it.
 ## VDUSE
 Linux kernel, starting with version 5.15, supports a new interface for attaching virtual disks
 to the host - VDUSE (vDPA Device in Userspace). QEMU, starting with 7.2, has support for
 exporting QEMU block devices over this protocol using qemu-storage-daemon.
 VDUSE is currently the best interface to attach Vitastor disks as kernel devices because:
 - It avoids data copies and thus achieves much better performance than [NBD](nbd.en.md)
 - It doesn't have NBD timeout problem - the device doesn't die if an operation executes for too long
 - It doesn't have hung device problem - if the userspace process dies it can be restarted (!)
  and block device will continue operation
 - It doesn't seem to have the device number limit
 Example performance comparison:
 |                      | direct fio  | NBD         | VDUSE       |
 |----------------------|-------------|-------------|-------------|
 | linear write         | 3.85 GB/s   | 1.12 GB/s   | 3.85 GB/s   |
 | 4k random write Q128 | 240000 iops | 120000 iops | 178000 iops |
 | 4k random write Q1   | 9500 iops   | 7620 iops   | 7640 iops   |
 | linear read          | 4.3 GB/s    | 1.8 GB/s    | 2.85 GB/s   |
 | 4k random read Q128  | 287000 iops | 140000 iops | 189000 iops |
 | 4k random read Q1    | 9600 iops   | 7640 iops   | 7780 iops   |
 To try VDUSE you need at least Linux 5.15, built with VDUSE support
 (CONFIG_VDPA=m, CONFIG_VDPA_USER=m, CONFIG_VIRTIO_VDPA=m).
 Debian Linux kernels have these options disabled by now, so if you want to try it on Debian,
 use a kernel from Ubuntu [kernel-ppa/mainline](https://kernel.ubuntu.com/~kernel-ppa/mainline/), Proxmox,
 or build modules for Debian kernel manually:
 ```
 mkdir build
 cd build
 apt-get install linux-headers-`uname -r`
 apt-get build-dep linux-image-`uname -r`-unsigned
 apt-get source linux-image-`uname -r`-unsigned
 cd linux*/drivers/vdpa
 make -C /lib/modules/`uname -r`/build M=$PWD CONFIG_VDPA=m CONFIG_VDPA_USER=m CONFIG_VIRTIO_VDPA=m -j8 modules modules_install
 cat Module.symvers >> /lib/modules/`uname -r`/build/Module.symvers
 cd ../virtio
 make -C /lib/modules/`uname -r`/build M=$PWD CONFIG_VDPA=m CONFIG_VDPA_USER=m CONFIG_VIRTIO_VDPA=m -j8 modules modules_install
 depmod -a
 ```
 You also need `vdpa` tool from the `iproute2` package.
 Commands to attach Vitastor image as a VDUSE device:
 ```
 modprobe vduse
 modprobe virtio-vdpa
 qemu-storage-daemon --daemonize --blockdev '{"node-name":"test1","driver":"vitastor",\
  "etcd-host":"192.168.7.2:2379/v3","image":"testosd1","cache":{"direct":true,"no-flush":false},"discard":"unmap"}' \
  --export vduse-blk,id=test1,node-name=test1,name=test1,num-queues=16,queue-size=128,writable=true
 vdpa dev add name test1 mgmtdev vduse
 ```
 After running these commands, `/dev/vda` device will appear in the system and you'll be able to
 use it as a normal disk.
 To remove the device:
 ```
 vdpa dev del test1
 kill <qemu-storage-daemon_process_PID>
 ```
--- a/docs/usage/qemu.ru.md
+++ b/docs/usage/qemu.ru.md
@ -18,16 +18,13 @@
 ```
 qemu-system-x86_64 -enable-kvm -m 1024 \
-    -drive 'file=vitastor:image=debian9',
+    -drive 'file=vitastor:etcd_host=192.168.7.2\:2379/v3:image=debian9',
        format=raw,if=none,id=drive-virtio-disk0,cache=none \
    -device 'virtio-blk-pci,scsi=off,bus=pci.0,addr=0x5,drive=drive-virtio-disk0,
        id=virtio-disk0,bootindex=1,write-cache=off' \
    -vnc 0.0.0.0:0
 ```
 Адрес подключения etcd можно задать явно, если добавить `:etcd_host=192.168.7.2\:2379/v3` к `file=`.
 Путь к файлу конфигурации можно переопределить, добавив `:config_path=/etc/vitastor/vitastor.conf`.
 Новый синтаксис (-blockdev):
 ```
@ -39,158 +36,17 @@ qemu-system-x86_64 -enable-kvm -m 1024 \
    -vnc 0.0.0.0:0
 ```
 С отдельным потоком ввода-вывода:
 ```
 qemu-system-x86_64 -enable-kvm -m 1024 \
    -object iothread,id=vitastor1 \
    -blockdev '{"node-name":"drive-virtio-disk0","driver":"vitastor","image":"debian9",
        "cache":{"direct":true,"no-flush":false},"auto-read-only":true,"discard":"unmap"}' \
    -device 'virtio-blk-pci,iothread=vitastor1,scsi=off,bus=pci.0,addr=0x5,drive=drive-virtio-disk0,
        id=virtio-disk0,bootindex=1,write-cache=off' \
    -vnc 0.0.0.0:0
 ```
 Вместо `:image=<IMAGE>` также можно указывать номер инода, пул и размер: `:pool=<POOL>:inode=<INODE>:size=<SIZE>`.
 ## qemu-img
-Для qemu-img используйте строку `vitastor:image=<IMAGE>[:etcd_host=<HOST>]` в качестве имени файла диска.
+Для qemu-img используйте строку `vitastor:etcd_host=<HOST>:image=<IMAGE>` в качестве имени файла диска.
 Например, чтобы загрузить образ диска в Vitastor:
 ```
-qemu-img convert -f qcow2 debian10.qcow2 -p -O raw 'vitastor:image=testimg'
+qemu-img convert -f qcow2 debian10.qcow2 -p -O raw 'vitastor:etcd_host=10.115.0.10\:2379/v3:image=testimg'
 ```
 Если вы не хотите обращаться к образу по имени, вместо `:image=<IMAGE>` можно указать номер пула, номер инода и размер:
 `:pool=<POOL>:inode=<INODE>:size=<SIZE>`.
 ### Экспорт снимков
 Начиная с 0.8.4 вы можете экспортировать отдельные слои (изменения в снимках) с помощью `qemu-img`.
 Допустим, что у вас есть образ `testimg` и его снимок `testimg@0`, созданный с помощью `vitastor-cli snap-create testimg@0`.
 Тогда вы можете выгрузить снимок `testimg@0` и данные, изменённые в `testimg` после создания снимка, отдельно,
 с помощью следующих команд (ключевые моменты - использование `skip-parents=1` и опции `-B backing_file.qcow2`):
 ```
 qemu-img convert -f raw 'vitastor:image=testimg@0' \
    -O qcow2 testimg_0.qcow2
 qemu-img convert -f raw 'vitastor:image=testimg:skip-parents=1' \
    -O qcow2 -o 'cluster_size=4k' -B testimg_0.qcow2 testimg.qcow2
 ```
 На самом деле, с `cluster_size=4k` вместо `-B testimg_0.qcow2` можно использовать любой qcow2-файл,
 даже пустой.
 Опция QCOW2 `cluster_size=4k` нужна, если вы хотите, чтобы `testimg.qcow2` содержал **в точности**
 данные, перезаписанные в дочернем слое. С размером кластера QCOW2 по умолчанию, составляющим 64 КБ,
 вы получите немного "лишних" данных из родительских слоёв - перезапись 4 КБ будет приводить к тому,
 что в `testimg.qcow2` будет появляться 64 КБ данных. Причём "лишние" данные qemu-img будет брать
 как раз из файла, указанного в опции `-B`, так что если там указан пустой образ, кластер обязан быть 4 КБ.
 После данной процедуры вы получите два QCOW2-образа, связанных в цепочку. Чтобы "отцепить" образ
 `testimg.qcow2` от базового, выполните:
 ```
 qemu-img rebase -u -b '' testimg.qcow2
 ```
 Это можно использовать для резервного копирования. Только помните, что экспортировать образ, в который
 в то же время идёт запись, небезопасно - результат чтения не будет целостным. Так что если вы работаете
 с активными виртуальными машинами, экспортируйте только их снимки, но не сам образ.
 ## vhost-user-blk
 QEMU, начиная с 6.0, позволяет подключать диски через отдельный рабочий процесс.
 Этот метод подключения называется `vhost-user-blk` и обычно имеет чуть меньшую
 задержку (ниже на 20-30 микросекунд, чем при обычном методе).
 Пример команд для использования vhost-user-blk с Vitastor:
 ```
 qemu-storage-daemon \
    --daemonize \
    --blockdev '{"node-name":"drive-virtio-disk1","driver":"vitastor","image":"testosd1","cache":{"direct":true,"no-flush":false},"auto-read-only":true,"discard":"unmap"}' \
    --export type=vhost-user-blk,id=vitastor1,node-name=drive-virtio-disk1,addr.type=unix,addr.path=/run/vitastor1-user-blk.sock,writable=on,num-queues=1
 qemu-system-x86_64 -enable-kvm -m 2048 -M accel=kvm,memory-backend=mem \
    -object memory-backend-memfd,id=mem,size=2G,share=on \
    -chardev socket,id=vitastor1,reconnect=1,path=/run/vitastor1-user-blk.sock \
    -device vhost-user-blk-pci,chardev=vitastor1,num-queues=1,config-wce=off \
    -vnc 0.0.0.0:0
 ```
 Здесь критична опция memory-backend-memfd, vhost-user-blk без неё не работает.
 ## VDUSE
 В Linux, начиная с версии ядра 5.15, доступен новый интерфейс для подключения виртуальных дисков
 к системе - VDUSE (vDPA Device in Userspace), а в QEMU, начиная с версии 7.2, есть поддержка
 экспорта блочных устройств QEMU по этому протоколу через qemu-storage-daemon.
 VDUSE - на данный момент лучший интерфейс для подключения дисков Vitastor в виде блочных
 устройств на уровне ядра, ибо:
 - VDUSE не копирует данные и поэтому достигает значительно лучшей производительности, чем [NBD](nbd.ru.md)
 - Также оно не имеет проблемы NBD-таймаута - устройство не умирает, если операция выполняется слишком долго
 - Также оно не имеет проблемы подвисающих устройств - если процесс-обработчик умирает, его можно
  перезапустить (!) и блочное устройство продолжит работать
 - По-видимому, у него нет предела числа подключаемых в систему устройств
 Пример сравнения производительности:
 |                          | Прямой fio  | NBD         | VDUSE       |
 |--------------------------|-------------|-------------|-------------|
 | линейная запись          | 3.85 GB/s   | 1.12 GB/s   | 3.85 GB/s   |
 | 4k случайная запись Q128 | 240000 iops | 120000 iops | 178000 iops |
 | 4k случайная запись Q1   | 9500 iops   | 7620 iops   | 7640 iops   |
 | линейное чтение          | 4.3 GB/s    | 1.8 GB/s    | 2.85 GB/s   |
 | 4k случайное чтение Q128 | 287000 iops | 140000 iops | 189000 iops |
 | 4k случайное чтение Q1   | 9600 iops   | 7640 iops   | 7780 iops   |
 Чтобы попробовать VDUSE, вам нужно ядро Linux как минимум версии 5.15, собранное с поддержкой
 VDUSE (CONFIG_VDPA=m, CONFIG_VDPA_USER=m, CONFIG_VIRTIO_VDPA=m).
 В ядрах в Debian Linux поддержка пока отключена по умолчанию, так что чтобы попробовать VDUSE
 на Debian, поставьте ядро из Ubuntu [kernel-ppa/mainline](https://kernel.ubuntu.com/~kernel-ppa/mainline/),
 из Proxmox или соберите модули для ядра Debian вручную:
 ```
 mkdir build
 cd build
 apt-get install linux-headers-`uname -r`
 apt-get build-dep linux-image-`uname -r`-unsigned
 apt-get source linux-image-`uname -r`-unsigned
 cd linux*/drivers/vdpa
 make -C /lib/modules/`uname -r`/build M=$PWD CONFIG_VDPA=m CONFIG_VDPA_USER=m CONFIG_VIRTIO_VDPA=m -j8 modules modules_install
 cat Module.symvers >> /lib/modules/`uname -r`/build/Module.symvers
 cd ../virtio
 make -C /lib/modules/`uname -r`/build M=$PWD CONFIG_VDPA=m CONFIG_VDPA_USER=m CONFIG_VIRTIO_VDPA=m -j8 modules modules_install
 depmod -a
 ```
 Также вам понадобится консольная утилита `vdpa` из пакета `iproute2`.
 Команды для подключения виртуального диска через VDUSE:
 ```
 modprobe vduse
 modprobe virtio-vdpa
 qemu-storage-daemon --daemonize --blockdev '{"node-name":"test1","driver":"vitastor",\
  "etcd-host":"192.168.7.2:2379/v3","image":"testosd1","cache":{"direct":true,"no-flush":false},"discard":"unmap"}' \
  --export vduse-blk,id=test1,node-name=test1,name=test1,num-queues=16,queue-size=128,writable=true
 vdpa dev add name test1 mgmtdev vduse
 ```
 После этого в системе появится устройство `/dev/vda`, которое можно будет использовать как
 обычный диск.
 Для удаления устройства из системы:
 ```
 vdpa dev del test1
 kill <PID_процесса_qemu-storage-daemon>
 ```
--- a/2
+++ b/2
@ -1 +1 @@
-Subproject commit fd37016cf85075303de74bab9c61e5d13bf71f64
+Subproject commit 52a3af664f40775426b189c85b6088d436d05df3
--- a/mon/90-vitastor.rules
+++ b/mon/90-vitastor.rules
@ -3,5 +3,5 @@ SUBSYSTEM=="block", ENV{ID_PART_ENTRY_TYPE}=="e7009fac-a5a1-4d72-af72-53de130599
    IMPORT{program}="/usr/bin/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=="add", RUN{program}+="/usr/bin/systemctl enable --now 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}"
+ENV{VITASTOR_OSD_NUM}!="", ACTION=="remove", RUN{program}+="/usr/bin/systemctl disable --now vitastor-osd@$env{VITASTOR_OSD_NUM}"
--- a/mon/PGUtil.js
+++ b/mon/PGUtil.js
@ -3,7 +3,6 @@
 module.exports = {
    scale_pg_count,
    scale_pg_history,
 };
 function add_pg_history(new_pg_history, new_pg, prev_pgs, prev_pg_history, old_pg)
@ -44,11 +43,9 @@ function finish_pg_history(merged_history)
    merged_history.all_peers = Object.values(merged_history.all_peers);
 }
-function scale_pg_history(prev_pg_history, prev_pgs, new_pgs)
+function scale_pg_count(prev_pgs, prev_pg_history, new_pg_history, new_pg_count)
 {
    const new_pg_history = [];
    const old_pg_count = prev_pgs.length;
    const new_pg_count = new_pgs.length;
    // Add all possibly intersecting PGs to the history of new PGs
    if (!(new_pg_count % old_pg_count))
    {
@ -92,22 +89,16 @@ function scale_pg_history(prev_pg_history, prev_pgs, new_pgs)
    {
        new_pg_history[i] = null;
    }
    return new_pg_history;
 }
 function scale_pg_count(prev_pgs, new_pg_count)
 {
    const old_pg_count = prev_pgs.length;
    // Just for the lp_solve optimizer - pick a "previous" PG for each "new" one
-    if (prev_pgs.length < new_pg_count)
+    if (old_pg_count < new_pg_count)
    {
-        for (let i = prev_pgs.length; i < new_pg_count; i++)
+        for (let i = old_pg_count; i < new_pg_count; i++)
        {
-            prev_pgs[i] = prev_pgs[i % prev_pgs.length];
+            prev_pgs[i] = prev_pgs[i % old_pg_count];
        }
    }
-    else if (prev_pgs.length > new_pg_count)
+    else if (old_pg_count > new_pg_count)
    {
-        prev_pgs.splice(new_pg_count, prev_pgs.length-new_pg_count);
+        prev_pgs.splice(new_pg_count, old_pg_count-new_pg_count);
    }
 }
--- a/Show More
+++ b/Show More
		`@ -1 +1 @@`
			`Subproject commit 8de8b467acbca50cfd8835c20e0e379110f3b32b`				`Subproject commit 45e6d1f13196a0824e2089a586c53b9de0283f17`
`@ -1,4 +1,4 @@`
	`VERSION ?= v1.4.4`	`VERSION ?= v0.8.3`

	`all: build push`	`all: build push`
		`@ -1 +1 @@`
			`Subproject commit fd37016cf85075303de74bab9c61e5d13bf71f64`				`Subproject commit 52a3af664f40775426b189c85b6088d436d05df3`