Trigger event loop more intelligently and automatically in libvitastor_c

.gitea/workflows/buildenv.Dockerfile

@@ -1,29 +1,28 @@
-FROM node:16-bookworm
+FROM node:16-bullseye
 
 WORKDIR /root
 
-ADD ./docker/etc/apt/trusted.gpg.d /etc/apt/trusted.gpg.d
+ADD ./docker/vitastor.gpg /etc/apt/trusted.gpg.d
 
-RUN echo 'deb http://deb.debian.org/debian bookworm-backports main' >> /etc/apt/sources.list; \
-    echo 'deb http://vitastor.io/debian bookworm main' >> /etc/apt/sources.list; \
+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 n=bookworm-backports' >> /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; \
-    perl -i -pe 's/Types: deb$/Types: deb deb-src/' /etc/apt/sources.list.d/debian.sources; \
     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 libasan8 \
-    libgoogle-perftools-dev devscripts libjerasure-dev cmake libibverbs-dev libisal-dev
+RUN apt-get -y install etcd qemu-system-x86 qemu-block-extra qemu-utils fio libasan5 \
+    liburing1 liburing-dev libgoogle-perftools-dev devscripts libjerasure-dev cmake libibverbs-dev libisal-dev
 RUN apt-get -y build-dep fio qemu=`dpkg -s qemu-system-x86|grep ^Version:|awk '{print $2}'`
-RUN apt-get update && apt-get -y install jq lp-solve sudo nfs-common fdisk parted libc-ares-dev udev iproute2
+RUN apt-get update && apt-get -y install jq lp-solve sudo nfs-common fdisk parted
 RUN apt-get --download-only source fio qemu=`dpkg -s qemu-system-x86|grep ^Version:|awk '{print $2}'`
 
 RUN set -ex; \

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

@@ -38,18 +38,6 @@ for my $line (<>)
             {
                 $test_name .= '_antietcd';
             }
-            elsif ($1 eq 'ETCD_SCHEME' && $2 eq 'https')
-            {
-                $test_name .= '_https';
-            }
-            elsif ($1 eq 'ENCRYPTED')
-            {
-                $test_name .= '_encrypted';
-            }
-            elsif ($1 eq 'OLD')
-            {
-                $test_name =~ s/^test_/test_old_/s;
-            }
             else
             {
                 $test_name .= '_'.lc($1).'_'.$2;

.gitignore

@@ -3,4 +3,3 @@
 package-lock.json
 fio
 qemu
-node_modules

CMakeLists.txt

@@ -1,20 +1,7 @@
-cmake_minimum_required(VERSION 2.8...3.30)
+cmake_minimum_required(VERSION 2.8.12)
 
 project(vitastor)
 
-set(VITASTOR_VERSION "3.2.2")
+set(VITASTOR_VERSION "1.11.0")
 
-include(CTest)
-
-add_custom_target(build_tests)
-set_property(TEST PROPERTY ENVIRONMENT LSAN_OPTIONS=suppressions=${CMAKE_CURRENT_BINARY_DIR}/lsan-suppress.txt)
-add_test(gen_lsan_suppress
-    ${CMAKE_COMMAND} -E echo leak:tcmalloc > "${CMAKE_CURRENT_BINARY_DIR}/lsan-suppress.txt"
-)
-set_tests_properties(gen_lsan_suppress PROPERTIES FIXTURES_SETUP f_lsan_suppress)
-set_property(TEST PROPERTY FIXTURES_REQUIRED f_lsan_suppress)
-# make -j16 -C ../../build test_heap && ../../build/src/test/test_heap
-# make -j16 -C ../../build test_heap && rm -f $(find ../../build -name '*.gcda') && ctest -V -T test -T coverage -R heap --test-dir ../../build && (cd ../../build; gcovr -f ../src --html --html-nested -o coverage/index.html; cd ../src/test)
-# make -j16 -C ../../build test_blockstore && rm -f $(find ../../build -name '*.gcda') && ctest -V -T test -T coverage -R blockstore --test-dir ../../build && (cd ../../build; gcovr -f ../src --html --html-nested -o coverage/index.html; cd ../src/test)
-# kcov --include-path=../../../src ../../kcov ./test_blockstore
 add_subdirectory(src)

README-ru.md

@@ -6,7 +6,7 @@
 
 Вернём былую скорость кластерному блочному хранилищу!
 
-Vitastor - распределённая блочная, файловая и объектная SDS (программная СХД), прямой аналог Ceph RBD, CephFS и RGW,
+Vitastor - распределённая блочная и файловая SDS (программная СХД), прямой аналог Ceph RBD и CephFS,
 а также внутренних СХД популярных облачных провайдеров. Однако, в отличие от них, Vitastor
 быстрый и при этом простой. Только пока маленький :-).
 
@@ -19,22 +19,18 @@ Vitastor нацелен в первую очередь на SSD и SSD+HDD кл
 TCP и RDMA и на хорошем железе может достигать задержки 4 КБ чтения и записи на уровне ~0.1 мс,
 что примерно в 10 раз быстрее, чем Ceph и другие популярные программные СХД.
 
-Vitastor поддерживает QEMU-драйвер, протоколы UBLK, NBD и NFS, драйверы OpenStack, OpenNebula, Proxmox, Kubernetes.
+Vitastor поддерживает QEMU-драйвер, протоколы NBD и NFS, драйверы OpenStack, OpenNebula, Proxmox, Kubernetes.
 Другие драйверы могут также быть легко реализованы.
 
 Подробности смотрите в документации по ссылкам. Можете начать отсюда: [Быстрый старт](docs/intro/quickstart.ru.md).
 
 ## Презентации и записи докладов
 
-- KuberConf'2025: [видео](https://vitastor.io/presentation/kuberconf.webm)
-- Highload'2025: [видео](https://vitastor.io/presentation/hl2025/hl2025.webm),
-  [на youtube](https://www.youtube.com/watch?v=0R8MLjFtz7g), презентация
-  ([на русском](https://vitastor.io/presentation/hl2025/), [на английском](https://vitastor.io/presentation/hl2025/en.html))
-- Highload'2022: презентация ([на русском](https://vitastor.io/presentation/highload/highload.html)),
-  [видео](https://vitastor.io/presentation/highload/talk.webm)
 - DevOpsConf'2021: презентация ([на русском](https://vitastor.io/presentation/devopsconf/devopsconf.html),
   [на английском](https://vitastor.io/presentation/devopsconf/devopsconf_en.html)),
   [видео](https://vitastor.io/presentation/devopsconf/talk.webm)
+- Highload'2022: презентация ([на русском](https://vitastor.io/presentation/highload/highload.html)),
+  [видео](https://vitastor.io/presentation/highload/talk.webm)
 
 ## Документация
 
@@ -50,7 +46,6 @@ Vitastor поддерживает QEMU-драйвер, протоколы UBLK,
   - [OpenNebula](docs/installation/opennebula.ru.md)
   - [OpenStack](docs/installation/openstack.ru.md)
   - [Kubernetes CSI](docs/installation/kubernetes.ru.md)
-  - [S3](docs/installation/s3.ru.md)
   - [Сборка из исходных кодов](docs/installation/source.ru.md)
 - Конфигурация
   - [Обзор](docs/config.ru.md)
@@ -62,18 +57,15 @@ Vitastor поддерживает QEMU-драйвер, протоколы UBLK,
     - [Дисковые параметры OSD](docs/config/layout-osd.ru.md)
     - [Прочие параметры OSD](docs/config/osd.ru.md)
     - [Параметры мониторов](docs/config/monitor.ru.md)
-    - [Безопасность](docs/config/security.ru.md)
   - [Настройки пулов](docs/config/pool.ru.md)
   - [Метаданные образов в etcd](docs/config/inode.ru.md)
 - Использование
   - [vitastor-cli](docs/usage/cli.ru.md) (консольный интерфейс)
   - [vitastor-disk](docs/usage/disk.ru.md) (управление дисками)
   - [fio](docs/usage/fio.ru.md) для тестов производительности
-  - [UBLK](docs/usage/ublk.ru.md) для монтирования ядром
-  - [NBD](docs/usage/nbd.ru.md) - старый интерфейс для монтирования ядром
-  - [QEMU, qemu-img и VDUSE](docs/usage/qemu.ru.md)
+  - [NBD](docs/usage/nbd.ru.md) для монтирования ядром
+  - [QEMU и qemu-img](docs/usage/qemu.ru.md)
   - [NFS](docs/usage/nfs.ru.md) кластерная файловая система и псевдо-ФС прокси
-  - [Безопасность](docs/usage/security.ru.md)
   - [Администрирование](docs/usage/admin.ru.md)
 - Производительность
   - [Понимание сути производительности](docs/performance/understanding.ru.md)

README.md

@@ -6,7 +6,7 @@
 
 Make Clustered Block Storage Fast Again.
 
-Vitastor is a distributed block, file and object SDS, direct replacement of Ceph RBD, CephFS and RGW,
+Vitastor is a distributed block and file SDS, direct replacement of Ceph RBD and CephFS,
 and also internal SDS's of public clouds. However, in contrast to them, Vitastor is fast
 and simple at the same time. The only thing is it's slightly young :-).
 
@@ -19,22 +19,18 @@ supports TCP and RDMA and may achieve 4 KB read and write latency as low as ~0.1
 with proper hardware which is ~10 times faster than other popular SDS's like Ceph
 or internal systems of public clouds.
 
-Vitastor supports QEMU, UBLK, NBD, NFS protocols, OpenStack, OpenNebula, Proxmox, Kubernetes drivers.
+Vitastor supports QEMU, NBD, NFS protocols, OpenStack, OpenNebula, Proxmox, Kubernetes drivers.
 More drivers may be created easily.
 
 Read more details in the documentation. You can start from here: [Quick Start](docs/intro/quickstart.en.md).
 
 ## Talks and presentations
 
-- KuberConf'2025: [video](https://vitastor.io/presentation/kuberconf.webm)
-- Highload'2025: [video](https://vitastor.io/presentation/hl2025/hl2025.webm),
-  [youtube](https://www.youtube.com/watch?v=0R8MLjFtz7g), presentation
-  ([in Russian](https://vitastor.io/presentation/hl2025/), [in English](https://vitastor.io/presentation/hl2025/en.html))
-- Highload'2022: presentation ([in Russian](https://vitastor.io/presentation/highload/highload.html)),
-  [video](https://vitastor.io/presentation/highload/talk.webm)
 - DevOpsConf'2021: presentation ([in Russian](https://vitastor.io/presentation/devopsconf/devopsconf.html),
   [in English](https://vitastor.io/presentation/devopsconf/devopsconf_en.html)),
   [video](https://vitastor.io/presentation/devopsconf/talk.webm)
+- Highload'2022: presentation ([in Russian](https://vitastor.io/presentation/highload/highload.html)),
+  [video](https://vitastor.io/presentation/highload/talk.webm)
 
 ## Documentation
 
@@ -50,7 +46,6 @@ Read more details in the documentation. You can start from here: [Quick Start](d
   - [OpenNebula](docs/installation/opennebula.en.md)
   - [OpenStack](docs/installation/openstack.en.md)
   - [Kubernetes CSI](docs/installation/kubernetes.en.md)
-  - [S3](docs/installation/s3.en.md)
   - [Building from Source](docs/installation/source.en.md)
 - Configuration
   - [Overview](docs/config.en.md)
@@ -62,18 +57,15 @@ Read more details in the documentation. You can start from here: [Quick Start](d
     - [OSD Disk Layout](docs/config/layout-osd.en.md)
     - [OSD Runtime Parameters](docs/config/osd.en.md)
     - [Monitor](docs/config/monitor.en.md)
-    - [Security](docs/config/security.en.md)
   - [Pool configuration](docs/config/pool.en.md)
   - [Image metadata in etcd](docs/config/inode.en.md)
 - Usage
   - [vitastor-cli](docs/usage/cli.en.md) (command-line interface)
   - [vitastor-disk](docs/usage/disk.en.md) (disk management tool)
   - [fio](docs/usage/fio.en.md) for benchmarks
-  - [UBLK](docs/usage/ublk.en.md) for kernel mounts
-  - [NBD](docs/usage/nbd.en.md) - old interface for kernel mounts
-  - [QEMU, qemu-img and VDUSE](docs/usage/qemu.en.md)
+  - [NBD](docs/usage/nbd.en.md) for kernel mounts
+  - [QEMU and qemu-img](docs/usage/qemu.en.md)
   - [NFS](docs/usage/nfs.en.md) clustered file system and pseudo-FS proxy
-  - [Security](docs/usage/security.en.md)
   - [Administration](docs/usage/admin.en.md)
 - Performance
   - [Understanding storage performance](docs/performance/understanding.en.md)

csi/Dockerfile

@@ -1,5 +1,5 @@
 # Compile stage
-FROM golang:trixie AS build
+FROM golang:bookworm AS build
 
 ADD go.sum go.mod /app/
 RUN cd /app; CGO_ENABLED=1 GOOS=linux GOARCH=amd64 go mod download -x
@@ -9,7 +9,7 @@ RUN perl -i -e '$/ = undef; while(<>) { s/\n\s*(\{\s*\n)/$1\n/g; s/\}(\s*\n\s*)e
     CGO_ENABLED=1 GOOS=linux GOARCH=amd64 go build -o vitastor-csi
 
 # Final stage
-FROM debian:trixie
+FROM debian:bookworm
 
 LABEL maintainers="Vitaliy Filippov <vitalif@yourcmc.ru>"
 LABEL description="Vitastor CSI Driver"
@@ -25,20 +25,20 @@ RUN apt-get update && \
         # NFS mount dependencies
         nfs-common netbase \
         # dependencies of qemu-storage-daemon
-        libaio1t64 libc6 libfuse3-4 libglib2.0-0t64 libgmp10 libgnutls30t64 \
-        libhogweed6t64 libnettle8t64 libnuma1 libselinux1 liburing2 libzstd1 zlib1g && \
+        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 trixie main > /etc/apt/sources.list.d/vitastor.list) && \
+RUN (echo deb http://vitastor.io/debian bookworm main > /etc/apt/sources.list.d/vitastor.list) && \
     ((echo 'Package: *'; echo 'Pin: origin "vitastor.io"'; echo 'Pin-Priority: 1000') > /etc/apt/preferences.d/vitastor.pref) && \
     wget -q -O /etc/apt/trusted.gpg.d/vitastor.gpg https://vitastor.io/debian/pubkey.gpg && \
     apt-get update && \
-    apt-get install -y vitastor-client ibverbs-providers && \
-    wget https://vitastor.io/archive/qemu/qemu-trixie-10.0.11%2Bds-0%2Bdeb13u1%2Bvitastor2/qemu-utils_10.0.11%2Bds-0%2Bdeb13u1%2Bvitastor2_amd64.deb && \
-    wget https://vitastor.io/archive/qemu/qemu-trixie-10.0.11%2Bds-0%2Bdeb13u1%2Bvitastor2/qemu-block-extra_10.0.11%2Bds-0%2Bdeb13u1%2Bvitastor2_amd64.deb && \
+    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/ && \

csi/Dockerfile.local

@@ -1,49 +0,0 @@
-# Compile stage
-FROM golang:trixie AS build
-
-ADD go.sum go.mod /app/
-RUN cd /app; CGO_ENABLED=1 GOOS=linux GOARCH=amd64 go mod download -x
-ADD . /app
-RUN perl -i -e '$/ = undef; while(<>) { s/\n\s*(\{\s*\n)/$1\n/g; s/\}(\s*\n\s*)else\b/$1} else/g; print; }' `find /app -name '*.go'` && \
-    cd /app && \
-    CGO_ENABLED=1 GOOS=linux GOARCH=amd64 go build -o vitastor-csi
-
-# Final stage
-FROM debian:trixie
-
-LABEL maintainers="Vitaliy Filippov <vitalif@yourcmc.ru>"
-LABEL description="Vitastor CSI Driver"
-
-ENV NODE_ID=""
-ENV CSI_ENDPOINT=""
-
-RUN apt-get update && \
-    apt-get install -y wget && \
-    (echo "APT::Install-Recommends false;" > /etc/apt/apt.conf) && \
-    apt-get update && \
-    apt-get install -y e2fsprogs xfsprogs kmod iproute2 \
-        # NFS mount dependencies
-        nfs-common netbase \
-        # dependencies of qemu-storage-daemon
-        libaio1t64 libc6 libfuse3-4 libglib2.0-0t64 libgmp10 libgnutls30t64 \
-        libhogweed6t64 libnettle8t64 libnuma1 libselinux1 liburing2 libzstd1 zlib1g && \
-    apt-get clean && \
-    (echo options nbd nbds_max=128 > /etc/modprobe.d/nbd.conf)
-
-COPY --from=build /app/vitastor-csi /bin/
-
-ADD deb /deb
-
-RUN apt-get update && \
-    apt-get -y install /deb/vitastor-client_*.deb && \
-    wget https://vitastor.io/archive/qemu/qemu-trixie-10.0.11%2Bds-0%2Bdeb13u1%2Bvitastor2/qemu-utils_10.0.11%2Bds-0%2Bdeb13u1%2Bvitastor2_amd64.deb && \
-    wget https://vitastor.io/archive/qemu/qemu-trixie-10.0.11%2Bds-0%2Bdeb13u1%2Bvitastor2/qemu-block-extra_10.0.11%2Bds-0%2Bdeb13u1%2Bvitastor2_amd64.deb && \
-    dpkg -x qemu-utils*.deb tmp1 && \
-    dpkg -x qemu-block-extra*.deb tmp1 && \
-    cp -a tmp1/usr/bin/qemu-storage-daemon /usr/bin/ && \
-    mkdir -p /usr/lib/x86_64-linux-gnu/qemu && \
-    cp -a tmp1/usr/lib/x86_64-linux-gnu/qemu/block-vitastor.so /usr/lib/x86_64-linux-gnu/qemu/ && \
-    rm -rf tmp1 *.deb && \
-    apt-get clean
-
-ENTRYPOINT ["/bin/vitastor-csi"]

csi/Makefile

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

csi/deploy/004-csi-nodeplugin.yaml

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

csi/deploy/007-csi-provisioner.yaml

@@ -87,7 +87,7 @@ spec:
             - name: socket-dir
               mountPath: /csi
         - name: csi-attacher
-          image: k8s.gcr.io/sig-storage/csi-attacher:v3.2.2
+          image: k8s.gcr.io/sig-storage/csi-attacher:v3.1.0
           args:
             - "--v=5"
             - "--csi-address=$(ADDRESS)"
@@ -121,7 +121,7 @@ spec:
             privileged: true
             capabilities:
               add: ["SYS_ADMIN"]
-          image: vitalif/vitastor-csi:v3.2.2
+          image: vitalif/vitastor-csi:v1.11.0
           args:
             - "--node=$(NODE_ID)"
             - "--endpoint=$(CSI_ENDPOINT)"

csi/go.mod

@@ -7,7 +7,6 @@ require (
 	github.com/golang/glog v0.0.0-20160126235308-23def4e6c14b
 	github.com/kubernetes-csi/csi-lib-utils v0.9.1
 	golang.org/x/net v0.7.0
-	golang.org/x/sys v0.5.0 // indirect
 	golang.org/x/xerrors v0.0.0-20200804184101-5ec99f83aff1 // indirect
 	google.golang.org/grpc v1.33.1
 	google.golang.org/protobuf v1.24.0

csi/src/config.go

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

csi/src/controllerserver.go

@@ -8,6 +8,7 @@ import (
     "encoding/json"
     "fmt"
     "strings"
+    "time"
     "os"
     "io/ioutil"
 
@@ -26,6 +27,7 @@ const (
     MB int64 = 1024 * KB
     GB int64 = 1024 * MB
     TB int64 = 1024 * GB
+    ETCD_TIMEOUT time.Duration = 15*time.Second
 )
 
 type InodeIndex struct
@@ -685,7 +687,7 @@ func (cs *ControllerServer) ControllerExpandVolume(ctx context.Context, req *csi
 
     return &csi.ControllerExpandVolumeResponse{
         CapacityBytes: int64(inodeCfg[0].Size),
-        NodeExpansionRequired: true,
+        NodeExpansionRequired: false,
     }, nil
 }
 

csi/src/nodeserver.go

@@ -33,7 +33,7 @@ import (
 type NodeServer struct
 {
     *Driver
-    method          MountMethod
+    useVduse        bool
     stateDir        string
     nfsStageDir     string
     mounter         mount.Interface
@@ -81,31 +81,26 @@ func NewNodeServer(driver *Driver) *NodeServer
     }
     ns := &NodeServer{
         Driver:      driver,
-        method:      selectMountMethod(),
+        useVduse:    checkVduseSupport(),
         stateDir:    stateDir,
         nfsStageDir: nfsStageDir,
         mounter:     mount.New(""),
         volumeLocks: make(map[string]bool),
     }
     ns.cond = sync.NewCond(&ns.mu)
-    if (ns.method == MOUNT_VDUSE)
+    if (ns.useVduse)
     {
         ns.restoreVduseDaemons()
-    }
-    else if (ns.method == MOUNT_UBLK)
-    {
-        ns.restoreUblkDaemons()
-    }
-    ns.restoreNfsDaemons()
-    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()
+        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
 }
@@ -132,22 +127,16 @@ func (ns *NodeServer) unlockVolume(lockId string)
 
 func (ns *NodeServer) restarter()
 {
-    // Restart dead storage daemons at regular intervals. Otherwise volume I/O
-    // may hang and may even lead to a kernel panic if panic_on_hung_task is set.
+    // 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
-        if (ns.method == MOUNT_VDUSE)
-        {
-            ns.restoreVduseDaemons()
-        }
-        else if (ns.method == MOUNT_UBLK)
-        {
-            ns.restoreUblkDaemons()
-        }
-        ns.restoreNfsDaemons()
+        ns.restoreVduseDaemons()
     }
 }
 
@@ -242,78 +231,6 @@ func (ns *NodeServer) checkVduseState(stateFile string, devs map[string]interfac
     }
 }
 
-func (ns *NodeServer) restoreUblkDaemons()
-{
-    pattern := ns.stateDir+"vitastor-ublk-*.json"
-    stateFiles, err := filepath.Glob(pattern)
-    if (err != nil)
-    {
-        klog.Errorf("failed to list %s: %v", pattern, err)
-    }
-    if (len(stateFiles) == 0)
-    {
-        return
-    }
-    for _, stateFile := range stateFiles
-    {
-        deviceNum := stateFile[len(ns.stateDir) + len("vitastor-ublk-") :]
-        deviceNum = deviceNum[0:len(deviceNum)-5]
-        ns.checkUblkState(deviceNum)
-    }
-}
-
-func (ns *NodeServer) checkUblkState(deviceNum string)
-{
-    // Check if the ublk daemon is still active
-
-    // Read state file
-    stateFile := ns.stateDir + "vitastor-ublk-" + deviceNum + ".json"
-    stateJSON, err := os.ReadFile(stateFile)
-    if (err != nil)
-    {
-        klog.Warningf("error reading state file %v: %v", stateFile, err)
-        return
-    }
-    var state DeviceState
-    err = json.Unmarshal(stateJSON, &state)
-    if (err != nil)
-    {
-        klog.Warningf("state file %v contains invalid JSON (error %v): %v", stateFile, err, string(stateJSON))
-        return
-    }
-
-    // Lock volume
-    ns.lockVolume(state.ConfigPath+":block:"+state.Image)
-    defer ns.unlockVolume(state.ConfigPath+":block:"+state.Image)
-
-    // Recheck state file after locking
-    _, err = os.ReadFile(stateFile)
-    if (err != nil)
-    {
-        klog.Warningf("state file %v disappeared, skipping volume", stateFile)
-        return
-    }
-
-    // Check if the vitastor-ublk process is still active
-    pidFile := ns.stateDir + "vitastor-ublk-" + deviceNum + ".pid"
-    exists := false
-    proc, err := findByPidFile(pidFile)
-    if (err == nil)
-    {
-        exists = proc.Signal(syscall.Signal(0)) == nil
-    }
-    if (!exists)
-    {
-        // Restart daemon
-        klog.Warningf("recovering UBLK device /dev/ublkb%v for volume %v", deviceNum, state.Image)
-        _, err = mapUblk(ns.stateDir, state.Image, state.ConfigPath, state.Readonly, "/dev/ublkb"+deviceNum)
-        if (err != nil)
-        {
-            klog.Warningf("failed to recover ublk device for volume %v: %v", state.Image, err)
-        }
-    }
-}
-
 func (ns *NodeServer) restoreNfsDaemons()
 {
     pattern := ns.stateDir+"vitastor-nfs-*.json"
@@ -326,10 +243,15 @@ func (ns *NodeServer) restoreNfsDaemons()
     {
         return
     }
+    activeNFS, err := ns.listActiveNFS()
+    if (err != nil)
+    {
+        return
+    }
     // Check all state files and try to restore active mounts
     for _, stateFile := range stateFiles
     {
-        ns.checkNfsState(stateFile)
+        ns.checkNfsState(stateFile, activeNFS)
     }
 }
 
@@ -355,43 +277,24 @@ func (ns *NodeServer) readNfsState(stateFile string, allowNotExists bool) (*NfsS
     return &state, nil
 }
 
-func (ns *NodeServer) checkNfsState(stateFile string)
+func (ns *NodeServer) checkNfsState(stateFile string, activeNfs map[int][]string)
 {
-    // Read state file to determine the lock ID
+    // Read state file
     state, err := ns.readNfsState(stateFile, false)
     if (err != nil)
     {
         return
     }
     // Lock FS
-    lockId := state.ConfigPath+":fs:"+state.FsName
-    ns.lockVolume(lockId)
-    defer ns.unlockVolume(lockId)
-    // Recheck state and mounts under the lock: publish/unpublish may have changed
-    // both while this recovery attempt was waiting for the lock.
-    state, err = ns.readNfsState(stateFile, true)
-    if (err != nil || state == nil)
-    {
-        return
-    }
-    activeNfs, err := ns.listActiveNFS()
-    if (err != nil)
-    {
-        return
-    }
+    ns.lockVolume(state.ConfigPath+":fs:"+state.FsName)
+    defer ns.unlockVolume(state.ConfigPath+":fs:"+state.FsName)
+    // Check if NFS at this port is still mounted
     pidFile := ns.stateDir + filepath.Base(stateFile)
     pidFile = pidFile[0:len(pidFile)-5] + ".pid"
     if (len(activeNfs[state.Port]) == 0)
     {
-        // This is a stale state file. Remove the root staging mount before
-        // stopping the daemon, otherwise a dead hidden NFS mount may remain.
+        // this is a stale state file, remove it
         klog.Warningf("state file %v contains stale mount at port %d, removing it", stateFile, state.Port)
-        err = mount.CleanupMountPoint(state.Path, ns.mounter, false)
-        if (err != nil)
-        {
-            klog.Errorf("failed to unmount stale NFS mount %v: %v", state.Path, err)
-            return
-        }
         ns.stopNFS(stateFile, pidFile)
         return
     }
@@ -411,7 +314,6 @@ func (ns *NodeServer) checkNfsState(stateFile string)
             "--pidfile", pidFile,
             "--bind", "127.0.0.1",
             "--port", fmt.Sprintf("%d", state.Port),
-            "--config_path", state.ConfigPath,
             "--fs", state.FsName,
             "--pool", state.Pool,
             "--portmap", "0",
@@ -515,18 +417,14 @@ func (ns *NodeServer) NodeStageVolume(ctx context.Context, req *csi.NodeStageVol
     }
 
     var devicePath, vdpaId string
-    if (ns.method == MOUNT_UBLK)
-    {
-        devicePath, err = mapUblk(ns.stateDir, volName, ctxVars["configPath"], false, "")
-    }
-    else if (ns.method == MOUNT_VDUSE)
-    {
-        devicePath, vdpaId, err = mapVduse(ns.stateDir, volName, ctxVars, false)
-    }
-    else /* if (ns.method == MOUNT_NBD) */
+    if (!ns.useVduse)
     {
         devicePath, err = mapNbd(volName, ctxVars, false)
     }
+    else
+    {
+        devicePath, vdpaId, err = mapVduse(ns.stateDir, volName, ctxVars, false)
+    }
     if (err != nil)
     {
         return nil, err
@@ -541,8 +439,7 @@ func (ns *NodeServer) NodeStageVolume(ctx context.Context, req *csi.NodeStageVol
     else
     {
         // Check existing format
-        var existingFormat string
-        existingFormat, err = diskMounter.GetDiskFormat(devicePath)
+        existingFormat, err := diskMounter.GetDiskFormat(devicePath)
         if (err != nil)
         {
             klog.Errorf("failed to get disk format for path %s, error: %v", err)
@@ -598,6 +495,10 @@ func (ns *NodeServer) NodeStageVolume(ctx context.Context, req *csi.NodeStageVol
                 case "xfs":
                     _, err = systemCombined("xfs_growfs", devicePath)
             }
+            if (err != nil)
+            {
+                goto unmap
+            }
         }
     }
     if (err != nil)
@@ -611,18 +512,14 @@ func (ns *NodeServer) NodeStageVolume(ctx context.Context, req *csi.NodeStageVol
     return &csi.NodeStageVolumeResponse{}, nil
 
 unmap:
-    if (ns.method == MOUNT_UBLK)
-    {
-        unmapUblk(ns.stateDir, devicePath)
-    }
-    else if (ns.method == MOUNT_VDUSE)
-    {
-        unmapVduseById(ns.stateDir, vdpaId)
-    }
-    else /* if (ns.method == MOUNT_NBD) */
+    if (!ns.useVduse || len(devicePath) >= 8 && devicePath[0:8] == "/dev/nbd")
     {
         unmapNbd(devicePath)
     }
+    else
+    {
+        unmapVduseById(ns.stateDir, vdpaId)
+    }
     return nil, err
 }
 
@@ -648,7 +545,7 @@ func (ns *NodeServer) NodeUnstageVolume(ctx context.Context, req *csi.NodeUnstag
     defer ns.unlockVolume(ctxVars["configPath"]+":block:"+volName)
 
     targetPath := req.GetStagingTargetPath()
-    devicePath, err := GetDeviceNameFromMount(targetPath)
+    devicePath, _, err := mount.GetDeviceNameFromMount(ns.mounter, targetPath)
     if (err != nil)
     {
         if (os.IsNotExist(err))
@@ -685,18 +582,14 @@ func (ns *NodeServer) NodeUnstageVolume(ctx context.Context, req *csi.NodeUnstag
     // unmap device
     if (len(refList) == 0)
     {
-        if (ns.method == MOUNT_UBLK)
-        {
-            unmapUblk(ns.stateDir, devicePath)
-        }
-        else if (ns.method == MOUNT_VDUSE)
-        {
-            unmapVduse(ns.stateDir, devicePath)
-        }
-        else /* if (ns.method == MOUNT_NBD) */
+        if (!ns.useVduse)
         {
             unmapNbd(devicePath)
         }
+        else
+        {
+            unmapVduse(ns.stateDir, devicePath)
+        }
     }
 
     return &csi.NodeUnstageVolumeResponse{}, nil
@@ -737,7 +630,6 @@ func (ns *NodeServer) mountNFS(ctxVars map[string]string) (string, error)
         "--pidfile", pidFile,
         "--bind", "127.0.0.1",
         "--port", "auto",
-        "--config_path", state.ConfigPath,
         "--fs", state.FsName,
         "--pool", state.Pool,
         "--portmap", "0",
@@ -767,7 +659,7 @@ func (ns *NodeServer) mountNFS(ctxVars map[string]string) (string, error)
     // Mount NFS
     _, _, err = system(
         "mount", "-t", "nfs", "127.0.0.1:/", state.Path,
-        "-o", fmt.Sprintf("port=%d,mountport=%d,nfsvers=3,soft,sync,nolock,tcp", port, port),
+        "-o", fmt.Sprintf("port=%d,mountport=%d,nfsvers=3,soft,nolock,tcp", port, port),
     )
     if (err != nil)
     {
@@ -828,38 +720,26 @@ func (ns *NodeServer) listActiveNFS() (map[int][]string, error)
         klog.Errorf("failed to list mounts: %v", err)
         return nil, err
     }
-    return collectActiveNFS(mounts), nil
-}
-
-func collectActiveNFS(mounts []mount.MountInfo) map[int][]string
-{
     activeNFS := make(map[int][]string)
-    for _, mnt := range mounts
+    for _, mount := range mounts
     {
-        // Only count PVC subdirectory mounts, not the root staging mount. Newer
-        // kernels expose the subdirectory in Source while older ones expose it
-        // in Root. The staging mount may also be visible through several bind
-        // aliases in the CSI container, so its mount point isn't a reliable
-        // discriminator.
-        if (mnt.FsType != "nfs" || !strings.HasPrefix(mnt.Source, "127.0.0.1:/") ||
-            (mnt.Source == "127.0.0.1:/" && mnt.Root == "/"))
+        // Volume mounts always refer to subpaths
+        if (mount.FsType == "nfs" && mount.Root != "/")
         {
-            continue
-        }
-        // NFS-specific options, including port, are per-superblock options.
-        for _, opt := range mnt.SuperOptions
-        {
-            if (strings.HasPrefix(opt, "port="))
+            for _, opt := range mount.MountOptions
             {
-                port64, err := strconv.ParseUint(opt[5:], 10, 16)
-                if (err == nil)
+                if (strings.HasPrefix(opt, "port="))
                 {
-                    activeNFS[int(port64)] = append(activeNFS[int(port64)], mnt.MountPoint)
+                    port64, err := strconv.ParseUint(opt[5:], 10, 16)
+                    if (err == nil)
+                    {
+                        activeNFS[int(port64)] = append(activeNFS[int(port64)], mount.MountPoint)
+                    }
                 }
             }
         }
     }
-    return activeNFS
+    return activeNFS, nil
 }
 
 // NodePublishVolume mounts the volume mounted to the staging path to the target path
@@ -1017,7 +897,7 @@ func (ns *NodeServer) NodeUnpublishVolume(ctx context.Context, req *csi.NodeUnpu
     }
 
     targetPath := req.GetTargetPath()
-    devicePath, err := GetDeviceNameFromMount(targetPath)
+    devicePath, _, err := mount.GetDeviceNameFromMount(ns.mounter, targetPath)
     if (err != nil)
     {
         if (os.IsNotExist(err))
@@ -1055,131 +935,10 @@ func (ns *NodeServer) NodeGetVolumeStats(ctx context.Context, req *csi.NodeGetVo
     return nil, status.Error(codes.Unimplemented, "")
 }
 
-// NodeExpandVolume expands the block device and, for filesystem volumes, the filesystem on the node
+// NodeExpandVolume expanding the file system on the node
 func (ns *NodeServer) NodeExpandVolume(ctx context.Context, req *csi.NodeExpandVolumeRequest) (*csi.NodeExpandVolumeResponse, error)
 {
-    klog.Infof("received node expand volume request %+v", protosanitizer.StripSecrets(req))
-    if (req == nil)
-    {
-        return nil, status.Error(codes.InvalidArgument, "request cannot be empty")
-    }
-    if (req.VolumeId == "")
-    {
-        return nil, status.Error(codes.InvalidArgument, "VolumeId is required")
-    }
-
-    ctxVars := make(map[string]string)
-    err := json.Unmarshal([]byte(req.VolumeId), &ctxVars)
-    if (err != nil)
-    {
-        return nil, status.Error(codes.Internal, "volume ID not in JSON format")
-    }
-    volName := ctxVars["name"]
-
-    if (ctxVars["vitastorfs"] != "")
-    {
-        // VitastorFS CSI volumes are NFS-backed and currently don't have per-volume quotas to resize here.
-        return &csi.NodeExpandVolumeResponse{CapacityBytes: req.GetCapacityRange().GetRequiredBytes()}, nil
-    }
-
-    ns.lockVolume(ctxVars["configPath"]+":block:"+volName)
-    defer ns.unlockVolume(ctxVars["configPath"]+":block:"+volName)
-
-    targetPath := req.GetStagingTargetPath()
-    if (targetPath == "")
-    {
-        targetPath = req.GetVolumePath()
-    }
-    if (targetPath == "")
-    {
-        return nil, status.Error(codes.InvalidArgument, "VolumePath or StagingTargetPath is required")
-    }
-
-    devicePath, err := GetDeviceNameFromMount(targetPath)
-    if (err != nil)
-    {
-        if (os.IsNotExist(err))
-        {
-            return nil, status.Error(codes.NotFound, "Target path not found")
-        }
-        return nil, err
-    }
-    if (devicePath == "")
-    {
-        return nil, status.Errorf(codes.NotFound, "%s is not a mountpoint", targetPath)
-    }
-    if (devicePath[0] != '/')
-    {
-        return nil, status.Errorf(codes.Internal, "failed to resolve device for %s: %s", targetPath, devicePath)
-    }
-    if (len(devicePath) < 5 || devicePath[0:5] != "/dev/")
-    {
-        // NodeExpandVolume may be called with the published target path. For block volumes it is
-        // usually a bind mount of the staging target, so resolve one more mount layer if needed.
-        var realDevicePath string
-        realDevicePath, err = GetDeviceNameFromMount(devicePath)
-        if (err == nil && realDevicePath != "")
-        {
-            devicePath = realDevicePath
-        }
-    }
-
-    // All newest Vitastor driver versions (nbd, ublk and vduse) support online resize.
-    // So all we need to do is just wait a bit until the device is resized by the driver.
-    requiredBytes := req.GetCapacityRange().GetRequiredBytes()
-    if (requiredBytes > 0)
-    {
-        timeout := 30
-        var actualSize uint64
-        var err error
-        for i := 0; i < timeout && actualSize < uint64(requiredBytes); i++
-        {
-            actualSize, err = GetBlockDeviceSize(devicePath)
-            if (err != nil)
-            {
-                return nil, err
-            }
-            time.Sleep(1 * time.Second)
-        }
-        if (actualSize < uint64(requiredBytes))
-        {
-            return nil, status.Errorf(codes.NotFound, "Failed to wait for online resize of %s to %v bytes: actual size is still %v after %v seconds",
-                devicePath, requiredBytes, actualSize, timeout)
-        }
-    }
-
-    isBlock := req.GetVolumeCapability().GetBlock() != nil
-    if (isBlock)
-    {
-        return &csi.NodeExpandVolumeResponse{CapacityBytes: requiredBytes}, nil
-    }
-
-    diskMounter := &mount.SafeFormatAndMount{Interface: ns.mounter, Exec: utilexec.New()}
-    fsType := req.GetVolumeCapability().GetMount().GetFsType()
-    if (fsType == "")
-    {
-        fsType, err = diskMounter.GetDiskFormat(devicePath)
-        if (err != nil)
-        {
-            return nil, err
-        }
-    }
-
-    switch (fsType)
-    {
-        case "ext4":
-            _, err = systemCombined("resize2fs", devicePath)
-        case "xfs":
-            _, err = systemCombined("xfs_growfs", targetPath)
-        default:
-            return nil, status.Errorf(codes.InvalidArgument, "unsupported filesystem for resize: %s", fsType)
-    }
-    if (err != nil)
-    {
-        return nil, err
-    }
-
-    return &csi.NodeExpandVolumeResponse{CapacityBytes: requiredBytes}, nil
+    return nil, status.Error(codes.Unimplemented, "")
 }
 
 // NodeGetCapabilities returns the supported capabilities of the node server
@@ -1194,13 +953,6 @@ func (ns *NodeServer) NodeGetCapabilities(ctx context.Context, req *csi.NodeGetC
                     },
                 },
             },
-            &csi.NodeServiceCapability{
-                Type: &csi.NodeServiceCapability_Rpc{
-                    Rpc: &csi.NodeServiceCapability_RPC{
-                        Type: csi.NodeServiceCapability_RPC_EXPAND_VOLUME,
-                    },
-                },
-            },
         },
     }, nil
 }

csi/src/nodeserver_test.go

@@ -1,73 +0,0 @@
-// Copyright (c) Vitaliy Filippov, 2019+
-// License: VNPL-1.1 or GNU GPL-2.0+ (see README.md for details)
-
-package vitastor
-
-import (
-    "reflect"
-    "testing"
-
-    "k8s.io/utils/mount"
-)
-
-func TestCollectActiveNFS(t *testing.T)
-{
-    mounts := []mount.MountInfo{
-        {
-            Root:         "/",
-            Source:       "127.0.0.1:/",
-            MountPoint:   "/var/lib/kubelet/plugins/csi.vitastor.io/nfs/hash",
-            FsType:       "nfs",
-            MountOptions: []string{"rw", "relatime"},
-            SuperOptions: []string{"rw", "vers=3", "port=45059"},
-        },
-        {
-            // This is how NFS subdirectory bind mounts appear on Linux 6.19:
-            // Root is still / and the subdirectory is only visible in Source.
-            Root:         "/",
-            Source:       "127.0.0.1:/pvc-one",
-            MountPoint:   "/var/lib/kubelet/pods/pod-one/volumes/kubernetes.io~csi/pvc-one/mount",
-            FsType:       "nfs",
-            MountOptions: []string{"rw", "relatime"},
-            SuperOptions: []string{"rw", "vers=3", "port=45059"},
-        },
-        {
-            Root:         "/",
-            Source:       "127.0.0.1:/pvc-two",
-            MountPoint:   "/var/lib/kubelet/pods/pod-two/volumes/kubernetes.io~csi/pvc-two/mount",
-            FsType:       "nfs",
-            MountOptions: []string{"rw", "relatime"},
-            SuperOptions: []string{"rw", "vers=3", "port=45059"},
-        },
-        {
-            // Older kernels expose the bind-mounted subdirectory in Root.
-            Root:         "/pvc-three",
-            Source:       "127.0.0.1:/",
-            MountPoint:   "/var/lib/kubelet/pods/pod-three/volumes/kubernetes.io~csi/pvc-three/mount",
-            FsType:       "nfs",
-            MountOptions: []string{"rw", "relatime"},
-            SuperOptions: []string{"rw", "vers=3", "port=45059"},
-        },
-        {
-            Root:         "/",
-            Source:       "server:/other",
-            MountPoint:   "/mnt/other",
-            FsType:       "nfs",
-            MountOptions: []string{"rw"},
-            SuperOptions: []string{"rw", "port=2049"},
-        },
-    }
-
-    got := collectActiveNFS(mounts)
-    want := map[int][]string{
-        45059: {
-            "/var/lib/kubelet/pods/pod-one/volumes/kubernetes.io~csi/pvc-one/mount",
-            "/var/lib/kubelet/pods/pod-two/volumes/kubernetes.io~csi/pvc-two/mount",
-            "/var/lib/kubelet/pods/pod-three/volumes/kubernetes.io~csi/pvc-three/mount",
-        },
-    }
-    if (!reflect.DeepEqual(got, want))
-    {
-        t.Fatalf("unexpected active NFS mounts: got %#v, want %#v", got, want)
-    }
-}

csi/src/utils.go

@@ -16,19 +16,8 @@ import (
     "syscall"
 
     "k8s.io/klog"
-    "k8s.io/utils/mount"
-
     "google.golang.org/grpc/codes"
     "google.golang.org/grpc/status"
-    "golang.org/x/sys/unix"
-)
-
-type MountMethod int
-
-const (
-    MOUNT_NBD   MountMethod = 0
-    MOUNT_VDUSE MountMethod = 1
-    MOUNT_UBLK  MountMethod = 2
 )
 
 func Contains(list []string, s string) bool
@@ -43,26 +32,29 @@ func Contains(list []string, s string) bool
     return false
 }
 
-func selectMountMethod() MountMethod
+func checkVduseSupport() bool
 {
-    // Check UBLK support (ublk_drv kernel module)
-    if (checkModule("ublk_drv"))
-    {
-        klog.Infof("UBLK support enabled successfully")
-        return MOUNT_UBLK
-    }
-    klog.Errorf(
-        "Your host apparently has no UBLK support. UBLK support disabled."+
-        " For UBLK you need at least Linux 6.0 and the ublk_drv kernel module.",
-    )
     // Check VDUSE support (vdpa, vduse, virtio-vdpa kernel modules)
     vduse := true
     for _, mod := range []string{"vdpa", "vduse", "virtio-vdpa"}
     {
-        if (!checkModule(mod))
+        _, err := os.Stat("/sys/module/"+mod)
+        if (err != nil)
         {
-            vduse = false
-            break
+            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
@@ -77,38 +69,18 @@ func selectMountMethod() MountMethod
             vduse = false
         }
     }
-    if (vduse)
+    if (!vduse)
+    {
+        klog.Errorf(
+            "Your host apparently has no VDUSE support. VDUSE support disabled, NBD will be used to map devices."+
+            " For VDUSE you need at least Linux 5.15 and the following kernel modules: vdpa, virtio-vdpa, vduse.",
+        )
+    }
+    else
     {
         klog.Infof("VDUSE support enabled successfully")
-        return MOUNT_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 MOUNT_NBD
-}
-
-func checkModule(mod string) bool
-{
-    _, 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)
-            return false
-        }
-    }
-    return true
+    return vduse
 }
 
 func mapNbd(volName string, ctxVars map[string]string, readonly bool) (string, error)
@@ -245,7 +217,6 @@ func mapVduse(stateDir string, volName string, ctxVars map[string]string, readon
                     stateJSON, _ := json.Marshal(&DeviceState{
                         ConfigPath: ctxVars["configPath"],
                         VdpaId:     vdpaId,
-
                         Image:      volName,
                         Blockdev:   blockdev,
                         Readonly:   readonly,
@@ -338,117 +309,6 @@ func unmapVduseById(stateDir, vdpaId string)
     }
 }
 
-func mapUblk(stateDir string, volName string, configPath string, readonly bool, recoverDev string) (string, error)
-{
-    pidFile := ""
-    if (recoverDev != "")
-    {
-        if (len(recoverDev) < 10 || recoverDev[0:10] != "/dev/ublkb")
-        {
-            return "", fmt.Errorf("recover: %s does not start with /dev/ublkb", recoverDev)
-        }
-        pidFile = stateDir + "vitastor-ublk-" + recoverDev[10:] + ".pid"
-    }
-    else
-    {
-        pidFd, err := os.CreateTemp(stateDir, "vitastor-tmp-*.pid")
-        if (err != nil)
-        {
-            return "", err
-        }
-        pidFile = pidFd.Name()
-        pidFd.Close()
-    }
-    // Map device via vitastor-ublk
-    args := []string{
-        "map", "--image", volName, "--pidfile", pidFile,
-    }
-    if (configPath != "")
-    {
-        args = append(args, "--config_path", configPath)
-    }
-    if (readonly)
-    {
-        args = append(args, "--readonly")
-    }
-    if (recoverDev != "")
-    {
-        args = append(args, "--recover", recoverDev)
-    }
-    stdout, stderr, err := system("/usr/bin/vitastor-ublk", args...)
-    if (err != nil)
-    {
-        return "", err
-    }
-    devicePath := strings.TrimSpace(string(stdout))
-    if (devicePath == "")
-    {
-        return "", fmt.Errorf("vitastor-ublk did not return the name of the device. output: %s", stderr)
-    }
-    if (len(devicePath) >= 10 && devicePath[0:10] == "/dev/ublkb")
-    {
-        // Generate state file
-        devNum := devicePath[10:]
-        pidNew := stateDir + "vitastor-ublk-" + devNum + ".pid"
-        if (pidFile != pidNew)
-        {
-            err := os.Rename(pidFile, pidNew)
-            if (err != nil)
-            {
-                klog.Errorf("Failed to rename PID file %s to %s: %v", pidFile, pidNew, err)
-            }
-            else
-            {
-                pidFile = pidNew
-            }
-        }
-        stateFile := stateDir + "vitastor-ublk-" + devNum + ".json"
-        stateJSON, _ := json.Marshal(&DeviceState{
-            ConfigPath: configPath,
-            Image:      volName,
-            Readonly:   readonly,
-            PidFile:    pidFile,
-        })
-        err = os.WriteFile(stateFile, stateJSON, 0600)
-        if (err == nil)
-        {
-            klog.Infof("Attached volume %s via UBLK as %s", volName, devicePath)
-            return devicePath, nil
-        }
-        os.Remove(stateFile)
-    }
-    killErr := killByPidFile(pidFile)
-    if (killErr != nil)
-    {
-        klog.Errorf("Failed to kill started vitastor-ublk: %v", killErr)
-    }
-    os.Remove(pidFile)
-    return "", err
-}
-
-func unmapUblk(stateDir, devicePath string)
-{
-    if (len(devicePath) < 10 || devicePath[0:10] != "/dev/ublkb")
-    {
-        klog.Errorf("%s does not start with /dev/ublkb", devicePath)
-        return
-    }
-    unmapOut, unmapErr := exec.Command("/usr/bin/vitastor-ublk", "unmap", devicePath).CombinedOutput()
-    if (unmapErr != nil)
-    {
-        klog.Errorf("failed to unmap UBLK device %s: %s, error: %v", devicePath, unmapOut, unmapErr)
-    }
-    for _, ext := range []string{"json", "pid"}
-    {
-        fn := stateDir + "vitastor-ublk-" + devicePath[10:] + "." + ext
-        err := os.Remove(fn)
-        if (err != nil)
-        {
-            klog.Errorf("failed to remove %s: %v", fn, err)
-        }
-    }
-}
-
 func system(program string, args ...string) ([]byte, []byte, error)
 {
     klog.Infof("Running "+program+" "+strings.Join(args, " "))
@@ -480,62 +340,3 @@ func systemCombined(program string, args ...string) ([]byte, error)
     }
     return out.Bytes(), nil
 }
-
-func GetDeviceNameFromMount(mountPath string) (string, error)
-{
-    // Use /proc/self/mountinfo to correctly parse bind mounts for block device files
-    mps, err := mount.ParseMountInfo("/proc/self/mountinfo")
-    if (err != nil)
-    {
-        return "", err
-    }
-
-    slTarget, err := filepath.EvalSymlinks(mountPath)
-    if (err != nil)
-    {
-        slTarget = mountPath
-    }
-
-    device := ""
-    for _, mp := range mps
-    {
-        if (mp.MountPoint == slTarget)
-        {
-            device = mp.Source
-            if (device[0] != '/' && mp.Root != "/")
-            {
-                // Handle {Source=udev Root=/vdb MountPoint=/var/lib/kubelet/tralaleylo/tralala}
-                for _, other := range mps
-                {
-                    if (other.Root == "/" && other.Source == mp.Source)
-                    {
-                        device = other.MountPoint + mp.Root
-                        break
-                    }
-                }
-            }
-            break
-        }
-    }
-
-    return device, nil
-}
-
-func GetBlockDeviceSize(devicePath string) (uint64, error)
-{
-    file, err := os.Open(devicePath)
-    if (err != nil)
-    {
-        return 0, err
-    }
-    defer file.Close()
-
-    // BLKGETSIZE64 returns the size in bytes as a uint64/int64
-    size, err := unix.IoctlGetInt(int(file.Fd()), unix.BLKGETSIZE64)
-    if (err != nil)
-    {
-        return 0, fmt.Errorf("ioctl BLKGETSIZE64 failed: %w", err)
-    }
-
-    return uint64(size), nil
-}

debian/build-vitastor-bookworm.sh

@@ -1,4 +1,7 @@
 #!/bin/bash
 
-docker build --build-arg DISTRO=debian --build-arg REL=bookworm -t vitastor-buildenv:bookworm -f vitastor-buildenv.Dockerfile .
-docker run -it --rm -e REL=bookworm -v `dirname $0`/../:/root/vitastor vitastor-buildenv:bookworm /root/vitastor/debian/vitastor-build.sh
+cat < vitastor.Dockerfile > ../Dockerfile
+cd ..
+mkdir -p packages
+sudo podman build --build-arg DISTRO=debian --build-arg REL=bookworm -v `pwd`/packages:/root/packages -f Dockerfile .
+rm Dockerfile

debian/build-vitastor-bullseye.sh

@@ -1,4 +1,7 @@
 #!/bin/bash
 
-docker build --build-arg DISTRO=debian --build-arg REL=bullseye -t vitastor-buildenv:bullseye -f vitastor-buildenv.Dockerfile .
-docker run -it --rm -e REL=bullseye -v `dirname $0`/../:/root/vitastor vitastor-buildenv:bullseye /root/vitastor/debian/vitastor-build.sh
+cat < vitastor.Dockerfile > ../Dockerfile
+cd ..
+mkdir -p packages
+sudo podman build --build-arg DISTRO=debian --build-arg REL=bullseye -v `pwd`/packages:/root/packages -f Dockerfile .
+rm Dockerfile

debian/build-vitastor-buster.sh

@@ -1,4 +1,7 @@
 #!/bin/bash
 
-docker build --build-arg DISTRO=debian --build-arg REL=buster -t vitastor-buildenv:buster -f vitastor-buildenv.Dockerfile .
-docker run -it --rm -e REL=buster -v `dirname $0`/../:/root/vitastor vitastor-buildenv:buster /root/vitastor/debian/vitastor-build.sh
+cat < vitastor.Dockerfile > ../Dockerfile
+cd ..
+mkdir -p packages
+sudo podman build --build-arg DISTRO=debian --build-arg REL=buster -v `pwd`/packages:/root/packages -f Dockerfile .
+rm Dockerfile

debian/build-vitastor-trixie.sh

@@ -1,4 +0,0 @@
-#!/bin/bash
-
-docker build --build-arg DISTRO=debian --build-arg REL=trixie -t vitastor-buildenv:trixie -f vitastor-buildenv.Dockerfile .
-docker run -it --rm -e REL=trixie -v `dirname $0`/../:/root/vitastor vitastor-buildenv:trixie /root/vitastor/debian/vitastor-build.sh

debian/build-vitastor-ubuntu-jammy.sh

@@ -1,5 +1,7 @@
 #!/bin/bash
-# Ubuntu 22.04 Jammy Jellyfish
 
-docker build --build-arg DISTRO=ubuntu --build-arg REL=jammy -t vitastor-buildenv:jammy -f vitastor-buildenv.Dockerfile .
-docker run -it --rm -e REL=jammy -v `dirname $0`/../:/root/vitastor vitastor-buildenv:jammy /root/vitastor/debian/vitastor-build.sh
+cat < vitastor.Dockerfile > ../Dockerfile
+cd ..
+mkdir -p packages
+sudo podman build --build-arg DISTRO=ubuntu --build-arg REL=jammy -v `pwd`/packages:/root/packages -f Dockerfile .
+rm Dockerfile

debian/build-vitastor-ubuntu-noble.sh

@@ -1,5 +0,0 @@
-#!/bin/bash
-# 24.04 Noble Numbat
-
-docker build --build-arg DISTRO=ubuntu --build-arg REL=noble -t vitastor-buildenv:noble -f vitastor-buildenv.Dockerfile .
-docker run -it --rm -e REL=noble -v `dirname $0`/../:/root/vitastor vitastor-buildenv:noble /root/vitastor/debian/vitastor-build.sh

debian/build-vitastor-ubuntu-questing.sh

@@ -1,5 +0,0 @@
-#!/bin/bash
-# 25.10 Questing quokka
-
-docker build --build-arg DISTRO=ubuntu --build-arg REL=questing -t vitastor-buildenv:questing -f vitastor-buildenv.Dockerfile .
-docker run -it --rm -e REL=questing -v `dirname $0`/../:/root/vitastor vitastor-buildenv:questing /root/vitastor/debian/vitastor-build.sh

debian/build-vitastor-ubuntu-resolute.sh

@@ -1,5 +0,0 @@
-#!/bin/bash
-# 26.04 Resolute Raccoon
-
-docker build --build-arg DISTRO=ubuntu --build-arg REL=resolute -t vitastor-buildenv:resolute -f vitastor-buildenv.Dockerfile .
-docker run -it --rm -e REL=resolute -v `dirname $0`/../:/root/vitastor vitastor-buildenv:resolute /root/vitastor/debian/vitastor-build.sh

debian/changelog

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

debian/control

@@ -2,9 +2,9 @@ Source: vitastor
 Section: admin
 Priority: optional
 Maintainer: Vitaliy Filippov <vitalif@yourcmc.ru>
-Build-Depends: debhelper, g++ (>= 8), libstdc++6 (>= 8),
-  linux-libc-dev, libgoogle-perftools-dev, libjerasure-dev, libgf-complete-dev, libc-ares-dev,
-  libibverbs-dev, librdmacm-dev, libisal-dev, cmake, pkg-config, libnl-3-dev, libnl-genl-3-dev,
+Build-Depends: debhelper, liburing-dev (>= 0.6), g++ (>= 8), libstdc++6 (>= 8),
+  linux-libc-dev, libgoogle-perftools-dev, libjerasure-dev, libgf-complete-dev,
+  libibverbs-dev, libisal-dev, cmake, pkg-config, libnl-3-dev, libnl-genl-3-dev,
   node-bindings <!nocheck>, node-gyp, node-nan
 Standards-Version: 4.5.0
 Homepage: https://vitastor.io/

debian/patched-qemu.Dockerfile

@@ -10,14 +10,10 @@ ARG REL=
 WORKDIR /root
 
 RUN if [ "$REL" = "buster" -o "$REL" = "bullseye" -o "$REL" = "bookworm" ]; then \
-        if [ "$REL" = "buster" ]; then \
-            echo "deb http://archive.debian.org/debian $REL-backports main" >> /etc/apt/sources.list; \
-        else \
-            echo "deb http://deb.debian.org/debian $REL-backports main" >> /etc/apt/sources.list; \
-        fi; \
+        echo "deb http://deb.debian.org/debian $REL-backports main" >> /etc/apt/sources.list; \
         echo >> /etc/apt/preferences; \
         echo 'Package: *' >> /etc/apt/preferences; \
-        echo "Pin: release n=$REL-backports" >> /etc/apt/preferences; \
+        echo "Pin: release a=$REL-backports" >> /etc/apt/preferences; \
         echo 'Pin-Priority: 500' >> /etc/apt/preferences; \
     fi; \
     grep '^deb ' /etc/apt/sources.list | perl -pe 's/^deb/deb-src/' >> /etc/apt/sources.list; \
@@ -26,7 +22,7 @@ RUN if [ "$REL" = "buster" -o "$REL" = "bullseye" -o "$REL" = "bookworm" ]; then
     echo 'APT::Install-Suggests false;' >> /etc/apt/apt.conf
 
 RUN apt-get update
-RUN DEBIAN_FRONTEND=noninteractive TZ=Europe/Moscow apt-get -y install fio libgoogle-perftools-dev devscripts
+RUN DEBIAN_FRONTEND=noninteractive TZ=Europe/Moscow apt-get -y install fio liburing-dev libgoogle-perftools-dev devscripts
 RUN DEBIAN_FRONTEND=noninteractive TZ=Europe/Moscow apt-get -y build-dep qemu
 # To build a custom version
 #RUN cp /root/packages/qemu-orig/* /root
@@ -60,7 +56,7 @@ RUN set -e; \
     quilt add block/vitastor.c; \
     cp /root/qemu_driver.c block/vitastor.c; \
     quilt refresh; \
-    V=$(head -n1 debian/changelog | perl -pe 's/5\.2\+dfsg-9/5.2+dfsg-11/; s/^.*\((.*?)(\+deb\d+u\d+)?(~bpo[\d\+]*)?\).*$/$1/')+vitastor5; \
+    V=$(head -n1 debian/changelog | perl -pe 's/5\.2\+dfsg-9/5.2+dfsg-11/; s/^.*\((.*?)(~bpo[\d\+]*)?\).*$/$1/')+vitastor4; \
     if [ "$REL" = bullseye ]; then V=${V}bullseye; fi; \
     DEBEMAIL="Vitaliy Filippov <vitalif@yourcmc.ru>" dch -D $REL -v $V 'Plug Vitastor block driver'; \
     DEB_BUILD_OPTIONS=nocheck dpkg-buildpackage --jobs=auto -sa; \

debian/rules

@@ -11,7 +11,6 @@ override_dh_install:
 	cp -v node-binding/package.json node-binding/index.js node-binding/addon.cc node-binding/addon.h node-binding/client.cc node-binding/client.h debian/tmp/usr/lib/x86_64-linux-gnu/nodejs/vitastor
 	cp -v node-binding/build/Release/addon.node debian/tmp/usr/lib/x86_64-linux-gnu/nodejs/vitastor/build/Release
 	dh_install
-	cd debian/vitastor-mon/usr/lib/vitastor/mon && npm install --production
 
 override_dh_installdeb:
 	cat debian/fio_version >> debian/vitastor-fio.substvars

debian/vitastor-build.sh

@@ -1,59 +0,0 @@
-#!/bin/bash
-# To be ran inside buildenv docker
-
-set -e -x
-
-[ -e /usr/lib/x86_64-linux-gnu/pkgconfig/libisal.pc ] || cp /root/vitastor/debian/libisal.pc /usr/lib/x86_64-linux-gnu/pkgconfig
-
-mkdir -p /root/fio-build/
-cd /root/fio-build/
-rm -rf /root/fio-build/*
-dpkg-source -x /root/fio*.dsc
-
-FULLVER=`head -n1 /root/vitastor/debian/changelog | perl -pe 's/^.*\((.*?)\).*$/$1/'`
-VER=${FULLVER%%-*}
-rm -rf /root/vitastor-$VER
-mkdir /root/vitastor-$VER
-cd /root/vitastor
-cp -a $(ls | grep -v packages) /root/vitastor-$VER
-
-rm -rf /root/vitastor/packages/vitastor-$REL
-mkdir -p /root/vitastor/packages/vitastor-$REL
-mv /root/vitastor-$VER /root/vitastor/packages/vitastor-$REL/
-
-cd /root/vitastor/packages/vitastor-$REL/vitastor-$VER
-
-rm -rf fio
-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
-sh copy-fio-includes.sh
-rm fio
-mkdir -p a b debian/patches
-mv fio-copy b/fio
-diff -NaurpbB a b > debian/patches/fio-headers.patch || true
-echo fio-headers.patch >> debian/patches/series
-rm -rf a b
-
-echo "dep:fio=$FIO" > debian/fio_version
-
-cd /root/vitastor/packages/vitastor-$REL
-if [[ ( "$REL" = "trixie" || "$REL" = "resolute" ) && -e ../vitastor-bookworm/vitastor_$VER.orig.tar.xz ]]; then
-    # Fucking shit, archives differ between bookworm (xz 5.4.1) and trixie (xz 5.8.1)
-    cp ../vitastor-bookworm/vitastor_$VER.orig.tar.xz .
-else
-    tar --sort=name --mtime='2020-01-01' --owner=0 --group=0 --exclude=debian -cJf vitastor_$VER.orig.tar.xz vitastor-$VER
-fi
-cd vitastor-$VER
-DEBEMAIL="Vitaliy Filippov <vitalif@yourcmc.ru>" dch -D $REL -v "$FULLVER""$REL" "Rebuild for $REL"
-DEB_BUILD_OPTIONS=nocheck dpkg-buildpackage --jobs=auto -sa
-rm -rf /root/vitastor/packages/vitastor-$REL/vitastor-*/
-
-# Why does ubuntu rename debug packages to *.ddeb?
-cd /root/vitastor/packages/vitastor-$REL
-if ls *.ddeb >/dev/null; then
-    perl -i -pe 's/\.ddeb/.deb/' *.buildinfo *.changes
-    for i in *.ddeb; do
-        mv $i ${i%%.ddeb}.deb
-    done
-fi

debian/vitastor-buildenv.Dockerfile

@@ -1,31 +0,0 @@
-# Build environment for building Vitastor packages for Debian inside a container
-# cd ..
-# docker build --build-arg DISTRO=debian --build-arg REL=bullseye -f debian/vitastor.Dockerfile -t vitastor-buildenv:bullseye .
-# docker run --rm -e REL=bullseye -v ./:/root/vitastor /root/vitastor/debian/vitastor-build.sh
-
-ARG DISTRO=debian
-ARG REL=
-FROM $DISTRO:$REL
-ARG DISTRO=debian
-ARG REL=
-
-WORKDIR /root
-
-RUN set -e -x; \
-    if [ "$REL" = "buster" ]; then \
-        perl -i -pe 's/deb.debian.org/archive.debian.org/' /etc/apt/sources.list; \
-    fi; \
-    apt-get update; \
-    apt-get -y install wget; \
-    wget https://vitastor.io/debian/pubkey.gpg -O /etc/apt/trusted.gpg.d/vitastor.gpg; \
-    echo "deb https://vitastor.io/debian $REL main" >> /etc/apt/sources.list; \
-    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/*.sources || true; \
-    echo 'APT::Install-Recommends false;' >> /etc/apt/apt.conf; \
-    echo 'APT::Install-Suggests false;' >> /etc/apt/apt.conf
-
-RUN apt-get update && \
-    apt-get -y install fio libgoogle-perftools-dev devscripts libjerasure-dev cmake libc-ares-dev libisal-crypto-dev \
-        libibverbs-dev librdmacm-dev libisal-dev libnl-3-dev libnl-genl-3-dev libssl-dev curl nodejs npm node-nan node-bindings && \
-    apt-get -y build-dep fio && \
-    apt-get --download-only source fio

debian/vitastor-client.install

@@ -2,10 +2,7 @@ usr/bin/vita
 usr/bin/vitastor-cli
 usr/bin/vitastor-rm
 usr/bin/vitastor-nbd
-usr/bin/vitastor-ublk
 usr/bin/vitastor-nfs
-usr/sbin/mount.vitastorfs
-usr/sbin/mount.vitastorblk
 usr/bin/vitastor-kv
 usr/bin/vitastor-kv-stress
 usr/lib/*/libvitastor*.so*

debian/vitastor.Dockerfile

@@ -0,0 +1,65 @@
+# Build Vitastor packages for Debian inside a container
+# cd ..; podman build --build-arg DISTRO=debian --build-arg REL=bullseye -v `pwd`/packages:/root/packages -f debian/vitastor.Dockerfile .
+
+ARG DISTRO=debian
+ARG REL=
+FROM $DISTRO:$REL
+ARG DISTRO=debian
+ARG REL=
+
+WORKDIR /root
+
+RUN set -e -x; \
+    if [ "$REL" = "buster" ]; then \
+        apt-get update; \
+        apt-get -y install wget; \
+        wget https://vitastor.io/debian/pubkey.gpg -O /etc/apt/trusted.gpg.d/vitastor.gpg; \
+        echo "deb https://vitastor.io/debian $REL main" >> /etc/apt/sources.list; \
+    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 && \
+    apt-get -y install fio liburing-dev libgoogle-perftools-dev devscripts libjerasure-dev cmake \
+        libibverbs-dev librdmacm-dev libisal-dev libnl-3-dev libnl-genl-3-dev curl nodejs npm node-nan node-bindings && \
+    apt-get -y build-dep fio && \
+    apt-get --download-only source fio
+
+ADD . /root/vitastor
+RUN set -e -x; \
+    [ -e /usr/lib/x86_64-linux-gnu/pkgconfig/libisal.pc ] || cp /root/vitastor/debian/libisal.pc /usr/lib/x86_64-linux-gnu/pkgconfig; \
+    mkdir -p /root/fio-build/; \
+    cd /root/fio-build/; \
+    rm -rf /root/fio-build/*; \
+    dpkg-source -x /root/fio*.dsc; \
+    mkdir -p /root/packages/vitastor-$REL; \
+    rm -rf /root/packages/vitastor-$REL/*; \
+    cd /root/packages/vitastor-$REL; \
+    FULLVER=$(head -n1 /root/vitastor/debian/changelog | perl -pe 's/^.*\((.*?)\).*$/$1/'); \
+    VER=${FULLVER%%-*}; \
+    cp -r /root/vitastor vitastor-$VER; \
+    cd vitastor-$VER; \
+    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; \
+    sh copy-fio-includes.sh; \
+    rm fio; \
+    mkdir -p a b debian/patches; \
+    mv fio-copy b/fio; \
+    diff -NaurpbB a b > debian/patches/fio-headers.patch || true; \
+    echo fio-headers.patch >> debian/patches/series; \
+    rm -rf a b; \
+    echo "dep:fio=$FIO" > debian/fio_version; \
+    cd /root/packages/vitastor-$REL/vitastor-$VER; \
+    mkdir mon/node_modules; \
+    cd mon/node_modules; \
+    curl -s https://git.yourcmc.ru/vitalif/antietcd/archive/master.tar.gz | tar -zx; \
+    curl -s https://git.yourcmc.ru/vitalif/tinyraft/archive/master.tar.gz | tar -zx; \
+    cd /root/packages/vitastor-$REL; \
+    tar --sort=name --mtime='2020-01-01' --owner=0 --group=0 --exclude=debian -cJf vitastor_$VER.orig.tar.xz vitastor-$VER; \
+    cd vitastor-$VER; \
+    DEBFULLNAME="Vitaliy Filippov <vitalif@yourcmc.ru>" dch -D $REL -v "$FULLVER""$REL" "Rebuild for $REL"; \
+    DEB_BUILD_OPTIONS=nocheck dpkg-buildpackage --jobs=auto -sa; \
+    rm -rf /root/packages/vitastor-$REL/vitastor-*/

docker/Dockerfile

@@ -1,9 +1,9 @@
 # Build Docker image with Vitastor packages
 
-FROM debian:trixie
+FROM debian:bookworm
 
 ADD etc/apt /etc/apt/
-RUN apt-get update && apt-get -y install vitastor ibverbs-providers udev systemd qemu-system-x86 qemu-system-common qemu-block-extra qemu-utils jq nfs-common && apt-get clean
+RUN apt-get update && apt-get -y install vitastor qemu-system-x86 qemu-system-common qemu-block-extra qemu-utils jq nfs-common && apt-get clean
 ADD sleep.sh /usr/bin/
 ADD install.sh /usr/bin/
 ADD scripts /opt/scripts/

docker/Makefile

@@ -1,9 +1,9 @@
-VITASTOR_VERSION ?= v3.2.2
+VITASTOR_VERSION ?= v1.11.0
 
 all: build push
 
 build:
-	@docker build --no-cache --rm -t vitalif/vitastor:$(VITASTOR_VERSION) .
+	@docker build --rm -t vitalif/vitastor:$(VITASTOR_VERSION) .
 
 push:
 	@docker push vitalif/vitastor:$(VITASTOR_VERSION)

docker/etc/apt/preferences

@@ -1,3 +0,0 @@
-Package: *
-Pin: release n=trixie-backports
-Pin-Priority: 500

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

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

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

@@ -12,7 +12,12 @@ EnvironmentFile=/etc/vitastor/etcd.conf
 SyslogIdentifier=etcd
 ExecStart=bash -c 'docker run --rm -i -v /var/lib/vitastor/etcd:/data \
     --log-driver none --network host $CONTAINER_OPTIONS --name vitastor-etcd \
-    $ETCD_IMAGE /usr/local/bin/etcd --data-dir /data
+    $ETCD_IMAGE /usr/local/bin/etcd --name "$ETCD_NAME" --data-dir /data \
+    --snapshot-count 10000 --advertise-client-urls http://$ETCD_IP:2379 --listen-client-urls http://$ETCD_IP:2379 \
+    --initial-advertise-peer-urls http://$ETCD_IP:2380 --listen-peer-urls http://$ETCD_IP:2380 \
+    --initial-cluster-token vitastor-etcd-1 --initial-cluster "$ETCD_INITIAL_CLUSTER" \
+    --initial-cluster-state new --max-txn-ops=100000 --max-request-bytes=104857600 \
+    --auto-compaction-retention=10 --auto-compaction-mode=revision'
 ExecStop=docker stop vitastor-etcd
 Restart=always
 StartLimitInterval=0

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

@@ -7,8 +7,8 @@ PartOf=vitastor.target
 [Service]
 Restart=always
 EnvironmentFile=/etc/vitastor/docker.conf
-ExecStart=bash -c 'docker run --rm -i -v /etc/vitastor:/etc/vitastor -v /dev:/dev -v /run:/run -e SYSTEMD_IN_CHROOT=0 \
-    --security-opt seccomp=unconfined --privileged --pid=host --log-driver none --network host --name vitastor vitastor:$VITASTOR_VERSION \
+ExecStart=bash -c 'docker run --rm -i -v /etc/vitastor:/etc/vitastor -v /dev:/dev \
+    --privileged --log-driver none --network host --name vitastor vitastor:$VITASTOR_VERSION \
     sleep.sh'
 ExecStartPost=udevadm trigger
 ExecStop=docker stop vitastor

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

@@ -12,8 +12,7 @@ EnvironmentFile=/etc/vitastor/docker.conf
 SyslogIdentifier=vitastor-osd%i
 ExecStart=bash -c 'docker run --rm -i -v /etc/vitastor:/etc/vitastor -v /dev:/dev \
     $(for i in $(ls /dev/vitastor/osd%i-*); do echo --device $i:$i; done) \
-    --log-driver none --network host --ulimit nofile=1048576 --ulimit memlock=-1 \
-    --security-opt seccomp=unconfined $CONTAINER_OPTIONS --name vitastor-osd%i \
+    --log-driver none --network host --ulimit nofile=1048576 --ulimit memlock=-1 $CONTAINER_OPTIONS --name vitastor-osd%i \
     vitastor:$VITASTOR_VERSION vitastor-disk exec-osd /dev/vitastor/osd%i-data'
 ExecStartPre=+docker exec vitastor vitastor-disk pre-exec /dev/vitastor/osd%i-data
 ExecStop=docker stop vitastor-etcd%i

docker/etc/vitastor/docker.conf

@@ -4,7 +4,7 @@
 #
 
 # Desired Vitastor version
-VITASTOR_VERSION=v3.2.2
+VITASTOR_VERSION=1.11.0
 
 # Additional arguments for all containers
 # For example, you may want to specify a custom logging driver here

docker/etc/vitastor/etcd.conf

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

docker/install.sh

@@ -2,7 +2,8 @@
 
 set -e
 
-cp -urv /etc/systemd/system/vitastor* /host-etc/systemd/system/
-cp -urv /etc/udev/rules.d /host-etc/udev/
+cp -urv /etc/default /host-etc/
+cp -urv /etc/systemd /host-etc/
+cp -urv /etc/udev /host-etc/
 cp -urnv /etc/vitastor /host-etc/
 cp -urnv /opt/scripts/* /host-bin/

docs/config.en.md

@@ -38,4 +38,3 @@ In the future, additional configuration methods may be added:
 - [OSD Disk Layout](config/layout-osd.en.md)
 - [OSD Runtime Parameters](config/osd.en.md)
 - [Monitor](config/monitor.en.md)
-- [Security Parameters](config/security.en.md)

docs/config.ru.md

@@ -41,4 +41,3 @@
 - [Дисковые параметры OSD](config/layout-osd.ru.md)
 - [Прочие параметры OSD](config/osd.ru.md)
 - [Параметры мониторов](config/monitor.ru.md)
-- [Параметры безопасности](config/security.ru.md)

docs/config/client.en.md

@@ -13,7 +13,6 @@ affect their interaction with the cluster.
 - [client_retry_interval](#client_retry_interval)
 - [client_eio_retry_interval](#client_eio_retry_interval)
 - [client_retry_enospc](#client_retry_enospc)
-- [client_wait_up_timeout](#client_wait_up_timeout)
 - [client_max_dirty_bytes](#client_max_dirty_bytes)
 - [client_max_dirty_ops](#client_max_dirty_ops)
 - [client_enable_writeback](#client_enable_writeback)
@@ -24,10 +23,6 @@ affect their interaction with the cluster.
 - [nbd_max_devices](#nbd_max_devices)
 - [nbd_max_part](#nbd_max_part)
 - [osd_nearfull_ratio](#osd_nearfull_ratio)
-- [hostname](#hostname)
-- [ublk_queue_depth](#ublk_queue_depth)
-- [ublk_max_io_size](#ublk_max_io_size)
-- [qemu_file_mirror_path](#qemu_file_mirror_path)
 
 ## client_iothread_count
 
@@ -75,19 +70,6 @@ and clients are not blocked and just get EIO error code instead.
 Retry writes on out of space errors to wait until some space is freed on
 OSDs.
 
-## client_wait_up_timeout
-
-- Type: seconds
-- Default: 16
-- Can be changed online: yes
-
-Wait for this number of seconds until PGs are up when doing operations
-which require all PGs to be up. Currently only used by object listings
-in delete and merge-based commands ([vitastor-cli rm](../usage/cli.en.md#rm), merge and so on).
-
-The default value is calculated as `1 + OSD lease timeout`, which is
-`1 + etcd_report_interval + max_etcd_attempts*2*etcd_quick_timeout`.
-
 ## client_max_dirty_bytes
 
 - Type: integer
@@ -219,37 +201,3 @@ just one OSD becomes 100 % full!
 However, unlike in Ceph, 100 % full Vitastor OSDs don't crash (in Ceph they're
 unable to start at all), so you'll be able to recover from "out of space" errors
 without destroying and recreating OSDs.
-
-## hostname
-
-- Type: string
-- Can be changed online: yes
-
-Clients use host name to find their distance to OSDs when [localized reads](pool.en.md#local_reads)
-are enabled. By default, standard [gethostname](https://man7.org/linux/man-pages/man2/gethostname.2.html)
-function is used to determine host name, but you can also override it with this parameter.
-
-## ublk_queue_depth
-
-- Type: integer
-- Default: 256
-
-Default queue depth for [Vitastor ublk servers](../usage/ublk.en.md).
-
-## ublk_max_io_size
-
-- Type: integer
-
-Default maximum I/O size for Vitastor [ublk servers](../usage/ublk.en.md).
-The largest of 1 MB and pool block size multiplied by EC data chunk count is used if not specified.
-
-## qemu_file_mirror_path
-
-- Type: string
-
-When set to an FS directory path (for example, `/mnt/vitastor/`), `qemu-img info` and similar
-QAPI commands return the name of the image inside this directory instead of normal
-`vitastor://?image=abc` URI as `filename`.
-
-This allows to then mount this path using [vitastor-nfs](../usage/nfs.en.md) and trick
-third-party systems like Veeam which rely on `filename` in the image info but don't support Vitastor.

docs/config/client.ru.md

@@ -13,7 +13,6 @@
 - [client_retry_interval](#client_retry_interval)
 - [client_eio_retry_interval](#client_eio_retry_interval)
 - [client_retry_enospc](#client_retry_enospc)
-- [client_wait_up_timeout](#client_wait_up_timeout)
 - [client_max_dirty_bytes](#client_max_dirty_bytes)
 - [client_max_dirty_ops](#client_max_dirty_ops)
 - [client_enable_writeback](#client_enable_writeback)
@@ -24,10 +23,6 @@
 - [nbd_max_devices](#nbd_max_devices)
 - [nbd_max_part](#nbd_max_part)
 - [osd_nearfull_ratio](#osd_nearfull_ratio)
-- [hostname](#hostname)
-- [ublk_queue_depth](#ublk_queue_depth)
-- [ublk_max_io_size](#ublk_max_io_size)
-- [qemu_file_mirror_path](#qemu_file_mirror_path)
 
 ## client_iothread_count
 
@@ -77,19 +72,6 @@ RDMA и хотите повысить пиковую производитель
 Повторять запросы записи, завершившиеся с ошибками нехватки места, т.е.
 ожидать, пока на OSD не освободится место.
 
-## client_wait_up_timeout
-
-- Тип: секунды
-- Значение по умолчанию: 16
-- Можно менять на лету: да
-
-Время ожидания поднятия PG при операциях, требующих активности всех PG.
-В данный момент используется листингами объектов в командах, использующих
-удаление и слияние ([vitastor-cli rm](../usage/cli.ru.md#rm), merge и подобные).
-
-Значение по умолчанию вычисляется как `1 + время lease OSD`, равное
-`1 + etcd_report_interval + max_etcd_attempts*2*etcd_quick_timeout`.
-
 ## client_max_dirty_bytes
 
 - Тип: целое число
@@ -223,40 +205,3 @@ RDMA и хотите повысить пиковую производитель
 заполненные на 100% OSD вообще не могут стартовать), так что вы сможете
 восстановить работу кластера после ошибок отсутствия свободного места
 без уничтожения и пересоздания OSD.
-
-## hostname
-
-- Тип: строка
-- Можно менять на лету: да
-
-Клиенты используют имя хоста для определения расстояния до OSD, когда включены
-[локальные чтения](pool.ru.md#local_reads). По умолчанию для определения имени
-хоста используется стандартная функция [gethostname](https://man7.org/linux/man-pages/man2/gethostname.2.html),
-но вы также можете задать имя хоста вручную данным параметром.
-
-## ublk_queue_depth
-
-- Тип: целое число
-- Значение по умолчанию: 256
-
-Глубина очереди по умолчанию для [ublk-серверов Vitastor](../usage/ublk.ru.md).
-
-## ublk_max_io_size
-
-- Тип: целое число
-
-Максимальный размер запроса ввода-вывода для [ublk-серверов Vitastor](../usage/ublk.ru.md).
-Если не задан, используется максимум из 1 МБ и размера блока пула, умноженного на число частей
-данных EC-пула.
-
-## qemu_file_mirror_path
-
-- Тип: строка
-
-Если установить эту опцию равной пути к каталогу в ФС, команда `qemu-img info` и подобные
-команды QAPI будут возвращать в поле `filename` имя образа внутри заданного каталога вместо
-обычного адреса типа `vitastor://?image=abc`.
-
-Это позволяет смонтировать этот путь с помощью [vitastor-nfs](../usage/nfs.ru.md) и обмануть
-сторонние системы типа Veeam, которые полагаются на поле `filename` в информации об образе QEMU,
-но не поддерживают Vitastor.

docs/config/layout-osd.en.md

@@ -9,7 +9,6 @@
 These parameters apply to OSDs, are fixed at the moment of OSD drive
 initialization and can't be changed after it without losing data.
 
-- [meta_format](#meta_format)
 - [data_device](#data_device)
 - [meta_device](#meta_device)
 - [journal_device](#journal_device)
@@ -28,21 +27,6 @@ initialization and can't be changed after it without losing data.
 - [data_csum_type](#data_csum_type)
 - [csum_block_size](#csum_block_size)
 
-## meta_format
-
-- Type: integer
-- Default: 3
-
-OSD store implementation version and on-disk metadata format.
-
-Three versions are currently supported: 3, 2 and 1.
-- 3 the new log-structured store, it's overall faster, has lower Write
-  Amplification, which may be even close to 1 (i.e. almost no extra writes)
-  if your SSDs support atomic writes (see [atomic_write_size](osd.en.md#atomic_write_size)).
-- 2 is the old stable store from Vitastor 0.9-2.x.
-- 1 is the same old store but with a legacy metadata format from Vitastor
-  versions to up 0.8.x, without any support for checksums.
-
 ## data_device
 
 - Type: string
@@ -198,14 +182,8 @@ put a modified value into etcd key /vitastor/config/global.
 - Type: string
 - Default: none
 
-Data and metadata checksum type to use. May be "crc32c", "xxh3_32" or "none".
-Select crc32c or xxh3_32 and set csum_block_size to enable data checksums.
-
-Both crc32c and xxh3_32 are almost equally fast, xxh3_32 is safer. xxh3_32 is
-the xxhash3 algorithm truncated from 64 to 32 bits (which is still a good hash).
-
-Note that enabled data checksums either increase memory usage or reduce
-performance. Check details in [csum_block_size](#csum_block_size) description.
+Data checksum type to use. May be "crc32c" or "none". Set to "crc32c" to
+enable data checksums.
 
 ## csum_block_size
 

docs/config/layout-osd.ru.md

@@ -10,7 +10,6 @@
 дисковые параметры, задаются в момент инициализации дисков OSD и не могут быть
 изменены после этого без потери данных.
 
-- [meta_format](#meta_format)
 - [data_device](#data_device)
 - [meta_device](#meta_device)
 - [journal_device](#journal_device)
@@ -29,23 +28,6 @@
 - [data_csum_type](#data_csum_type)
 - [csum_block_size](#csum_block_size)
 
-## meta_format
-
-- Тип: целое число
-- Значение по умолчанию: 3
-
-Версия реализации дискового хранилища OSD и дискового формата метаданных.
-
-Поддерживаются три версии: 3, 2 и 1.
-- 3 - новое лог-структурированное хранилище, в целом более быстрое, со
-  сниженным фактором амплификации записи, который может составлять около 1
-  (то есть, практически без лишней служебной записи), если ваши SSD
-  поддерживают атомарную запись (см. [atomic_write_size](osd.ru.md#atomic_write_size)).
-- 2 - старое стабильное хранилище из версий Vitastor 0.9-2.x.
-- 1 - то же самое стабильное хранилище, но с ещё более старым форматом
-  метаданных из версий Vitastor до 0.8.x, без какой-либо поддержки
-  контрольных сумм.
-
 ## data_device
 
 - Тип: строка
@@ -209,12 +191,8 @@ journal_block_size и meta_block_size. Однако на данный момен
 - Тип: строка
 - Значение по умолчанию: none
 
-Тип используемых OSD контрольных сумм данных и метаданных. Может быть "crc32c",
-"xxh3_32" или "none". Выберите crc32c или xxh3_32 и установите csum_block_size,
-чтобы включить контрольные суммы данных.
-
-И crc32c, и xxh3_32 примерно одинаково быстры, xxh3_32 надёжней. xxh3_32 - это
-алгоритм xxhash3, обрезанный с 64 до 32 бит (это всё равно хороший хеш).
+Тип используемых OSD контрольных сумм данных. Может быть "crc32c" или "none".
+Установите в "crc32c", чтобы включить расчёт и проверку контрольных сумм данных.
 
 Следует понимать, что контрольные суммы в зависимости от размера блока их
 расчёта либо увеличивают потребление памяти, либо снижают производительность.

docs/config/monitor.en.md

@@ -50,9 +50,6 @@ or antietcd_data_dir options). All other antietcd parameters
 cluster, cluster_key, persist_filter, stale_read can also be set in
 Vitastor configuration with `antietcd_` prefix.
 
-See also: [antietcd_cert](security.en.md#antietcd_cert),
-[antietcd_key](security.en.md#antietcd_key) and [etcd_proxy](security.en.md#etcd_proxyurls).
-
 You can dump/load data to or from antietcd using Antietcd `anticli` tool:
 
 ```
@@ -77,13 +74,13 @@ Grafana dashboard suitable for this exporter is here: [Vitastor-Grafana-6+.json]
 - Type: integer
 - Default: 8060
 
-HTTP port for monitors to listen to (including metrics exporter)
+HTTP port for monitors to listen on (including metrics exporter)
 
 ## mon_http_ip
 
 - Type: string
 
-IP address for monitors to listen to (all addresses by default)
+IP address for monitors to listen on (all addresses by default)
 
 ## mon_https_cert
 

docs/config/monitor.ru.md

@@ -50,9 +50,6 @@ antietcd_data_file или antietcd_data_dir). Все остальные пара
 node_id, cluster, cluster_key, persist_filter, stale_read также можно задавать
 в конфигурации Vitastor с префиксом `antietcd_`.
 
-Смотрите также настройки [antietcd_cert](security.ru.md#antietcd_cert),
-[antietcd_key](security.ru.md#antietcd_key) и [etcd_proxy](security.ru.md#etcd_proxyurls).
-
 Вы можете выгружать/загружать данные в или из antietcd с помощью его инструмента
 `anticli`:
 

docs/config/network.en.md

@@ -9,22 +9,18 @@
 These parameters apply to clients and OSDs and affect network connection logic
 between clients, OSDs and etcd.
 
-- [osd_network](#osd_network)
-- [osd_cluster_network](#osd_cluster_network)
+- [tcp_header_buffer_size](#tcp_header_buffer_size)
+- [use_sync_send_recv](#use_sync_send_recv)
 - [use_rdma](#use_rdma)
-- [use_rdmacm](#use_rdmacm)
-- [disable_tcp](#disable_tcp)
 - [rdma_device](#rdma_device)
 - [rdma_port_num](#rdma_port_num)
 - [rdma_gid_index](#rdma_gid_index)
-- [rdma_traffic_class](#rdma_traffic_class)
-- [rdma_sl](#rdma_sl)
-- [rdma_set_flow_label](#rdma_set_flow_label)
 - [rdma_mtu](#rdma_mtu)
 - [rdma_max_sge](#rdma_max_sge)
 - [rdma_max_msg](#rdma_max_msg)
 - [rdma_max_recv](#rdma_max_recv)
 - [rdma_max_send](#rdma_max_send)
+- [rdma_odp](#rdma_odp)
 - [peer_connect_interval](#peer_connect_interval)
 - [peer_connect_timeout](#peer_connect_timeout)
 - [osd_idle_timeout](#osd_idle_timeout)
@@ -34,64 +30,38 @@ between clients, OSDs and etcd.
 - [etcd_slow_timeout](#etcd_slow_timeout)
 - [etcd_keepalive_timeout](#etcd_keepalive_timeout)
 - [etcd_ws_keepalive_interval](#etcd_ws_keepalive_interval)
-- [etcd_min_reload_interval](#etcd_min_reload_interval)
-- [tcp_header_buffer_size](#tcp_header_buffer_size)
-- [rxbounce](#rxbounce)
-- [min_zerocopy_send_size](#min_zerocopy_send_size)
-- [use_sync_send_recv](#use_sync_send_recv)
 
-## osd_network
+## tcp_header_buffer_size
 
-- Type: string or array of strings
+- Type: integer
+- Default: 65536
 
-Network mask of public OSD network(s) (IPv4 or IPv6). Each OSD listens to all
-addresses of UP + RUNNING interfaces matching one of these networks, on the
-same port. Port is auto-selected except if [bind_port](osd.en.md#bind_port) is
-explicitly specified. Bind address(es) may also be overridden manually by
-specifying [bind_address](osd.en.md#bind_address). If OSD networks are not specified
-at all, OSD just listens to a wildcard address (0.0.0.0).
+Size of the buffer used to read data using an additional copy. Vitastor
+packet headers are 128 bytes, payload is always at least 4 KB, so it is
+usually beneficial to try to read multiple packets at once even though
+it requires to copy the data an additional time. The rest of each packet
+is received without an additional copy. You can try to play with this
+parameter and see how it affects random iops and linear bandwidth if you
+want.
 
-## osd_cluster_network
+## use_sync_send_recv
 
-- Type: string or array of strings
+- Type: boolean
+- Default: false
 
-Network mask of separate network(s) (IPv4 or IPv6) to use for OSD
-cluster connections. I.e. OSDs will always attempt to use these networks
-to connect to other OSDs, while clients will attempt to use networks from
-[osd_network](#osd_network).
+If true, synchronous send/recv syscalls are used instead of io_uring for
+socket communication. Useless for OSDs because they require io_uring anyway,
+but may be required for clients with old kernel versions.
 
 ## use_rdma
 
 - Type: boolean
 - Default: true
 
-Try to use RDMA through libibverbs for communication if it's available.
-Disable if you don't want Vitastor to use RDMA. TCP-only clients can also
-talk to an RDMA-enabled cluster, so disabling RDMA may be needed if clients
-have RDMA devices, but they are not connected to the cluster.
-
-`use_rdma` works with RoCEv1/RoCEv2 networks, but not with iWARP and,
-maybe, with some Infiniband configurations which require RDMA-CM.
-Consider `use_rdmacm` for such networks.
-
-## use_rdmacm
-
-- Type: boolean
-- Default: false
-
-Use an alternative implementation of RDMA through RDMA-CM (Connection
-Manager). Works with all RDMA networks: Infiniband, iWARP and
-RoCEv1/RoCEv2, and even allows to disable TCP and run only with RDMA.
-OSDs always use random port numbers for RDMA-CM listeners, different
-from their TCP ports. `use_rdma` is automatically disabled when
-`use_rdmacm` is enabled.
-
-## disable_tcp
-
-- Type: boolean
-- Default: true
-
-Fully disable TCP and only use RDMA-CM for OSD communication.
+Try to use RDMA for communication if it's available. Disable if you don't
+want Vitastor to use RDMA. TCP-only clients can also talk to an RDMA-enabled
+cluster, so disabling RDMA may be needed if clients have RDMA devices,
+but they are not connected to the cluster.
 
 ## rdma_device
 
@@ -105,6 +75,11 @@ found or if `osd_network` is not specified. Auto-selection is also
 unsupported with old libibverbs < v32, like in Debian 10 Buster or
 CentOS 7.
 
+Vitastor supports all adapters, even ones without ODP support, like
+Mellanox ConnectX-3 and non-Mellanox cards. Versions up to Vitastor
+1.2.0 required ODP which is only present in Mellanox ConnectX >= 4.
+See also [rdma_odp](#rdma_odp).
+
 Run `ibv_devinfo -v` as root to list available RDMA devices and their
 features.
 
@@ -114,33 +89,15 @@ 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).
 
-Vitastor supports all adapters, even ones without ODP (On-Demand Paging)
-support, like Mellanox ConnectX-3 and non-Mellanox cards. ODP is only present
-in Mellanox ConnectX >= 4 adapters and allows to skip memory registration
-for RDMA and thus, in theory, avoid memory copying.
-
-Versions up to Vitastor 1.2.0 required ODP, then it was disabled by default,
-but it was still supported up to 3.0.3. Now ODP support is removed because it
-actually only hurts performance: an example 3-node cluster with 8 NVMe in each
-node and 2*25 GBit/s ConnectX-6 RDMA network pushed 3950000 read iops without
-ODP, 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
-
 ## rdma_port_num
 
 - Type: integer
+- Default: 1
 
 RDMA device port number to use. Only for devices that have more than 1 port.
 See `phys_port_cnt` in `ibv_devinfo -v` output to determine how many ports
 your device has.
 
-Not relevant for RDMA-CM (use_rdmacm).
-
 ## rdma_gid_index
 
 - Type: integer
@@ -156,48 +113,13 @@ GID auto-selection is unsupported with libibverbs < v32.
 
 A correct rdma_gid_index for RoCEv2 is usually 1 (IPv6) or 3 (IPv4).
 
-Not relevant for RDMA-CM (use_rdmacm).
-
-## rdma_traffic_class
-
-- Type: integer
-- Default: 0
-
-Full TOS byte for RDMA traffic in the IP header (RoCEv2): DSCP in the
-higher 6 bits and ECN in the lower 2 bits. For example, 106 (0x6A) =
-DSCP 26 + ECT(0). Works with both libibverbs and RDMA-CM modes and should
-be set on both OSDs and clients to mark traffic in both directions.
-Default 0 = don't mark.
-
-## rdma_sl
-
-- Type: integer
-- Default: 0
-
-Service Level (802.1p priority analogue) for RDMA traffic, put into the
-address vector of every connection. Only applies to the libibverbs mode:
-in RDMA-CM mode the service level is derived from rdma_traffic_class.
-Default 0 = as is without PFC-configured networks.
-
-## rdma_set_flow_label
-
-- Type: boolean
-- Default: false
-
-Automatically derive an IPv6 Flow Label for RDMA connections from the
-queue pair number pair, so that every connection gets its own label and
-connections spread over ECMP links while each connection keeps a single
-stable path.  Only applied to IPv6 GIDs: an IPv4-mapped GID
-(::ffff:a.b.c.d) produces IPv4 packets which have no flow label.  Only
-applies to the libibverbs mode; RDMA-CM generates flow labels on its own.
-Default false = don't set.
-
 ## rdma_mtu
 
 - Type: integer
+- Default: 4096
 
-RDMA Path MTU to use. Must be 1024, 2048 or 4096. Default is to use the
-RDMA device's MTU.
+RDMA Path MTU to use. Must be 1024, 2048 or 4096. There is usually no
+sense to change it from the default 4096.
 
 ## rdma_max_sge
 
@@ -236,6 +158,28 @@ less than `rdma_max_recv` so the receiving side doesn't run out of buffers.
 Doesn't affect memory usage - additional memory isn't allocated for send
 operations.
 
+## rdma_odp
+
+- Type: boolean
+- Default: false
+
+Use RDMA with On-Demand Paging. ODP is currently only available on Mellanox
+ConnectX-4 and newer adapters. ODP allows to not register memory explicitly
+for RDMA adapter to be able to use it. This, in turn, allows to skip memory
+copying during sending. One would think this should improve performance, but
+**in reality** RDMA performance with ODP is **drastically** worse. Example
+3-node cluster with 8 NVMe in each node and 2*25 GBit/s ConnectX-6 RDMA network
+without ODP pushes 3950000 read iops, but only 239000 iops with ODP...
+
+This happens because Mellanox ODP implementation seems to be based on
+message retransmissions when the adapter doesn't know about the buffer yet -
+it likely uses standard "RNR retransmissions" (RNR = receiver not ready)
+which is generally slow in RDMA/RoCE networks. Here's a presentation about
+it from ISPASS-2021 conference: https://tkygtr6.github.io/pub/ISPASS21_slides.pdf
+
+ODP support is retained in the code just in case a good ODP implementation
+appears one day.
+
 ## peer_connect_interval
 
 - Type: seconds
@@ -317,78 +261,3 @@ etcd_report_interval to guarantee that keepalive actually works.
 
 etcd websocket ping interval required to keep the connection alive and
 detect disconnections quickly.
-
-## etcd_min_reload_interval
-
-- Type: milliseconds
-- Default: 1000
-- Can be changed online: yes
-
-Minimum interval for full etcd state reload. Introduced to prevent
-excessive load on etcd during outages when etcd can't keep up with event
-streams and cancels them.
-
-## tcp_header_buffer_size
-
-- Type: integer
-- Default: 65536
-
-Size of the buffer used to read data using an additional copy. Vitastor
-packet headers are 128 bytes, payload is always at least 4 KB, so it is
-usually beneficial to try to read multiple packets at once even though
-it requires to copy the data an additional time. The rest of each packet
-is received without an additional copy. You can try to play with this
-parameter and see how it affects random iops and linear bandwidth if you
-want.
-
-## rxbounce
-
-- Type: boolean
-- Default: false
-- Can be changed online: yes
-
-Receive all TCP data into an intermediate buffer before copying to the actual
-destination. Enabling this option is required for Windows guests if you use TCP
-and [security.en.md#proto_checksums](proto_checksums) because Windows uses a
-shared system-wide 'dummy page' to skip unneeded blocks during reads and breaks
-checksum verification with it when data copy is avoided. rxbounce is only needed
-when you use TCP and don't use transport encryption (AES-GCM); it's not required
-with RDMA or with GCM encryption because both always copy data anyway (yes, RDMA
-isn't actually zerocopy in Vitastor).
-
-## min_zerocopy_send_size
-
-- Type: integer
-- Default: 32768
-
-OSDs and clients will attempt to use io_uring-based zero-copy TCP send
-for buffers larger than this number of bytes. Zero-copy send with io_uring is
-supported since Linux kernel version 6.1. Support is auto-detected and disabled
-automatically when not available. It can also be disabled explicitly by setting
-this parameter to a negative value.
-
-⚠️ Warning! Zero-copy send performance may vary greatly from CPU to CPU and from
-one kernel version to another. Generally, it tends to only make benefit with larger
-messages. With smaller messages (say, 4 KB), it may actually be slower. 32 KB is
-enough for almost all CPUs, but even smaller values are optimal for some of them.
-For example, 4 KB is OK for EPYC Milan/Genoa and 12 KB is OK for Xeon Ice Lake
-(but verify it yourself please).
-
-Verification instructions:
-1. Add `iommu=pt` into your Linux kernel command line and reboot.
-2. Upgrade your kernel. For example, it's very important to use 6.11+ with recent AMD EPYCs.
-3. Run some tests with the [send-zerocopy liburing example](https://github.com/axboe/liburing/blob/master/examples/send-zerocopy.c)
-   to find the minimal message size for which zero-copy is optimal.
-   Use `./send-zerocopy tcp -4 -R` at the server side and
-   `time ./send-zerocopy tcp -4 -b 0 -s BUFFER_SIZE -D SERVER_IP` at the client side with
-   `-z 0` (no zero-copy) and `-z 1` (zero-copy), and compare MB/s and used CPU time
-   (user+system).
-
-## use_sync_send_recv
-
-- Type: boolean
-- Default: false
-
-If true, synchronous send/recv syscalls are used instead of io_uring for
-socket communication. Useless for OSDs because they require io_uring anyway,
-but may be required for clients with old kernel versions.

docs/config/network.ru.md

@@ -9,22 +9,18 @@
 Данные параметры используются клиентами и OSD и влияют на логику сетевого
 взаимодействия между клиентами, OSD, а также etcd.
 
-- [osd_network](#osd_network)
-- [osd_cluster_network](#osd_cluster_network)
+- [tcp_header_buffer_size](#tcp_header_buffer_size)
+- [use_sync_send_recv](#use_sync_send_recv)
 - [use_rdma](#use_rdma)
-- [use_rdmacm](#use_rdmacm)
-- [disable_tcp](#disable_tcp)
 - [rdma_device](#rdma_device)
 - [rdma_port_num](#rdma_port_num)
 - [rdma_gid_index](#rdma_gid_index)
-- [rdma_traffic_class](#rdma_traffic_class)
-- [rdma_sl](#rdma_sl)
-- [rdma_set_flow_label](#rdma_set_flow_label)
 - [rdma_mtu](#rdma_mtu)
 - [rdma_max_sge](#rdma_max_sge)
 - [rdma_max_msg](#rdma_max_msg)
 - [rdma_max_recv](#rdma_max_recv)
 - [rdma_max_send](#rdma_max_send)
+- [rdma_odp](#rdma_odp)
 - [peer_connect_interval](#peer_connect_interval)
 - [peer_connect_timeout](#peer_connect_timeout)
 - [osd_idle_timeout](#osd_idle_timeout)
@@ -34,64 +30,41 @@
 - [etcd_slow_timeout](#etcd_slow_timeout)
 - [etcd_keepalive_timeout](#etcd_keepalive_timeout)
 - [etcd_ws_keepalive_interval](#etcd_ws_keepalive_interval)
-- [etcd_min_reload_interval](#etcd_min_reload_interval)
-- [tcp_header_buffer_size](#tcp_header_buffer_size)
-- [rxbounce](#rxbounce)
-- [min_zerocopy_send_size](#min_zerocopy_send_size)
-- [use_sync_send_recv](#use_sync_send_recv)
 
-## osd_network
+## tcp_header_buffer_size
 
-- Тип: строка или массив строк
+- Тип: целое число
+- Значение по умолчанию: 65536
 
-Маски подсетей (IPv4 или IPv6) публичной сети или сетей OSD. Каждый OSD слушает
-один и тот же порт на всех адресах поднятых (UP + RUNNING) сетевых интерфейсов,
-соответствующих одной из указанных сетей. Порт выбирается автоматически, если
-только [bind_port](osd.ru.md#bind_port) не задан явно. Адреса для подключений можно
-также переопределить явно, задав [bind_address](osd.ru.md#bind_address). Если сети OSD
-не заданы вообще, OSD слушает все адреса (0.0.0.0).
+Размер буфера для чтения данных с дополнительным копированием. Пакеты
+Vitastor содержат 128-байтные заголовки, за которыми следуют данные размером
+от 4 КБ и для мелких операций ввода-вывода обычно выгодно за 1 вызов читать
+сразу несколько пакетов, даже не смотря на то, что это требует лишний раз
+скопировать данные. Часть каждого пакета за пределами значения данного
+параметра читается без дополнительного копирования. Вы можете попробовать
+поменять этот параметр и посмотреть, как он влияет на производительность
+случайного и линейного доступа.
 
-## osd_cluster_network
+## use_sync_send_recv
 
-- Тип: строка или массив строк
+- Тип: булево (да/нет)
+- Значение по умолчанию: false
 
-Маски подсетей (IPv4 или IPv6) отдельной кластерной сети или сетей OSD.
-То есть, OSD будут всегда стараться использовать эти сети для соединений
-с другими OSD, а клиенты будут стараться использовать сети из [osd_network](#osd_network).
+Если установлено в истину, то вместо io_uring для передачи данных по сети
+будут использоваться обычные синхронные системные вызовы send/recv. Для OSD
+это бессмысленно, так как OSD в любом случае нуждается в io_uring, но, в
+принципе, это может применяться для клиентов со старыми версиями ядра.
 
 ## use_rdma
 
 - Тип: булево (да/нет)
 - Значение по умолчанию: true
 
-Попробовать использовать RDMA через libibverbs для связи при наличии
-доступных устройств. Отключите, если вы не хотите, чтобы Vitastor
-использовал RDMA. TCP-клиенты также могут работать с RDMA-кластером,
-так что отключать RDMA может быть нужно, только если у клиентов есть
-RDMA-устройства, но они не имеют соединения с кластером Vitastor.
-
-`use_rdma` работает с RoCEv1/RoCEv2 сетями, но не работает с iWARP и
-может не работать с частью конфигураций Infiniband, требующих RDMA-CM.
-Рассмотрите включение `use_rdmacm` для таких сетей.
-
-## use_rdmacm
-
-- Тип: булево (да/нет)
-- Значение по умолчанию: false
-
-Использовать альтернативную реализацию RDMA на основе RDMA-CM (Connection
-Manager). Работает со всеми типами RDMA-сетей: Infiniband, iWARP и
-RoCEv1/RoCEv2, и даже позволяет полностью отключить TCP и работать
-только на RDMA. OSD используют случайные номера портов для ожидания
-соединений через RDMA-CM, отличающиеся от их TCP-портов. Также при
-включении `use_rdmacm` автоматически отключается опция `use_rdma`.
-
-## disable_tcp
-
-- Тип: булево (да/нет)
-- Значение по умолчанию: true
-
-Полностью отключить TCP и использовать только RDMA-CM для соединений с OSD.
+Пытаться использовать RDMA для связи при наличии доступных устройств.
+Отключите, если вы не хотите, чтобы Vitastor использовал RDMA.
+TCP-клиенты также могут работать с RDMA-кластером, так что отключать
+RDMA может быть нужно только если у клиентов есть RDMA-устройства,
+но они не имеют соединения с кластером Vitastor.
 
 ## rdma_device
 
@@ -104,6 +77,12 @@ RoCEv1/RoCEv2, и даже позволяет полностью отключи
 не задана. Также автовыбор не поддерживается со старыми версиями библиотеки
 libibverbs < v32, например в Debian 10 Buster или CentOS 7.
 
+Vitastor поддерживает все модели адаптеров, включая те, у которых
+нет поддержки ODP, то есть вы можете использовать RDMA с ConnectX-3 и
+картами производства не Mellanox. Версии Vitastor до 1.2.0 включительно
+требовали ODP, который есть только на Mellanox ConnectX 4 и более новых.
+См. также [rdma_odp](#rdma_odp).
+
 Запустите `ibv_devinfo -v` от имени суперпользователя, чтобы посмотреть
 список доступных RDMA-устройств, их параметры и возможности.
 
@@ -114,35 +93,16 @@ libibverbs < v32, например в Debian 10 Buster или CentOS 7.
 подразумевает настройку сети без потерь на основе PFC (Priority Flow
 Control) и ECN (Explicit Congestion Notification).
 
-Vitastor поддерживает все модели адаптеров, включая те, у которых нет
-поддержки ODP (On-Demand Paging), например, ConnectX-3 и карты производства
-не Mellanox. Функция ODP доступна только на адаптерах Mellanox ConnectX-4 и
-более новых и позволяет не регистрировать память для её использования RDMA-картой,
-благодаря чему в теории можно избежать лишних копирований памяти.
-
-Версии Vitastor до 1.2.0 включительно требовали ODP, потом функция был отключена
-по умолчанию, но поддерживалась вплоть до версии 3.0.3. Сейчас поддержка ODP
-полностью удалена, так как на самом деле она только портит производительность:
-например, на 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
-
 ## rdma_port_num
 
 - Тип: целое число
+- Значение по умолчанию: 1
 
 Номер порта RDMA-устройства, который следует использовать. Имеет смысл
 только для устройств, у которых более 1 порта. Чтобы узнать, сколько портов
 у вашего адаптера, посмотрите `phys_port_cnt` в выводе команды
 `ibv_devinfo -v`.
 
-Опция неприменима к RDMA-CM (use_rdmacm).
-
 ## rdma_gid_index
 
 - Тип: целое число
@@ -159,48 +119,13 @@ libibverbs < v32.
 
 Правильный rdma_gid_index для RoCEv2, как правило, 1 (IPv6) или 3 (IPv4).
 
-Опция неприменима к RDMA-CM (use_rdmacm).
-
-## rdma_traffic_class
-
-- Тип: целое число
-- Значение по умолчанию: 0
-
-Полный байт TOS для RDMA-трафика в заголовке IP (RoCEv2): DSCP в старших
-6 битах и ECN в младших 2. Например, 106 (0x6A) = DSCP 26 + ECT(0).
-Работает в обоих режимах RDMA - и libibverbs, и RDMA-CM; должен быть задан
-и на OSD, и на клиентах, чтобы трафик помечался в обе стороны. По умолчанию
-0 - не помечать.
-
-## rdma_sl
-
-- Тип: целое число
-- Значение по умолчанию: 0
-
-Service Level (аналог приоритета 802.1p) для RDMA-трафика; попадает в
-адресный вектор каждого соединения. Применим только к libibverbs-режиму:
-в RDMA-CM уровень обслуживания выводится из rdma_traffic_class.
-По умолчанию 0 = как в сетях без PFC.
-
-## rdma_set_flow_label
-
-- Тип: булево (да/нет)
-- Значение по умолчанию: false
-
-Автоматически выводить IPv6 Flow Label для RDMA-соединений из пары
-номеров очередей (QPN), чтобы каждое соединение получало свою метку,
-соединения распределялись по ECMP-каналам, но каждое соединение шло по
-одному стабильному пути. Применяется только к IPv6-GID: IPv4-mapped GID
-(::ffff:a.b.c.d) даёт IPv4-пакеты, где поля flow label нет. Применим
-только к libibverbs-режиму - RDMA-CM всегда генерирует flow label сам.
-По умолчанию false = не задавать.
-
 ## rdma_mtu
 
 - Тип: целое число
+- Значение по умолчанию: 4096
 
 Максимальная единица передачи (Path MTU) для RDMA. Должно быть равно 1024,
-2048 или 4096. По умолчанию используется значение MTU RDMA-устройства.
+2048 или 4096. Обычно нет смысла менять значение по умолчанию, равное 4096.
 
 ## rdma_max_sge
 
@@ -241,6 +166,29 @@ OSD в любом случае согласовывают реальное зн
 Не влияет на потребление памяти - дополнительная память на операции отправки
 не выделяется.
 
+## rdma_odp
+
+- Тип: булево (да/нет)
+- Значение по умолчанию: false
+
+Использовать RDMA с On-Demand Paging. ODP - функция, доступная пока что
+исключительно на адаптерах Mellanox ConnectX-4 и более новых. ODP позволяет
+не регистрировать память для её использования RDMA-картой. Благодаря этому
+можно не копировать данные при отправке их в сеть и, казалось бы, это должно
+улучшать производительность - но **по факту** получается так, что
+производительность только ухудшается, причём сильно. Пример - на 3-узловом
+кластере с 8 NVMe в каждом узле и сетью 2*25 Гбит/с на чтение с RDMA без ODP
+удаётся снять 3950000 iops, а с ODP - всего 239000 iops...
+
+Это происходит из-за того, что реализация ODP у Mellanox неоптимальная и
+основана на повторной передаче сообщений, когда карте не известен буфер -
+вероятно, на стандартных "RNR retransmission" (RNR = receiver not ready).
+А данные повторные передачи в RDMA/RoCE - всегда очень медленная штука.
+Презентация на эту тему с конференции ISPASS-2021: https://tkygtr6.github.io/pub/ISPASS21_slides.pdf
+
+Возможность использования ODP сохранена в коде на случай, если вдруг в один
+прекрасный день появится хорошая реализация ODP.
+
 ## peer_connect_interval
 
 - Тип: секунды
@@ -323,81 +271,3 @@ etcd_report_interval, чтобы keepalive гарантированно рабо
 - Можно менять на лету: да
 
 Интервал проверки живости вебсокет-подключений к etcd.
-
-## etcd_min_reload_interval
-
-- Тип: миллисекунды
-- Значение по умолчанию: 1000
-- Можно менять на лету: да
-
-Минимальный интервал полной перезагрузки состояния из etcd. Добавлено для
-предотвращения избыточной нагрузки на etcd во время отказов, когда etcd не
-успевает рассылать потоки событий и отменяет их.
-
-## tcp_header_buffer_size
-
-- Тип: целое число
-- Значение по умолчанию: 65536
-
-Размер буфера для чтения данных с дополнительным копированием. Пакеты
-Vitastor содержат 128-байтные заголовки, за которыми следуют данные размером
-от 4 КБ и для мелких операций ввода-вывода обычно выгодно за 1 вызов читать
-сразу несколько пакетов, даже не смотря на то, что это требует лишний раз
-скопировать данные. Часть каждого пакета за пределами значения данного
-параметра читается без дополнительного копирования. Вы можете попробовать
-поменять этот параметр и посмотреть, как он влияет на производительность
-случайного и линейного доступа.
-
-## rxbounce
-
-- Тип: булево (да/нет)
-- Значение по умолчанию: false
-- Можно менять на лету: да
-
-Принимать все данные по TCP в промежуточный буфер и потом копировать их в
-буфер клиента (ВМ). Это нужно для гостевых ОС Windows с TCP и включёнными
-[security.ru.md#proto_checksums](proto_checksums), потому что Windows использует
-одну разделяемую общесистемную страницу-заглушку для пропуска ненужных блоков
-при чтении и ломает проверку контрольных сумм, если данные не копируются лишний
-раз. Опция rxbounce нужна только если вы используете TCP и не используете
-транспортное шифрование (AES-GCM); с RDMA или шифрованием опция не нужна, так
-как в этом случае данные копируются всегда (да, RDMA в Vitastor на самом деле
-не zero-copy).
-
-## min_zerocopy_send_size
-
-- Тип: целое число
-- Значение по умолчанию: 32768
-
-OSD и клиенты будут пробовать использовать TCP-отправку без копирования (zero-copy) на
-основе io_uring для буферов, больших, чем это число байт. Отправка без копирования
-поддерживается в io_uring, начиная с версии ядра Linux 6.1. Наличие поддержки
-проверяется автоматически и zero-copy отключается, когда поддержки нет. Также
-её можно отключить явно, установив данный параметр в отрицательное значение.
-
-⚠️ Внимание! Производительность данной функции может сильно отличаться на разных
-процессорах и на разных версиях ядра Linux. В целом, zero-copy обычно быстрее с
-большими сообщениями, а с мелкими (например, 4 КБ) zero-copy может быть даже
-медленнее. 32 КБ достаточно почти для всех процессоров, но для каких-то можно
-использовать даже меньшие значения. Например, для EPYC Milan/Genoa подходит 4 КБ,
-а для Xeon Ice Lake - 12 КБ (но, пожалуйста, перепроверьте это сами).
-
-Инструкция по проверке:
-1. Добавьте `iommu=pt` в командную строку загрузки вашего ядра Linux и перезагрузитесь.
-2. Обновите ядро. Например, для AMD EPYC очень важно использовать версию 6.11+.
-3. Позапускайте тесты с помощью [send-zerocopy из примеров liburing](https://github.com/axboe/liburing/blob/master/examples/send-zerocopy.c),
-   чтобы найти минимальный размер сообщения, для которого zero-copy отправка оптимальна.
-   Запускайте `./send-zerocopy tcp -4 -R` на стороне сервера и
-   `time ./send-zerocopy tcp -4 -b 0 -s РАЗМЕР_БУФЕРА -D АДРЕС_СЕРВЕРА` на стороне клиента
-   с опцией `-z 0` (обычная отправка) и `-z 1` (отправка без копирования), и сравнивайте
-   скорость в МБ/с и занятое процессорное время (user+system).
-
-## use_sync_send_recv
-
-- Тип: булево (да/нет)
-- Значение по умолчанию: false
-
-Если установлено в истину, то вместо io_uring для передачи данных по сети
-будут использоваться обычные синхронные системные вызовы send/recv. Для OSD
-это бессмысленно, так как OSD в любом случае нуждается в io_uring, но, в
-принципе, это может применяться для клиентов со старыми версиями ядра.

docs/config/osd.en.md

@@ -7,15 +7,16 @@
 # Runtime OSD Parameters
 
 These parameters only apply to OSDs, are not fixed at the moment of OSD drive
-initialization and can be changed - in /etc/vitastor/vitastor.conf or [vitastor-disk update-sb](../usage/disk.en.md#update-sb)
-with an OSD restart or, for some of them, even without restarting by updating configuration in etcd.
+initialization and can be changed - either with an OSD restart or, for some of
+them, even without restarting by updating configuration in etcd.
 
-- [bind_address](#bind_address)
-- [bind_port](#bind_port)
 - [osd_iothread_count](#osd_iothread_count)
 - [etcd_report_interval](#etcd_report_interval)
 - [etcd_stats_interval](#etcd_stats_interval)
 - [run_primary](#run_primary)
+- [osd_network](#osd_network)
+- [bind_address](#bind_address)
+- [bind_port](#bind_port)
 - [autosync_interval](#autosync_interval)
 - [autosync_writes](#autosync_writes)
 - [recovery_queue_depth](#recovery_queue_depth)
@@ -38,7 +39,6 @@ with an OSD restart or, for some of them, even without restarting by updating co
 - [journal_io](#journal_io)
 - [journal_sector_buffer_count](#journal_sector_buffer_count)
 - [journal_no_same_sector_overwrites](#journal_no_same_sector_overwrites)
-- [skip_corrupted_meta_entries](#skip_corrupted_meta_entries)
 - [throttle_small_writes](#throttle_small_writes)
 - [throttle_target_iops](#throttle_target_iops)
 - [throttle_target_mbs](#throttle_target_mbs)
@@ -61,33 +61,6 @@ with an OSD restart or, for some of them, even without restarting by updating co
 - [recovery_tune_agg_interval](#recovery_tune_agg_interval)
 - [recovery_tune_sleep_min_us](#recovery_tune_sleep_min_us)
 - [recovery_tune_sleep_cutoff_us](#recovery_tune_sleep_cutoff_us)
-- [discard_on_start](#discard_on_start)
-- [min_discard_size](#min_discard_size)
-- [allow_net_split](#allow_net_split)
-- [enable_pg_locks](#enable_pg_locks)
-- [pg_lock_retry_interval_ms](#pg_lock_retry_interval_ms)
-- [atomic_write_size](#atomic_write_size)
-- [use_atomic_flag](#use_atomic_flag)
-- [pg_reshard_chunk_size](#pg_reshard_chunk_size)
-- [pg_reshard_chunk_pause_ms](#pg_reshard_chunk_pause_ms)
-- [gc_on_start](#gc_on_start)
-
-## bind_address
-
-- Type: string or array of strings
-
-Instead of the network masks ([osd_network](network.en.md#osd_network) and
-[osd_cluster_network](network.en.md#osd_cluster_network)), you can also set
-OSD listen addresses explicitly using this parameter. May be useful if you
-want to start OSDs on interfaces that are not UP + RUNNING.
-
-## bind_port
-
-- Type: integer
-
-By default, OSDs pick random ports to use for incoming connections
-automatically. With this option you can set a specific port for a specific
-OSD by hand.
 
 ## osd_iothread_count
 
@@ -131,6 +104,34 @@ debugging purposes. It's possible to implement additional feature for the
 monitor which may allow to separate primary and secondary OSDs, but it's
 unclear why anyone could need it, so it's not implemented.
 
+## osd_network
+
+- Type: string or array of strings
+
+Network mask of the network (IPv4 or IPv6) to use for OSDs. Note that
+although it's possible to specify multiple networks here, this does not
+mean that OSDs will create multiple listening sockets - they'll only
+pick the first matching address of an UP + RUNNING interface. Separate
+networks for cluster and client connections are also not implemented, but
+they are mostly useless anyway, so it's not a big deal.
+
+## bind_address
+
+- Type: string
+- Default: 0.0.0.0
+
+Instead of the network mask, you can also set OSD listen address explicitly
+using this parameter. May be useful if you want to start OSDs on interfaces
+that are not UP + RUNNING.
+
+## bind_port
+
+- Type: integer
+
+By default, OSDs pick random ports to use for incoming connections
+automatically. With this option you can set a specific port for a specific
+OSD by hand.
+
 ## autosync_interval
 
 - Type: seconds
@@ -281,19 +282,13 @@ Maximum number of journal flushers (see above min_flusher_count).
 - Type: boolean
 - Default: true
 
-Only for the old store ([meta_format](layout-osd.en.md#meta_format) 2).
-
-This parameter makes Vitastor keep a copy of metadata area in memory as it is
-on disk, in addition to the metadata database. When the option is enabled, every
-metadata entry is effectively stored in RAM twice. It's required for good performance
-because it allows to avoid additional read-modify-write cycles during metadata
-modifications. Metadata area size with the old store is roughly 224 MB per 1 TB
-of data. You can turn the option off to reduce memory usage by this value, but
-it will reduce performance.
-
-For the new store ([meta_format](layout-osd.en.md#meta_format) 3), the option
-may be changed in the future to support operation without loading full metadata
-database in memory.
+This parameter makes Vitastor always keep metadata area of the block device
+in memory. It's required for good performance because it allows to avoid
+additional read-modify-write cycles during metadata modifications. Metadata
+area size is currently roughly 224 MB per 1 TB of data. You can turn it off
+to reduce memory usage by this value, but it will hurt performance. This
+restriction is likely to be removed in the future along with the upgrade
+of the metadata storage scheme.
 
 ## inmemory_journal
 
@@ -321,7 +316,7 @@ for hot data and slower disks - HDDs and maybe SATA SSDs - but will slightly
 decrease write performance for fast disks because page cache is an overhead
 itself.
 
-Choose "directsync" to use [immediate_commit](layout-cluster.en.md#immediate_commit)
+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
@@ -372,8 +367,6 @@ blocks. The only situation when you should increase it to a larger value
 is when you enable journal_no_same_sector_overwrites. In this case set
 it to, for example, 1024.
 
-Not applicable to the new store ([meta_format](layout-osd.en.md#meta_format) 3).
-
 ## journal_no_same_sector_overwrites
 
 - Type: boolean
@@ -387,17 +380,6 @@ journal after writing it instead of possibly overwriting it the second time.
 
 Most (99%) other SSDs don't need this option.
 
-Not applicable to the new store ([meta_format](layout-osd.en.md#meta_format) 3).
-
-## skip_corrupted_meta_entries
-
-- Type: boolean
-- Default: false
-
-Only for the new store ([meta_format](layout-osd.en.md#meta_format) 3).
-Allow OSD to start when some metadata entries or blocks are corrupted by
-skipping them. Should be only used as an emergency measure.
-
 ## throttle_small_writes
 
 - Type: boolean
@@ -516,7 +498,7 @@ Can be used to slow down scrubbing if it affects user load too much.
 ## scrub_list_limit
 
 - Type: integer
-- Default: 262144
+- Default: 1000
 - Can be changed online: yes
 
 Number of objects to list in one listing operation during scrub.
@@ -647,116 +629,3 @@ are changed to 0.
 
 Maximum possible value for auto-tuned recovery_sleep_us. Higher values
 are treated as outliers and ignored in aggregation.
-
-## discard_on_start
-
-- Type: boolean
-
-Discard (SSD TRIM) unused data device blocks on every OSD startup.
-
-## min_discard_size
-
-- Type: integer
-- Default: 1048576
-
-Minimum consecutive block size to TRIM it.
-
-## allow_net_split
-
-- Type: boolean
-- Default: false
-
-Allow "safe" cases of network splits/partitions - allow to start PGs without
-connections to some OSDs currently registered as alive in etcd, if the number
-of actually connected PG OSDs is at least pg_minsize. That is, allow some OSDs to lose
-connectivity with some other OSDs as long as it doesn't break pg_minsize guarantees.
-The downside is that it increases the probability of writing data into just pg_minsize
-OSDs during failover which can lead to PGs becoming incomplete after additional outages.
-
-The old behaviour in versions up to 2.0.0 was equal to enabled allow_net_split.
-
-## enable_pg_locks
-
-- Type: boolean
-
-Vitastor 2.2.0 introduces a new layer of split-brain prevention mechanism in
-addition to etcd: PG locks. They prevent split-brain even in abnormal theoretical cases
-when etcd is extremely laggy. As a new feature, by default, PG locks are only enabled
-for pools where they're required - pools with [localized reads](pool.en.md#local_reads).
-Use this parameter to enable or disable this function for all pools.
-
-## pg_lock_retry_interval_ms
-
-- Type: milliseconds
-- Default: 100
-
-Retry interval for failed PG lock attempts.
-
-## atomic_write_size
-
-- Type: integer
-- Default: 4096
-
-Maximum data device atomic write size allowed for OSD to use.
-
-Atomic writes allow to reduce the Write Amplification factor with the new store
-([meta_format](layout-osd.en.md#meta_format)=3) to almost 1 (i.e. almost no extra writes)
-with replicated pools and reach the best possible write performance.
-
-Default value is auto-detected during OSD initialization from
-`/sys/block/xx/queue/atomic_write_max_bytes` or assumed to be 4096 bytes
-because all known disks support 4 KB atomic writes. Auto-detection is only used for
-NVMe disks because SAS disks require the explicit WRITE ATOMIC command which requires
-RWF_ATOMIC (see below [#use_atomic_flag]) but that flag works incorrectly in current
-Linux versions.
-
-You can also check if your NVMe drives support atomic writes by running
-the command `nvme id-ctrl /dev/nvme0n1 | grep awupf`. If the reported value,
-plus 1, multiplied by the currently selected block size of the NVMe,
-is more than 4 KB, then the new store can utilize it for better performance.
-The only drives known to support it currently are [Micron and Kioxia](../intro/quickstart.en.md).
-
-Atomic writes allow to skip double data writes in replicated pools, thus
-reducing Write Amplification and improving write performance up to 2 times.
-
-## use_atomic_flag
-
-- Type: boolean
-
-This option controls whether Vitastor OSDs use RWF_ATOMIC write flag with atomic writes.
-This flag is supported since Linux 6.11 and adds some safety to atomic writes - the kernel
-guarantees to not fragment write requests with it and also to check them against the actual
-device atomic write capabilities.
-
-However, the option is disabled by default because the flag is currently UNUSABLE - Linux
-incorrectly requires writes with that flag to be of power-of-2 length and length-aligned.
-I.e., for example, 12 KB writes and not-8-KB aligned 8 KB writes are forbidden by the kernel,
-even though the NVMe specification allows them.
-
-For NVMe disks with `scheduler=none` writes aren't fragmented anyway so it's not a big deal.
-However, you can rebuild your kernel with [this patch](../../patches/linux-fix-atomic-write-checks.diff)
-and turn this option on. It will make your atomic writes a bit safer.
-
-## pg_reshard_chunk_size
-
-- Type: integer
-- Default: 100000
-
-Pool PG count change is a CPU-intensive operation because OSDs store the full object database
-in memory and have to move all entries between old and new PGs. Thus it's performed in chunks,
-with pauses between chunks to prevent blocking OSD's event loop and other clients' operations.
-This option sets the maximum number of object is a chunk. Moving 100k objects usually takes
-50-100ms. Chunk size equal to 0 means unlimited.
-
-## pg_reshard_chunk_pause_ms
-
-- Type: milliseconds
-- Default: 100
-
-This option sets the interval between handling two PG count change chunks.
-
-## gc_on_start
-
-- Type: boolean
-
-Forcibly clean all garbage entries in the new store on every OSD restart.

docs/config/osd.ru.md

@@ -8,15 +8,16 @@
 
 Данные параметры используются только OSD, но, в отличие от дисковых параметров,
 не фиксируются в момент инициализации дисков OSD и могут быть изменены в любой
-момент с перезапуском OSD в /etc/vitastor/vitastor.conf или [vitastor-disk update-sb](../usage/disk.ru.md#update-sb),
-а некоторые и без перезапуска, с помощью изменения конфигурации в etcd.
+момент с помощью перезапуска OSD, а некоторые и без перезапуска, с помощью
+изменения конфигурации в etcd.
 
-- [bind_address](#bind_address)
-- [bind_port](#bind_port)
 - [osd_iothread_count](#osd_iothread_count)
 - [etcd_report_interval](#etcd_report_interval)
 - [etcd_stats_interval](#etcd_stats_interval)
 - [run_primary](#run_primary)
+- [osd_network](#osd_network)
+- [bind_address](#bind_address)
+- [bind_port](#bind_port)
 - [autosync_interval](#autosync_interval)
 - [autosync_writes](#autosync_writes)
 - [recovery_queue_depth](#recovery_queue_depth)
@@ -39,7 +40,6 @@
 - [journal_io](#journal_io)
 - [journal_sector_buffer_count](#journal_sector_buffer_count)
 - [journal_no_same_sector_overwrites](#journal_no_same_sector_overwrites)
-- [skip_corrupted_meta_entries](#skip_corrupted_meta_entries)
 - [throttle_small_writes](#throttle_small_writes)
 - [throttle_target_iops](#throttle_target_iops)
 - [throttle_target_mbs](#throttle_target_mbs)
@@ -62,33 +62,6 @@
 - [recovery_tune_agg_interval](#recovery_tune_agg_interval)
 - [recovery_tune_sleep_min_us](#recovery_tune_sleep_min_us)
 - [recovery_tune_sleep_cutoff_us](#recovery_tune_sleep_cutoff_us)
-- [discard_on_start](#discard_on_start)
-- [min_discard_size](#min_discard_size)
-- [allow_net_split](#allow_net_split)
-- [enable_pg_locks](#enable_pg_locks)
-- [pg_lock_retry_interval_ms](#pg_lock_retry_interval_ms)
-- [atomic_write_size](#atomic_write_size)
-- [use_atomic_flag](#use_atomic_flag)
-- [pg_reshard_chunk_size](#pg_reshard_chunk_size)
-- [pg_reshard_chunk_pause_ms](#pg_reshard_chunk_pause_ms)
-- [gc_on_start](#gc_on_start)
-
-## bind_address
-
-- Тип: строка или массив строк
-
-Вместо использования масок подсети ([osd_network](network.ru.md#osd_network) и
-[osd_cluster_network](network.ru.md#osd_cluster_network)), вы также можете явно
-задать адрес(а), на которых будут ожидать соединений OSD, с помощью данного
-параметра. Это может быть полезно, например, чтобы запускать OSD на неподнятых
-интерфейсах (не UP + RUNNING).
-
-## bind_port
-
-- Тип: целое число
-
-По умолчанию OSD сами выбирают случайные порты для входящих подключений.
-С помощью данной опции вы можете задать порт для отдельного OSD вручную.
 
 ## osd_iothread_count
 
@@ -134,6 +107,34 @@ max_etcd_attempts * etcd_quick_timeout.
 первичные OSD от вторичных, но пока не понятно, зачем это может кому-то
 понадобиться, поэтому это не реализовано.
 
+## osd_network
+
+- Тип: строка или массив строк
+
+Маска подсети (IPv4 или IPv6) для использования для соединений с OSD.
+Имейте в виду, что хотя сейчас и можно передать в этот параметр несколько
+подсетей, это не означает, что OSD будут создавать несколько слушающих
+сокетов - они лишь будут выбирать адрес первого поднятого (состояние UP +
+RUNNING), подходящий под заданную маску. Также не реализовано разделение
+кластерной и публичной сетей OSD. Правда, от него обычно всё равно довольно
+мало толку, так что особенной проблемы в этом нет.
+
+## bind_address
+
+- Тип: строка
+- Значение по умолчанию: 0.0.0.0
+
+Этим параметром можно явным образом задать адрес, на котором будет ожидать
+соединений OSD (вместо использования маски подсети). Может быть полезно,
+например, чтобы запускать OSD на неподнятых интерфейсах (не UP + RUNNING).
+
+## bind_port
+
+- Тип: целое число
+
+По умолчанию OSD сами выбирают случайные порты для входящих подключений.
+С помощью данной опции вы можете задать порт для отдельного OSD вручную.
+
 ## autosync_interval
 
 - Тип: секунды
@@ -289,19 +290,13 @@ Flusher - это микро-поток (корутина), которая коп
 - Тип: булево (да/нет)
 - Значение по умолчанию: true
 
-Только для старого хранилища ([meta_format](layout-osd.en.md#meta_format) 2).
-
-Данный параметр заставляет Vitastor всегда держать копию области метаданных
-в памяти в том же виде, как она лежит на диске, в дополнение к БД метаданных.
-То есть, с включённой опцией каждая запись метаданных хранится в памяти дважды.
-Это нужно, чтобы избегать дополнительных операций чтения с диска при записи.
-Размер области метаданных в старом хранилище составляет примерно 224 МБ на
-1 ТБ данных. Вы можете отключить опцию, чтобы снизить потребление памяти
-примерно на эту величину, но при этом также снизится и производительность.
-
-Для нового хранилища ([meta_format](layout-osd.en.md#meta_format) 3) опция,
-возможно, будет переработана в будущем для поддержки работы без полной
-загрузки метаданных в памяти.
+Данный параметр заставляет Vitastor всегда держать область метаданных диска
+в памяти. Это нужно, чтобы избегать дополнительных операций чтения с диска
+при записи. Размер области метаданных на данный момент составляет примерно
+224 МБ на 1 ТБ данных. При включении потребление памяти снизится примерно
+на эту величину, но при этом также снизится и производительность. В будущем,
+после обновления схемы хранения метаданных, это ограничение, скорее всего,
+будет ликвидировано.
 
 ## inmemory_journal
 
@@ -384,8 +379,6 @@ fsync небезопасным даже с режимом "directsync".
 нужно менять - это если вы включаете journal_no_same_sector_overwrites. В
 этом случае установите данный параметр, например, в 1024.
 
-Неприменимо к новому хранилищу ([meta_format](layout-osd.en.md#meta_format) 3).
-
 ## journal_no_same_sector_overwrites
 
 - Тип: булево (да/нет)
@@ -401,18 +394,6 @@ fsync небезопасным даже с режимом "directsync".
 
 Почти все другие SSD (99% моделей) не требуют данной опции.
 
-Неприменимо к новому хранилищу ([meta_format](layout-osd.en.md#meta_format) 3).
-
-## skip_corrupted_meta_entries
-
-- Тип: булево (да/нет)
-- Значение по умолчанию: false
-
-Только для нового хранилища ([meta_format](layout-osd.en.md#meta_format) 3).
-Разрешить OSD запускаться, даже если часть блоков или записей метаданных
-повреждена, пропуская их. Опция предназначена для использования только в
-целях аварийного восстановления.
-
 ## throttle_small_writes
 
 - Тип: булево (да/нет)
@@ -540,7 +521,7 @@ fsync небезопасным даже с режимом "directsync".
 ## scrub_list_limit
 
 - Тип: целое число
-- Значение по умолчанию: 262144
+- Значение по умолчанию: 1000
 - Можно менять на лету: да
 
 Размер загружаемых за одну операцию списков объектов в процессе фоновой
@@ -679,124 +660,3 @@ EC (кодов коррекции ошибок) с более, чем 1 диск
 Максимальное возможное значение авто-подстроенного recovery_sleep_us.
 Большие значения считаются случайными выбросами и игнорируются в
 усреднении.
-
-## discard_on_start
-
-- Тип: булево (да/нет)
-
-Освобождать (SSD TRIM) неиспользуемые блоки диска данных при каждом запуске OSD.
-
-## min_discard_size
-
-- Тип: целое число
-- Значение по умолчанию: 1048576
-
-Минимальный размер последовательного блока данных, чтобы освобождать его через TRIM.
-
-## allow_net_split
-
-- Тип: булево (да/нет)
-- Значение по умолчанию: false
-
-Разрешить "безопасные" случаи разделений сети - разрешить активировать PG без
-соединений к некоторым OSD, помеченным активными в etcd, если общее число активных
-OSD в PG составляет как минимум pg_minsize. То есть, разрешать некоторым OSD терять
-соединения с некоторыми другими OSD, если это не нарушает гарантий pg_minsize.
-Минус такого разрешения в том, что оно повышает вероятность записи данных ровно в
-pg_minsize OSD во время переключений, что может потом привести к тому, что PG станут
-неполными (incomplete), если упадут ещё какие-то OSD.
-
-Старое поведение в версиях до 2.0.0 было идентично включённому allow_net_split.
-
-## enable_pg_locks
-
-- Тип: булево (да/нет)
-
-В Vitastor 2.2.0 появился новый слой защиты от сплитбрейна в дополнение к etcd -
-блокировки PG. Они гарантируют порядок даже в теоретических ненормальных случаях,
-когда etcd очень сильно тормозит. Так как функция новая, по умолчанию она включается
-только для пулов, в которых она необходима - а именно, в пулах с включёнными
-[локальными чтениями](pool.ru.md#local_reads). Ну а с помощью данного параметра
-можно включить блокировки PG для всех пулов.
-
-## pg_lock_retry_interval_ms
-
-- Тип: миллисекунды
-- Значение по умолчанию: 100
-
-Интервал повтора неудачных попыток блокировки PG.
-
-## atomic_write_size
-
-- Тип: целое число
-- Значение по умолчанию: 4096
-
-Максимальный размер атомарной записи на диск данных, который OSD разрешено использовать.
-
-Поддержка атомарной записи позволяет снизить мультипликатор записи (Write Amplification)
-на диск с новым хранилищем ([meta_format](layout-osd.ru.md#meta_format)=3)
-практически до 1 (то есть, почти до нулевого объёма лишней записи) в реплицированных
-пулах и достигнуть наилучшей возможной производительности записи.
-
-Значение по умолчанию авто-определяется во время инициализации OSD из
-`/sys/block/xx/queue/atomic_write_max_bytes` либо принимается равным 4096,
-так как все известные диски поддерживают атомарную запись 4 КБ блоков.
-Автоопределение применяется только для NVMe-дисков, так как SAS диски требуют
-использования отдельной команды WRITE ATOMIC, а для неё нужен флаг RWF_ATOMIC
-(см. ниже [#use_atomic_flag]), а он в текущих версиях Linux работает некорректно.
-
-Вы также можете проверить, поддерживают ли ваши NVMe-диски атомарную запись,
-с помощью команды `nvme id-ctrl /dev/nvme0n1 | grep awupf`. Если значение awupf
-плюс 1, умноженное на текущий выбранный размер блока NVMe-диска, больше 4 КБ,
-то новое хранилище может использовать атомарные записи для достижения лучшей
-производительности. Единственные известные диски, которые поддерживают это сейчас -
-[Micron и Kioxia](../intro/quickstart.ru.md).
-
-Атомарная запись позволяет не использовать двойную запись данных (в журнал и на
-устройство данных) в реплицированных пулах и таким образом снижает амплификацию
-записи (объём служебной записи на диск) и улучшает производительность записи
-вплоть до 2-х кратного прироста.
-
-## use_atomic_flag
-
-- Тип: булево (да/нет)
-
-Данная опция контролирует использование Vitastor OSD флага RWF_ATOMIC при атомарной записи
-блоков. Этот флаг поддерживается, начиная с версии ядра Linux 6.11 и добавляет немного корректности
-атомарным записям - ядро гарантирует отсутствие фрагментации запросов записи с этим флагом и
-проверяет их на соответствие реальным возможностям устройства.
-
-Однако, данная опция по умолчанию отключена, так как флаг в текущих версиях Linux работает
-абсолютно НЕКОРРЕКТНО - при нём Linux требует, чтобы запросы записи имели длину, равную
-степени двойки и были выровнены на эту длину. То есть, например, 12 КБ запросы записи, а также
-8 КБ запросы записи по не-кратному 8 КБ смещению запрещаются ядром, хотя спецификация NVMe их
-разрешает.
-
-Для NVMe-дисков с `scheduler=none` запросы записи и так не фрагментируются, так что это не так
-уж и важно, однако вы можете пересобрать своё ядро с [этим патчем](../../patches/linux-fix-atomic-write-checks.diff)
-и включить данную опцию. Это сделает вашу атомарную запись капельку безопаснее.
-
-## pg_reshard_chunk_size
-
-- Тип: целое число
-- Значение по умолчанию: 100000
-
-Изменение числа PG в пуле заметно загружает процессор, так как OSD хранят полную базу данных
-объектов в памяти и им приходится перемещать все записи объектов между старыми и новыми PG.
-Поэтому изменение применяется порциями, с паузами между порциями, чтобы не блокировать обработку
-событий OSD и операции остальных клиентов. Данная опция задаёт максимальное число объектов
-в порции. Перемещение 100 тысяч объектов (значение по умолчанию) обычно занимает порядка
-50-100 миллисекунд. Значение опции 0 отключает лимит размера порции.
-
-## pg_reshard_chunk_pause_ms
-
-- Тип: миллисекунды
-- Значение по умолчанию: 100
-
-Данная опция задаёт интервал между обработкой двух порций изменения числа PG пулов.
-
-## gc_on_start
-
-- Тип: булево (да/нет)
-
-Принудительно очищать все мусорные записи в новом хранилище при каждом запуске OSD.

docs/config/pool.en.md

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

docs/config/pool.ru.md

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

docs/config/security.en.md

@@ -1,313 +0,0 @@
-[Documentation](../../README.md#documentation) → [Configuration](../config.en.md) → Security Parameters
-
------
-
-[Читать на русском](security.ru.md)
-
-# Security Parameters
-
-These parameters affect your Vitastor installation security and apply to OSDs, monitors and clients.
-
-Most of them can be set in /etc/vitastor/vitastor.conf and in etcd, but don't support online modification.
-
-All certificate and private key parameters mentioned may contain a path to a PEM file or just
-a PEM string with certificate or a private key. In the latter case, the string must begin with
-"-----BEGIN CERTIFICATE-----" or "-----BEGIN PRIVATE KEY-----".
-
-- [use_perms](#use_perms)
-- [cert](#cert)
-- [pkey](#pkey)
-- [etcd_ca](#etcd_ca)
-- [client_ca](#client_ca)
-- [admin_ca](#admin_ca)
-- [osd_ca](#osd_ca)
-- [mon_ca](#mon_ca)
-- [antietcd_cert](#antietcd_cert)
-- [antietcd_key](#antietcd_key)
-- [etcd_proxy.urls](#etcd_proxyurls)
-- [etcd_proxy.cert](#etcd_proxycert)
-- [etcd_proxy.key](#etcd_proxykey)
-- [etcd_proxy.ca](#etcd_proxyca)
-- [osd_cert](#osd_cert)
-- [osd_pkey](#osd_pkey)
-- [api_cert](#api_cert)
-- [api_pkey](#api_pkey)
-- [etcd_client_cert](#etcd_client_cert)
-- [etcd_client_key](#etcd_client_key)
-- [osd_etcd_client_cert](#osd_etcd_client_cert)
-- [osd_etcd_client_key](#osd_etcd_client_key)
-- [mon_etcd_client_cert](#mon_etcd_client_cert)
-- [mon_etcd_client_key](#mon_etcd_client_key)
-- [proto_checksums](#proto_checksums)
-- [force_proto_checksums](#force_proto_checksums)
-- [max_cipher_pool_size](#max_cipher_pool_size)
-- [vault_url](#vault_url)
-- [vault_secret_api_path](#vault_secret_api_path)
-- [vault_client_cert](#vault_client_cert)
-- [vault_client_key](#vault_client_key)
-- [vault_ca](#vault_ca)
-- [vault_timeout_ms](#vault_timeout_ms)
-- [vault_error_timeout_sec](#vault_error_timeout_sec)
-- [vault_refresh_leeway_sec](#vault_refresh_leeway_sec)
-
-## use_perms
-
-- Type: boolean
-- Default: false
-
-Enable client permissions in a Vitastor cluster, including Antietcd built into the Monitor.
-Requires configured encryption. Also note that separate Antietcd requires separate configuration
-to use permissions (see [security documentation](../usage/security.en.md) for details).
-
-## cert
-
-- Type: string
-
-Client certificate of the current Vitastor user. Required for Vitastor protocol encryption.
-Must be signed with [client_ca](#client_ca). Also used as the client certificate for etcd/Antietcd
-connections by default.
-
-## pkey
-
-- Type: string
-
-Private key of the current Vitastor user.
-
-## etcd_ca
-
-- Type: string
-
-Trusted TLS CA to verify etcd server certificate. Or just the etcd server's
-certificate itself - it's fine to use it for etcd_ca.
-
-## client_ca
-
-- Type: string
-
-Trusted TLS CA to verify Vitastor client certificates.
-Mandatory for Vitastor protocol encryption.
-
-## admin_ca
-
-- Type: string
-
-Trusted TLS CA to verify Vitastor administrator certificates.
-
-## osd_ca
-
-- Type: string
-
-Trusted TLS CA to verify Vitastor OSD certificates. Also mandatory for Vitastor protocol
-encryption. Must be different from client_ca. May be equal to osd_cert - different OSDs
-don't require separate certificates at the moment because their permissions don't differ.
-
-## mon_ca
-
-- Type: string
-
-Trusted TLS CA to verify Vitastor Monitor certificates. Used only for separate Antietcd,
-not required when a monitor built-in Antietcd is used. May be equal to mon_client_etcd_cert.
-
-## antietcd_cert
-
-- Type: string
-
-Server TLS certificate for Antietcd built into the Monitor.
-
-## antietcd_key
-
-- Type: string
-
-Private key for antietcd_cert.
-
-## etcd_proxy.urls
-
-- Type: string or array of strings
-
-etcd URLs for Antietcd etcd proxy mode.
-See [Mon as Etcd proxy](../usage/security.en.md#mon-as-etcd-proxy) for details.
-
-## etcd_proxy.cert
-
-- Type: string
-
-Client certificate for Antietcd connections to etcd in proxy mode.
-
-## etcd_proxy.key
-
-- Type: string
-
-Private key for etcd_proxy.cert.
-
-## etcd_proxy.ca
-
-- Type: string
-
-Trusted TLS CA to verify etcd server certificate when connecting to it from Antietcd.
-
-## osd_cert
-
-- Type: string
-
-Vitastor OSD server certificate. Required for Vitastor protocol encryption. May be equal
-to [osd_ca](#osd_ca) - all OSDs share the same permission set for now. Also used as the client
-certificate for connections from OSD to etcd/Antietcd by default.
-
-## osd_pkey
-
-- Type: string
-
-Private key for osd_cert.
-
-## api_cert
-
-- Type: string
-
-Server TLS certificate for [vitastor-cli serve](../usage/cli.en.md#serve) API server.
-
-## api_pkey
-
-- Type: string
-
-Private key for api_cert.
-
-## etcd_client_cert
-
-- Type: string
-
-Client TLS certificate to use for connections from Vitastor clients to etcd/Antietcd if you don't want
-to use the common client certificate [cert](#cert).
-
-## etcd_client_key
-
-- Type: string
-
-Private key for etcd_client_cert.
-
-## osd_etcd_client_cert
-
-- Type: string
-
-Client TLS certificate to use for connections from Vitastor OSDs to etcd/Antietcd if you don't want
-to use the common OSD certificate [osd_cert](#osd_cert).
-
-## osd_etcd_client_key
-
-- Type: string
-
-Private key for osd_etcd_client_cert.
-
-## mon_etcd_client_cert
-
-- Type: string
-
-Client TLS certificate to use for connections from Vitastor Monitors to etcd/Antietcd - required
-if you don't use the built-in Antietcd. In case you use it Monitor has direct access to Antietcd data
-and doesn't require any connection.
-
-## mon_etcd_client_key
-
-- Type: string
-
-Private key for mon_etcd_client_cert.
-
-## proto_checksums
-
-- Type: string
-- Default: payload
-
-One of "full", "payload", "gcm", "none":
-- "full" means calculate and verify transport level checksums from the full message data
-  including the header - recommended for unencrypted setups.
-- "payload" enables checksums only for the actual read/write data, but skips them for message
-  headers - recommended for encrypted setups because headers are already protected by AES-GCM.
-- "gcm" disables checksums and enables AES-GCM encryption of the whole messages including headers
-  and data - AES-GCM already includes MAC which is actually a stronger checksum. This option is
-  slower and is only recommended for untrusted networks.
-- "none" disables transport level checksums at all.
-
-## force_proto_checksums
-
-- Type: string
-
-To allow older clients to connect to a Vitastor cluster with enabled checksums, Vitastor OSDs
-allow clients to downgrade their proto_checksums by default. force_proto_checksums sets the
-minimum security level allowed for connecting clients. When encryption is disabled, default
-force_proto_checksums is none and clients without checksums are allowed. With enabled
-encryption, force_proto_checksums becomes "payload" by default to block unauthenticated data
-on the transport level.
-
-## max_cipher_pool_size
-
-- Type: integer
-- Default: 256
-
-Maximum number of OpenSSL cipher contexts cached in OSD memory, counted separately
-for each cipher and for encryption/decryption. Probably doesn't require modification.
-
-## vault_url
-
-- Type: string
-
-Vault base URL.
-
-Vitastor clients support AES-256-XTS image data encryption with different per-image keys.
-Encryption is performed by the client, OSDs don't have access to decrypted data.
-
-Encryption keys may be stored in etcd or, for the increased security level, in an external
-[HashiCorp Vault](https://developer.hashicorp.com/vault/) or [OpenBao](https://openbao.org/)
-instance.
-
-Vitastor clients use [v1 k/v secrets engine](https://openbao.org/api-docs/secret/kv/kv-v1/)
-and [TLS authentication engine](https://openbao.org/api-docs/auth/cert/) in Vault.
-
-In that case, only key IDs are stored in etcd.
-
-## vault_secret_api_path
-
-- Type: string
-- Default: /v1/secret/
-
-Vault v1 secret API mount path to use.
-
-## vault_client_cert
-
-- Type: string
-
-Client TLS certificate to use for Vault connections if you don't want to use the common Vitastor
-client certificate [cert](#cert) which is also used for Vault connections by default.
-
-## vault_client_key
-
-- Type: string
-
-Private key for the vault_client_cert certificate.
-
-## vault_ca
-
-- Type: string
-
-Trusted TLS CA to verify Vault server certificate. May be path to a file,
-directory or just a PEM string with certificate.
-
-## vault_timeout_ms
-
-- Type: integer
-- Default: 5000
-
-Timeout for Vault requests in milliseconds.
-
-## vault_error_timeout_sec
-
-- Type: integer
-- Default: 60
-
-Time (in seconds) to wait before retrying after receiving an error from Vault.
-
-## vault_refresh_leeway_sec
-
-- Type: integer
-- Default: 60
-
-Extra time (in seconds) before real Vault token lease_timeout to refresh it, just
-in case of system clock drift.

docs/config/security.ru.md

@@ -1,319 +0,0 @@
-[Документация](../../README-ru.md#документация) → [Конфигурация](../config.ru.md) → Параметры безопасности
-
------
-
-[Read in English](security.en.md)
-
-# Параметры безопасности
-
-Данные параметры затрагивают безопасность инсталляций Vitastor и используются
-OSD, мониторами и клиентами.
-
-Большая их часть может задаваться в /etc/vitastor/vitastor.conf и в etcd, но не
-поддерживает онлайн-изменение.
-
-Все параметры сертификатов и закрытых ключей могут быть путём к файлу или просто
-строкой с сертификатом в формате PEM. В последнем случае строка должна начинаться с
-"-----BEGIN CERTIFICATE-----" или "-----BEGIN PRIVATE KEY-----".
-
-- [use_perms](#use_perms)
-- [cert](#cert)
-- [pkey](#pkey)
-- [etcd_ca](#etcd_ca)
-- [client_ca](#client_ca)
-- [admin_ca](#admin_ca)
-- [osd_ca](#osd_ca)
-- [mon_ca](#mon_ca)
-- [antietcd_cert](#antietcd_cert)
-- [antietcd_key](#antietcd_key)
-- [etcd_proxy.urls](#etcd_proxyurls)
-- [etcd_proxy.cert](#etcd_proxycert)
-- [etcd_proxy.key](#etcd_proxykey)
-- [etcd_proxy.ca](#etcd_proxyca)
-- [osd_cert](#osd_cert)
-- [osd_pkey](#osd_pkey)
-- [api_cert](#api_cert)
-- [api_pkey](#api_pkey)
-- [etcd_client_cert](#etcd_client_cert)
-- [etcd_client_key](#etcd_client_key)
-- [osd_etcd_client_cert](#osd_etcd_client_cert)
-- [osd_etcd_client_key](#osd_etcd_client_key)
-- [mon_etcd_client_cert](#mon_etcd_client_cert)
-- [mon_etcd_client_key](#mon_etcd_client_key)
-- [proto_checksums](#proto_checksums)
-- [force_proto_checksums](#force_proto_checksums)
-- [max_cipher_pool_size](#max_cipher_pool_size)
-- [vault_url](#vault_url)
-- [vault_secret_api_path](#vault_secret_api_path)
-- [vault_client_cert](#vault_client_cert)
-- [vault_client_key](#vault_client_key)
-- [vault_ca](#vault_ca)
-- [vault_timeout_ms](#vault_timeout_ms)
-- [vault_error_timeout_sec](#vault_error_timeout_sec)
-- [vault_refresh_leeway_sec](#vault_refresh_leeway_sec)
-
-## use_perms
-
-- Тип: булево (да/нет)
-- Значение по умолчанию: false
-
-Включает клиентские привилегии в кластере Vitastor, в том числе во встроенном в мониторе Antietcd.
-Требует настроенного шифрования протокола. Также обратите внимание, что отдельно установленный Antietcd
-требует отдельной настройки привилегий (подробности смотрите в [документации безопасности](../usage/security.ru.md)).
-
-## cert
-
-- Тип: строка
-
-Клиентский сертификат текущего пользователя Vitastor. Требуется для шифрования протокола Vitastor.
-Должен быть подписан [client_ca](#client_ca). Также по умолчанию используется как клиентский
-сертификат для подключения к etcd/Antietcd и Vault.
-
-## pkey
-
-- Тип: строка
-
-Закрытый ключ текущего пользователя Vitastor.
-
-## etcd_ca
-
-- Тип: строка
-
-Доверенный корневой TLS-сертификат для проверки сертификата сервера etcd.
-Либо же просто сам сертификат сервера etcd - его можно использовать как etcd_ca.
-
-## client_ca
-
-- Тип: строка
-
-Доверенный TLS-сертификат для проверки сертификатов клиентов Vitastor.
-Требуется для шифрования протокола Vitastor.
-
-## admin_ca
-
-- Тип: строка
-
-Доверенный TLS-сертификат для проверки сертификатов администраторов Vitastor.
-
-## osd_ca
-
-- Тип: строка
-
-Доверенный TLS-сертификат для проверки сертификатов OSD Vitastor. Также обязателен
-для шифрования протокола Vitastor. Должен отличаться от client_ca. Может быть равен
-osd_cert - разные OSD не требуют разных сертификатов, потому что на данный момент
-привилегии разных OSD никак не отличаются.
-
-## mon_ca
-
-- Тип: строка
-
-Доверенный TLS-сертификат для проверки сертификатов мониторов Vitastor. Используется
-только отдельно установленным Antietcd, не требуется при использовании встроенного в монитор
-Antietcd. Может быть равен mon_client_etcd_cert.
-
-## antietcd_cert
-
-- Тип: строка
-
-Серверный TLS-сертификат для Antietcd, встроенного в монитор.
-
-## antietcd_key
-
-- Тип: строка
-
-Закрытый ключ для сертификата antietcd_cert.
-
-## etcd_proxy.urls
-
-- Тип: строка или массив строк
-
-Адреса etcd для режима Antietcd etcd-прокси.
-Смотрите подробности в разделе [Mon в роли Etcd proxy](../usage/security.ru.md#mon-в-роли-etcd-proxy).
-
-## etcd_proxy.cert
-
-- Тип: строка
-
-Клиентский сертификат для подключений от Antietcd к etcd в режиме прокси.
-
-## etcd_proxy.key
-
-- Тип: строка
-
-Закрытый ключ для сертификата etcd_proxy.cert.
-
-## etcd_proxy.ca
-
-- Тип: строка
-
-Доверенный TLS-сертификат для проверки сертификата сервера etcd при подключениях от Antietcd.
-
-## osd_cert
-
-- Тип: строка
-
-Сертификат сервера Vitastor OSD. Требуется для шифрования протокола Vitastor. Может быть равен
-[osd_ca](#osd_ca) - все OSD на данный момент имеют одинаковые привилегии. Также по умолчанию
-используется как клиентский сертификат для подключения от OSD к etcd/Antietcd.
-
-## osd_pkey
-
-- Тип: строка
-
-Закрытый ключ для сертификата osd_cert.
-
-## api_cert
-
-- Тип: строка
-
-Серверный TLS-сертификат для API-сервера [vitastor-cli serve](../usage/cli.ru.md#serve).
-
-## api_pkey
-
-- Тип: строка
-
-Закрытый ключ для сертификата api_cert.
-
-## etcd_client_cert
-
-- Тип: строка
-
-Клиентский TLS сертификат для подключений от клиентов Vitastor к etcd/Antietcd, если вы не хотите
-использовать общий клиентский сертификат [cert](#cert).
-
-## etcd_client_key
-
-- Тип: строка
-
-Закрытый ключ для сертификата etcd_client_cert.
-
-## osd_etcd_client_cert
-
-- Тип: строка
-
-Клиентский TLS сертификат для подключений от Vitastor OSD к etcd/Antietcd, если вы не хотите
-использовать общий сертификат OSD [osd_cert](#osd_cert).
-
-## osd_etcd_client_key
-
-- Тип: строка
-
-Закрытый ключ для сертификата osd_etcd_client_cert.
-
-## mon_etcd_client_cert
-
-- Тип: строка
-
-Клиентский TLS сертификат для подключений от мониторов Vitastor к etcd/Antietcd - требуется, если
-вы не используете встроенный в монитор Antietcd. Если вы используете его, то монитор и так имеет
-прямой доступ к данным Antietcd и не требует никаких соединений.
-
-## mon_etcd_client_key
-
-- Тип: строка
-
-Закрытый ключ для сертификата mon_etcd_client_cert.
-
-## proto_checksums
-
-- Тип: строка
-- Значение по умолчанию: payload
-
-Одно из значений "full", "payload", "gcm" и "none":
-- "full" означает расчёт и проверку контрольных сумм на транспортном уровне от полных сообщений,
-  включая их заголовки и данные - рекомендуется для кластеров без шифрования.
-- "payload" включает контрольные суммы только для данных сообщений, но пропускает заголовки -
-  такая настройка рекомендуется для кластеров с включённым шифрованием, потому что в них заголовки
-  и так защищены шифрованием AES-GCM.
-- "gcm" отключает контрольные суммы и включает шифрование полных сообщений включая заголовки и
-  данные - AES-GCM уже включает в себя MAC, который по сути является криптостойкой контрольной
-  суммой. Такая настройка медленнее и рекомендуется только для недоверенных сетей.
-- "none" полностью отключает контрольные суммы на транспортном уровне.
-
-## force_proto_checksums
-
-- Тип: строка
-
-Чтобы старые клиенты Vitastor могли подключаться к кластеру с включёнными контрольными
-суммами, Vitastor OSD по умолчанию разрешают клиентам отключать контрольные суммы
-данных (proto_checksums). Настройка force_proto_checksums задаёт минимальный уровень
-безопасности, разрешённый для подключающихся клиентов. Когда шифрование отключено,
-force_proto_checksums по умолчанию равно none и подключения клиентов без контрольных
-сумм разрешаются. При включённом шифровании значение по умолчанию force_proto_checksums
-становится "payload", чтобы блокировать подключения с неаутентифицированными данными.
-
-## max_cipher_pool_size
-
-- Тип: целое число
-- Значение по умолчанию: 256
-
-Максимальное количество кэшируемых в памяти OSD контекстов шифра OpenSSL, учитываемое
-отдельно для каждого шифра и для шифрования и расшифровки. Вряд ли требует изменения.
-
-## vault_url
-
-- Тип: строка
-
-Базовый адрес Vault.
-
-Клиенты Vitastor поддерживают AES-256-XTS шифрование данных образов с отдельными ключами на
-каждый образ. Данные шифруются клиентами, OSD не имеют доступа к незашифрованным данным.
-
-Ключи шифрования могут храниться в etcd или, для повышенного уровня безопасности, во внешнем
-[HashiCorp Vault](https://developer.hashicorp.com/vault/) или [OpenBao](https://openbao.org/).
-
-Клиенты Vitastor используют [движок секретов v1](https://openbao.org/api-docs/secret/kv/kv-v1/)
-и [TLS-аутентификацию](https://openbao.org/api-docs/auth/cert/) в Vault.
-
-В этом случае, только ID ключей хранятся в etcd.
-
-## vault_secret_api_path
-
-- Тип: строка
-- Значение по умолчанию: /v1/secret/
-
-Путь к API секретов v1 для использования клиентами.
-
-## vault_client_cert
-
-- Тип: строка
-
-Клиентский TLS сертификат для подключений к Vault на тот случай, если вы не хотите использовать
-общий сертификат клиента Vitastor [cert](#cert), используемый для подключений к Vault по умолчанию.
-
-## vault_client_key
-
-- Тип: строка
-
-Закрытый ключ для сертификата vault_client_cert.
-
-## vault_ca
-
-- Тип: строка
-
-Доверенный корневой TLS-сертификат для проверки сертификата сервера Vault.
-Может быть путём к файлу, директории или просто строкой с сертификатом в
-формате PEM.
-
-## vault_timeout_ms
-
-- Тип: целое число
-- Значение по умолчанию: 5000
-
-Максимально время выполнения Vault-запросов в миллисекундах.
-
-## vault_error_timeout_sec
-
-- Тип: целое число
-- Значение по умолчанию: 60
-
-Время (в секундах) для ожидания перед повторной попыткой при получении ошибки от Vault.
-
-## vault_refresh_leeway_sec
-
-- Тип: целое число
-- Значение по умолчанию: 60
-
-Зазор времени (в секундах), чтобы обновлять токены Vault чуть раньше их реального
-lease_timeout, на случай "ухода" системных часов.

docs/config/src/client.yml

@@ -271,48 +271,3 @@
     заполненные на 100% OSD вообще не могут стартовать), так что вы сможете
     восстановить работу кластера после ошибок отсутствия свободного места
     без уничтожения и пересоздания OSD.
-- name: hostname
-  type: string
-  online: true
-  info: |
-    Clients use host name to find their distance to OSDs when [localized reads](pool.en.md#local_reads)
-    are enabled. By default, standard [gethostname](https://man7.org/linux/man-pages/man2/gethostname.2.html)
-    function is used to determine host name, but you can also override it with this parameter.
-  info_ru: |
-    Клиенты используют имя хоста для определения расстояния до OSD, когда включены
-    [локальные чтения](pool.ru.md#local_reads). По умолчанию для определения имени
-    хоста используется стандартная функция [gethostname](https://man7.org/linux/man-pages/man2/gethostname.2.html),
-    но вы также можете задать имя хоста вручную данным параметром.
-- name: ublk_queue_depth
-  type: int
-  default: 256
-  online: false
-  info: Default queue depth for [Vitastor ublk servers](../usage/ublk.en.md).
-  info_ru: Глубина очереди по умолчанию для [ublk-серверов Vitastor](../usage/ublk.ru.md).
-- name: ublk_max_io_size
-  type: int
-  online: false
-  info: |
-    Default maximum I/O size for Vitastor [ublk servers](../usage/ublk.en.md).
-    The largest of 1 MB and pool block size multiplied by EC data chunk count is used if not specified.
-  info_ru: |
-    Максимальный размер запроса ввода-вывода для [ublk-серверов Vitastor](../usage/ublk.ru.md).
-    Если не задан, используется максимум из 1 МБ и размера блока пула, умноженного на число частей
-    данных EC-пула.
-- name: qemu_file_mirror_path
-  type: string
-  info: |
-    When set to an FS directory path (for example, `/mnt/vitastor/`), `qemu-img info` and similar
-    QAPI commands return the name of the image inside this directory instead of normal
-    `vitastor://?image=abc` URI as `filename`.
-
-    This allows to then mount this path using [vitastor-nfs](../usage/nfs.en.md) and trick
-    third-party systems like Veeam which rely on `filename` in the image info but don't support Vitastor.
-  info_ru: |
-    Если установить эту опцию равной пути к каталогу в ФС, команда `qemu-img info` и подобные
-    команды QAPI будут возвращать в поле `filename` имя образа внутри заданного каталога вместо
-    обычного адреса типа `vitastor://?image=abc`.
-
-    Это позволяет смонтировать этот путь с помощью [vitastor-nfs](../usage/nfs.ru.md) и обмануть
-    сторонние системы типа Veeam, которые полагаются на поле `filename` в информации об образе QEMU,
-    но не поддерживают Vitastor.

docs/config/src/included.en.md

@@ -24,8 +24,6 @@
 
 {{../../installation/kubernetes.en.md}}
 
-{{../../installation/s3.en.md}}
-
 {{../../installation/source.en.md}}
 
 {{../../config.en.md|indent=1}}
@@ -44,8 +42,6 @@
 
 {{../../config/monitor.en.md|indent=2}}
 
-{{../../config/security.en.md|indent=2}}
-
 {{../../config/pool.en.md|indent=2}}
 
 {{../../config/inode.en.md|indent=2}}
@@ -58,16 +54,12 @@
 
 {{../../usage/fio.en.md}}
 
-{{../../usage/ublk.en.md}}
-
 {{../../usage/nbd.en.md}}
 
 {{../../usage/qemu.en.md}}
 
 {{../../usage/nfs.en.md}}
 
-{{../../usage/security.en.md}}
-
 {{../../usage/admin.en.md}}
 
 ## Performance

docs/config/src/included.ru.md

@@ -26,8 +26,6 @@
 
 {{../../installation/source.ru.md}}
 
-{{../../installation/s3.ru.md}}
-
 {{../../config.ru.md|indent=1}}
 
 {{../../config/common.ru.md|indent=2}}
@@ -44,8 +42,6 @@
 
 {{../../config/monitor.ru.md|indent=2}}
 
-{{../../config/security.ru.md|indent=2}}
-
 {{../../config/pool.ru.md|indent=2}}
 
 {{../../config/inode.ru.md|indent=2}}
@@ -58,16 +54,12 @@
 
 {{../../usage/fio.ru.md}}
 
-{{../../usage/ublk.ru.md}}
-
 {{../../usage/nbd.ru.md}}
 
 {{../../usage/qemu.ru.md}}
 
 {{../../usage/nfs.ru.md}}
 
-{{../../usage/security.ru.md}}
-
 {{../../usage/admin.ru.md}}
 
 ## Производительность

docs/config/src/layout-osd.yml

@@ -1,28 +1,3 @@
-- name: meta_format
-  type: int
-  default: 3
-  info: |
-    OSD store implementation version and on-disk metadata format.
-
-    Three versions are currently supported: 3, 2 and 1.
-    - 3 the new log-structured store, it's overall faster, has lower Write
-      Amplification, which may be even close to 1 (i.e. almost no extra writes)
-      if your SSDs support atomic writes (see [atomic_write_size](osd.en.md#atomic_write_size)).
-    - 2 is the old stable store from Vitastor 0.9-2.x.
-    - 1 is the same old store but with a legacy metadata format from Vitastor
-      versions to up 0.8.x, without any support for checksums.
-  info_ru: |
-    Версия реализации дискового хранилища OSD и дискового формата метаданных.
-
-    Поддерживаются три версии: 3, 2 и 1.
-    - 3 - новое лог-структурированное хранилище, в целом более быстрое, со
-      сниженным фактором амплификации записи, который может составлять около 1
-      (то есть, практически без лишней служебной записи), если ваши SSD
-      поддерживают атомарную запись (см. [atomic_write_size](osd.ru.md#atomic_write_size)).
-    - 2 - старое стабильное хранилище из версий Vitastor 0.9-2.x.
-    - 1 - то же самое стабильное хранилище, но с ещё более старым форматом
-      метаданных из версий Vitastor до 0.8.x, без какой-либо поддержки
-      контрольных сумм.
 - name: data_device
   type: string
   info: |
@@ -233,21 +208,11 @@
   type: string
   default: none
   info: |
-    Data and metadata checksum type to use. May be "crc32c", "xxh3_32" or "none".
-    Select crc32c or xxh3_32 and set csum_block_size to enable data checksums.
-
-    Both crc32c and xxh3_32 are almost equally fast, xxh3_32 is safer. xxh3_32 is
-    the xxhash3 algorithm truncated from 64 to 32 bits (which is still a good hash).
-
-    Note that enabled data checksums either increase memory usage or reduce
-    performance. Check details in [csum_block_size](#csum_block_size) description.
+    Data checksum type to use. May be "crc32c" or "none". Set to "crc32c" to
+    enable data checksums.
   info_ru: |
-    Тип используемых OSD контрольных сумм данных и метаданных. Может быть "crc32c",
-    "xxh3_32" или "none". Выберите crc32c или xxh3_32 и установите csum_block_size,
-    чтобы включить контрольные суммы данных.
-
-    И crc32c, и xxh3_32 примерно одинаково быстры, xxh3_32 надёжней. xxh3_32 - это
-    алгоритм xxhash3, обрезанный с 64 до 32 бит (это всё равно хороший хеш).
+    Тип используемых OSD контрольных сумм данных. Может быть "crc32c" или "none".
+    Установите в "crc32c", чтобы включить расчёт и проверку контрольных сумм данных.
 
     Следует понимать, что контрольные суммы в зависимости от размера блока их
     расчёта либо увеличивают потребление памяти, либо снижают производительность.

docs/config/src/make.js

@@ -13,7 +13,6 @@ const L = {
         toc_installation: 'Installation',
         toc_config: '[Configuration](../config.en.md)',
         toc_usage: 'Usage',
-        toc_tests: 'Tests',
         toc_performance: 'Performance',
         online: 'Can be changed online: yes',
     },
@@ -29,7 +28,6 @@ const L = {
         toc_installation: 'Установка',
         toc_config: '[Конфигурация](../config.ru.md)',
         toc_usage: 'Использование',
-        toc_tests: 'Тесты',
         toc_performance: 'Производительность',
         online: 'Можно менять на лету: да',
     },
@@ -66,7 +64,7 @@ for (const file of params_files)
         let out = '\n';
         for (const c of cfg)
         {
-            out += `\n- [${c.name}](#${c.name.replace(/\./g, '')})`;
+            out += `\n- [${c.name}](#${c.name})`;
         }
         for (const c of cfg)
         {

docs/config/src/monitor.yml

@@ -21,9 +21,6 @@
     cluster, cluster_key, persist_filter, stale_read can also be set in
     Vitastor configuration with `antietcd_` prefix.
 
-    See also: [antietcd_cert](security.en.md#antietcd_cert),
-    [antietcd_key](security.en.md#antietcd_key) and [etcd_proxy](security.en.md#etcd_proxyurls).
-
     You can dump/load data to or from antietcd using Antietcd `anticli` tool:
 
     ```
@@ -50,9 +47,6 @@
     node_id, cluster, cluster_key, persist_filter, stale_read также можно задавать
     в конфигурации Vitastor с префиксом `antietcd_`.
 
-    Смотрите также настройки [antietcd_cert](security.ru.md#antietcd_cert),
-    [antietcd_key](security.ru.md#antietcd_key) и [etcd_proxy](security.ru.md#etcd_proxyurls).
-
     Вы можете выгружать/загружать данные в или из antietcd с помощью его инструмента
     `anticli`:
 
@@ -81,11 +75,11 @@
 - name: mon_http_port
   type: int
   default: 8060
-  info: HTTP port for monitors to listen to (including metrics exporter)
+  info: HTTP port for monitors to listen on (including metrics exporter)
   info_ru: Порт, на котором мониторы принимают HTTP-соединения (в том числе для отдачи метрик)
 - name: mon_http_ip
   type: string
-  info: IP address for monitors to listen to (all addresses by default)
+  info: IP address for monitors to listen on (all addresses by default)
   info_ru: IP-адрес, на котором мониторы принимают HTTP-соединения (по умолчанию все адреса)
 - name: mon_https_cert
   type: string

docs/config/src/network.yml

@@ -1,78 +1,49 @@
-- name: osd_network
-  type: string or array of strings
-  type_ru: строка или массив строк
+- name: tcp_header_buffer_size
+  type: int
+  default: 65536
   info: |
-    Network mask of public OSD network(s) (IPv4 or IPv6). Each OSD listens to all
-    addresses of UP + RUNNING interfaces matching one of these networks, on the
-    same port. Port is auto-selected except if [bind_port](osd.en.md#bind_port) is
-    explicitly specified. Bind address(es) may also be overridden manually by
-    specifying [bind_address](osd.en.md#bind_address). If OSD networks are not specified
-    at all, OSD just listens to a wildcard address (0.0.0.0).
+    Size of the buffer used to read data using an additional copy. Vitastor
+    packet headers are 128 bytes, payload is always at least 4 KB, so it is
+    usually beneficial to try to read multiple packets at once even though
+    it requires to copy the data an additional time. The rest of each packet
+    is received without an additional copy. You can try to play with this
+    parameter and see how it affects random iops and linear bandwidth if you
+    want.
   info_ru: |
-    Маски подсетей (IPv4 или IPv6) публичной сети или сетей OSD. Каждый OSD слушает
-    один и тот же порт на всех адресах поднятых (UP + RUNNING) сетевых интерфейсов,
-    соответствующих одной из указанных сетей. Порт выбирается автоматически, если
-    только [bind_port](osd.ru.md#bind_port) не задан явно. Адреса для подключений можно
-    также переопределить явно, задав [bind_address](osd.ru.md#bind_address). Если сети OSD
-    не заданы вообще, OSD слушает все адреса (0.0.0.0).
-- name: osd_cluster_network
-  type: string or array of strings
-  type_ru: строка или массив строк
+    Размер буфера для чтения данных с дополнительным копированием. Пакеты
+    Vitastor содержат 128-байтные заголовки, за которыми следуют данные размером
+    от 4 КБ и для мелких операций ввода-вывода обычно выгодно за 1 вызов читать
+    сразу несколько пакетов, даже не смотря на то, что это требует лишний раз
+    скопировать данные. Часть каждого пакета за пределами значения данного
+    параметра читается без дополнительного копирования. Вы можете попробовать
+    поменять этот параметр и посмотреть, как он влияет на производительность
+    случайного и линейного доступа.
+- name: use_sync_send_recv
+  type: bool
+  default: false
   info: |
-    Network mask of separate network(s) (IPv4 or IPv6) to use for OSD
-    cluster connections. I.e. OSDs will always attempt to use these networks
-    to connect to other OSDs, while clients will attempt to use networks from
-    [osd_network](#osd_network).
+    If true, synchronous send/recv syscalls are used instead of io_uring for
+    socket communication. Useless for OSDs because they require io_uring anyway,
+    but may be required for clients with old kernel versions.
   info_ru: |
-    Маски подсетей (IPv4 или IPv6) отдельной кластерной сети или сетей OSD.
-    То есть, OSD будут всегда стараться использовать эти сети для соединений
-    с другими OSD, а клиенты будут стараться использовать сети из [osd_network](#osd_network).
+    Если установлено в истину, то вместо io_uring для передачи данных по сети
+    будут использоваться обычные синхронные системные вызовы send/recv. Для OSD
+    это бессмысленно, так как OSD в любом случае нуждается в io_uring, но, в
+    принципе, это может применяться для клиентов со старыми версиями ядра.
 - name: use_rdma
   type: bool
   default: true
   info: |
-    Try to use RDMA through libibverbs for communication if it's available.
-    Disable if you don't want Vitastor to use RDMA. TCP-only clients can also
-    talk to an RDMA-enabled cluster, so disabling RDMA may be needed if clients
-    have RDMA devices, but they are not connected to the cluster.
-
-    `use_rdma` works with RoCEv1/RoCEv2 networks, but not with iWARP and,
-    maybe, with some Infiniband configurations which require RDMA-CM.
-    Consider `use_rdmacm` for such networks.
+    Try to use RDMA for communication if it's available. Disable if you don't
+    want Vitastor to use RDMA. TCP-only clients can also talk to an RDMA-enabled
+    cluster, so disabling RDMA may be needed if clients have RDMA devices,
+    but they are not connected to the cluster.
   info_ru: |
-    Попробовать использовать RDMA через libibverbs для связи при наличии
-    доступных устройств. Отключите, если вы не хотите, чтобы Vitastor
-    использовал RDMA. TCP-клиенты также могут работать с RDMA-кластером,
-    так что отключать RDMA может быть нужно, только если у клиентов есть
-    RDMA-устройства, но они не имеют соединения с кластером Vitastor.
-
-    `use_rdma` работает с RoCEv1/RoCEv2 сетями, но не работает с iWARP и
-    может не работать с частью конфигураций Infiniband, требующих RDMA-CM.
-    Рассмотрите включение `use_rdmacm` для таких сетей.
-- name: use_rdmacm
-  type: bool
-  default: false
-  info: |
-    Use an alternative implementation of RDMA through RDMA-CM (Connection
-    Manager). Works with all RDMA networks: Infiniband, iWARP and
-    RoCEv1/RoCEv2, and even allows to disable TCP and run only with RDMA.
-    OSDs always use random port numbers for RDMA-CM listeners, different
-    from their TCP ports. `use_rdma` is automatically disabled when
-    `use_rdmacm` is enabled.
-  info_ru: |
-    Использовать альтернативную реализацию RDMA на основе RDMA-CM (Connection
-    Manager). Работает со всеми типами RDMA-сетей: Infiniband, iWARP и
-    RoCEv1/RoCEv2, и даже позволяет полностью отключить TCP и работать
-    только на RDMA. OSD используют случайные номера портов для ожидания
-    соединений через RDMA-CM, отличающиеся от их TCP-портов. Также при
-    включении `use_rdmacm` автоматически отключается опция `use_rdma`.
-- name: disable_tcp
-  type: bool
-  default: true
-  info: |
-    Fully disable TCP and only use RDMA-CM for OSD communication.
-  info_ru: |
-    Полностью отключить TCP и использовать только RDMA-CM для соединений с OSD.
+    Пытаться использовать RDMA для связи при наличии доступных устройств.
+    Отключите, если вы не хотите, чтобы Vitastor использовал RDMA.
+    TCP-клиенты также могут работать с RDMA-кластером, так что отключать
+    RDMA может быть нужно только если у клиентов есть RDMA-устройства,
+    но они не имеют соединения с кластером Vitastor.
 - name: rdma_device
   type: string
   info: |
@@ -84,6 +55,11 @@
     unsupported with old libibverbs < v32, like in Debian 10 Buster or
     CentOS 7.
 
+    Vitastor supports all adapters, even ones without ODP support, like
+    Mellanox ConnectX-3 and non-Mellanox cards. Versions up to Vitastor
+    1.2.0 required ODP which is only present in Mellanox ConnectX >= 4.
+    See also [rdma_odp](#rdma_odp).
+
     Run `ibv_devinfo -v` as root to list available RDMA devices and their
     features.
 
@@ -92,23 +68,6 @@
     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).
-
-    Vitastor supports all adapters, even ones without ODP (On-Demand Paging)
-    support, like Mellanox ConnectX-3 and non-Mellanox cards. ODP is only present
-    in Mellanox ConnectX >= 4 adapters and allows to skip memory registration
-    for RDMA and thus, in theory, avoid memory copying.
-
-    Versions up to Vitastor 1.2.0 required ODP, then it was disabled by default,
-    but it was still supported up to 3.0.3. Now ODP support is removed because it
-    actually only hurts performance: an example 3-node cluster with 8 NVMe in each
-    node and 2*25 GBit/s ConnectX-6 RDMA network pushed 3950000 read iops without
-    ODP, 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
   info_ru: |
     Название RDMA-устройства для связи с Vitastor OSD (например, "rocep5s0f0").
     Если не указано, Vitastor попробует найти RoCE-устройство, соответствующее
@@ -117,6 +76,12 @@
     не задана. Также автовыбор не поддерживается со старыми версиями библиотеки
     libibverbs < v32, например в Debian 10 Buster или CentOS 7.
 
+    Vitastor поддерживает все модели адаптеров, включая те, у которых
+    нет поддержки ODP, то есть вы можете использовать RDMA с ConnectX-3 и
+    картами производства не Mellanox. Версии Vitastor до 1.2.0 включительно
+    требовали ODP, который есть только на Mellanox ConnectX 4 и более новых.
+    См. также [rdma_odp](#rdma_odp).
+
     Запустите `ibv_devinfo -v` от имени суперпользователя, чтобы посмотреть
     список доступных RDMA-устройств, их параметры и возможности.
 
@@ -126,39 +91,18 @@
     коммутатора для RoCEv2 ищите в документации производителя. Обычно это
     подразумевает настройку сети без потерь на основе PFC (Priority Flow
     Control) и ECN (Explicit Congestion Notification).
-
-    Vitastor поддерживает все модели адаптеров, включая те, у которых нет
-    поддержки ODP (On-Demand Paging), например, ConnectX-3 и карты производства
-    не Mellanox. Функция ODP доступна только на адаптерах Mellanox ConnectX-4 и
-    более новых и позволяет не регистрировать память для её использования RDMA-картой,
-    благодаря чему в теории можно избежать лишних копирований памяти.
-
-    Версии Vitastor до 1.2.0 включительно требовали ODP, потом функция был отключена
-    по умолчанию, но поддерживалась вплоть до версии 3.0.3. Сейчас поддержка ODP
-    полностью удалена, так как на самом деле она только портит производительность:
-    например, на 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
 - name: rdma_port_num
   type: int
+  default: 1
   info: |
     RDMA device port number to use. Only for devices that have more than 1 port.
     See `phys_port_cnt` in `ibv_devinfo -v` output to determine how many ports
     your device has.
-
-    Not relevant for RDMA-CM (use_rdmacm).
   info_ru: |
     Номер порта RDMA-устройства, который следует использовать. Имеет смысл
     только для устройств, у которых более 1 порта. Чтобы узнать, сколько портов
     у вашего адаптера, посмотрите `phys_port_cnt` в выводе команды
     `ibv_devinfo -v`.
-
-    Опция неприменима к RDMA-CM (use_rdmacm).
 - name: rdma_gid_index
   type: int
   info: |
@@ -172,8 +116,6 @@
     GID auto-selection is unsupported with libibverbs < v32.
 
     A correct rdma_gid_index for RoCEv2 is usually 1 (IPv6) or 3 (IPv4).
-
-    Not relevant for RDMA-CM (use_rdmacm).
   info_ru: |
     Номер глобального идентификатора адреса RDMA-устройства, который следует
     использовать. Разным gid_index могут соответствовать разные протоколы связи:
@@ -186,63 +128,15 @@
     libibverbs < v32.
 
     Правильный rdma_gid_index для RoCEv2, как правило, 1 (IPv6) или 3 (IPv4).
-
-    Опция неприменима к RDMA-CM (use_rdmacm).
-- name: rdma_traffic_class
-  type: int
-  default: 0
-  info: |
-    Full TOS byte for RDMA traffic in the IP header (RoCEv2): DSCP in the
-    higher 6 bits and ECN in the lower 2 bits. For example, 106 (0x6A) =
-    DSCP 26 + ECT(0). Works with both libibverbs and RDMA-CM modes and should
-    be set on both OSDs and clients to mark traffic in both directions.
-    Default 0 = don't mark.
-  info_ru: |
-    Полный байт TOS для RDMA-трафика в заголовке IP (RoCEv2): DSCP в старших
-    6 битах и ECN в младших 2. Например, 106 (0x6A) = DSCP 26 + ECT(0).
-    Работает в обоих режимах RDMA - и libibverbs, и RDMA-CM; должен быть задан
-    и на OSD, и на клиентах, чтобы трафик помечался в обе стороны. По умолчанию
-    0 - не помечать.
-- name: rdma_sl
-  type: int
-  default: 0
-  info: |
-    Service Level (802.1p priority analogue) for RDMA traffic, put into the
-    address vector of every connection. Only applies to the libibverbs mode:
-    in RDMA-CM mode the service level is derived from rdma_traffic_class.
-    Default 0 = as is without PFC-configured networks.
-  info_ru: |
-    Service Level (аналог приоритета 802.1p) для RDMA-трафика; попадает в
-    адресный вектор каждого соединения. Применим только к libibverbs-режиму:
-    в RDMA-CM уровень обслуживания выводится из rdma_traffic_class.
-    По умолчанию 0 = как в сетях без PFC.
-- name: rdma_set_flow_label
-  type: bool
-  default: false
-  info: |
-    Automatically derive an IPv6 Flow Label for RDMA connections from the
-    queue pair number pair, so that every connection gets its own label and
-    connections spread over ECMP links while each connection keeps a single
-    stable path.  Only applied to IPv6 GIDs: an IPv4-mapped GID
-    (::ffff:a.b.c.d) produces IPv4 packets which have no flow label.  Only
-    applies to the libibverbs mode; RDMA-CM generates flow labels on its own.
-    Default false = don't set.
-  info_ru: |
-    Автоматически выводить IPv6 Flow Label для RDMA-соединений из пары
-    номеров очередей (QPN), чтобы каждое соединение получало свою метку,
-    соединения распределялись по ECMP-каналам, но каждое соединение шло по
-    одному стабильному пути. Применяется только к IPv6-GID: IPv4-mapped GID
-    (::ffff:a.b.c.d) даёт IPv4-пакеты, где поля flow label нет. Применим
-    только к libibverbs-режиму - RDMA-CM всегда генерирует flow label сам.
-    По умолчанию false = не задавать.
 - name: rdma_mtu
   type: int
+  default: 4096
   info: |
-    RDMA Path MTU to use. Must be 1024, 2048 or 4096. Default is to use the
-    RDMA device's MTU.
+    RDMA Path MTU to use. Must be 1024, 2048 or 4096. There is usually no
+    sense to change it from the default 4096.
   info_ru: |
     Максимальная единица передачи (Path MTU) для RDMA. Должно быть равно 1024,
-    2048 или 4096. По умолчанию используется значение MTU RDMA-устройства.
+    2048 или 4096. Обычно нет смысла менять значение по умолчанию, равное 4096.
 - name: rdma_max_sge
   type: int
   default: 128
@@ -289,6 +183,45 @@
     у принимающей стороны в процессе работы не заканчивались буферы на приём.
     Не влияет на потребление памяти - дополнительная память на операции отправки
     не выделяется.
+- name: rdma_odp
+  type: bool
+  default: false
+  online: false
+  info: |
+    Use RDMA with On-Demand Paging. ODP is currently only available on Mellanox
+    ConnectX-4 and newer adapters. ODP allows to not register memory explicitly
+    for RDMA adapter to be able to use it. This, in turn, allows to skip memory
+    copying during sending. One would think this should improve performance, but
+    **in reality** RDMA performance with ODP is **drastically** worse. Example
+    3-node cluster with 8 NVMe in each node and 2*25 GBit/s ConnectX-6 RDMA network
+    without ODP pushes 3950000 read iops, but only 239000 iops with ODP...
+
+    This happens because Mellanox ODP implementation seems to be based on
+    message retransmissions when the adapter doesn't know about the buffer yet -
+    it likely uses standard "RNR retransmissions" (RNR = receiver not ready)
+    which is generally slow in RDMA/RoCE networks. Here's a presentation about
+    it from ISPASS-2021 conference: https://tkygtr6.github.io/pub/ISPASS21_slides.pdf
+
+    ODP support is retained in the code just in case a good ODP implementation
+    appears one day.
+  info_ru: |
+    Использовать RDMA с On-Demand Paging. ODP - функция, доступная пока что
+    исключительно на адаптерах Mellanox ConnectX-4 и более новых. ODP позволяет
+    не регистрировать память для её использования RDMA-картой. Благодаря этому
+    можно не копировать данные при отправке их в сеть и, казалось бы, это должно
+    улучшать производительность - но **по факту** получается так, что
+    производительность только ухудшается, причём сильно. Пример - на 3-узловом
+    кластере с 8 NVMe в каждом узле и сетью 2*25 Гбит/с на чтение с RDMA без ODP
+    удаётся снять 3950000 iops, а с ODP - всего 239000 iops...
+
+    Это происходит из-за того, что реализация ODP у Mellanox неоптимальная и
+    основана на повторной передаче сообщений, когда карте не известен буфер -
+    вероятно, на стандартных "RNR retransmission" (RNR = receiver not ready).
+    А данные повторные передачи в RDMA/RoCE - всегда очень медленная штука.
+    Презентация на эту тему с конференции ISPASS-2021: https://tkygtr6.github.io/pub/ISPASS21_slides.pdf
+
+    Возможность использования ODP сохранена в коде на случай, если вдруг в один
+    прекрасный день появится хорошая реализация ODP.
 - name: peer_connect_interval
   type: sec
   min: 1
@@ -373,119 +306,3 @@
     detect disconnections quickly.
   info_ru: |
     Интервал проверки живости вебсокет-подключений к etcd.
-- name: etcd_min_reload_interval
-  type: ms
-  default: 1000
-  online: true
-  info: |
-    Minimum interval for full etcd state reload. Introduced to prevent
-    excessive load on etcd during outages when etcd can't keep up with event
-    streams and cancels them.
-  info_ru: |
-    Минимальный интервал полной перезагрузки состояния из etcd. Добавлено для
-    предотвращения избыточной нагрузки на etcd во время отказов, когда etcd не
-    успевает рассылать потоки событий и отменяет их.
-- name: tcp_header_buffer_size
-  type: int
-  default: 65536
-  info: |
-    Size of the buffer used to read data using an additional copy. Vitastor
-    packet headers are 128 bytes, payload is always at least 4 KB, so it is
-    usually beneficial to try to read multiple packets at once even though
-    it requires to copy the data an additional time. The rest of each packet
-    is received without an additional copy. You can try to play with this
-    parameter and see how it affects random iops and linear bandwidth if you
-    want.
-  info_ru: |
-    Размер буфера для чтения данных с дополнительным копированием. Пакеты
-    Vitastor содержат 128-байтные заголовки, за которыми следуют данные размером
-    от 4 КБ и для мелких операций ввода-вывода обычно выгодно за 1 вызов читать
-    сразу несколько пакетов, даже не смотря на то, что это требует лишний раз
-    скопировать данные. Часть каждого пакета за пределами значения данного
-    параметра читается без дополнительного копирования. Вы можете попробовать
-    поменять этот параметр и посмотреть, как он влияет на производительность
-    случайного и линейного доступа.
-- name: rxbounce
-  type: bool
-  default: false
-  online: true
-  info: |
-    Receive all TCP data into an intermediate buffer before copying to the actual
-    destination. Enabling this option is required for Windows guests if you use TCP
-    and [security.en.md#proto_checksums](proto_checksums) because Windows uses a
-    shared system-wide 'dummy page' to skip unneeded blocks during reads and breaks
-    checksum verification with it when data copy is avoided. rxbounce is only needed
-    when you use TCP and don't use transport encryption (AES-GCM); it's not required
-    with RDMA or with GCM encryption because both always copy data anyway (yes, RDMA
-    isn't actually zerocopy in Vitastor).
-  info_ru: |
-    Принимать все данные по TCP в промежуточный буфер и потом копировать их в
-    буфер клиента (ВМ). Это нужно для гостевых ОС Windows с TCP и включёнными
-    [security.ru.md#proto_checksums](proto_checksums), потому что Windows использует
-    одну разделяемую общесистемную страницу-заглушку для пропуска ненужных блоков
-    при чтении и ломает проверку контрольных сумм, если данные не копируются лишний
-    раз. Опция rxbounce нужна только если вы используете TCP и не используете
-    транспортное шифрование (AES-GCM); с RDMA или шифрованием опция не нужна, так
-    как в этом случае данные копируются всегда (да, RDMA в Vitastor на самом деле
-    не zero-copy).
-- name: min_zerocopy_send_size
-  type: int
-  default: 32768
-  info: |
-    OSDs and clients will attempt to use io_uring-based zero-copy TCP send
-    for buffers larger than this number of bytes. Zero-copy send with io_uring is
-    supported since Linux kernel version 6.1. Support is auto-detected and disabled
-    automatically when not available. It can also be disabled explicitly by setting
-    this parameter to a negative value.
-
-    ⚠️ Warning! Zero-copy send performance may vary greatly from CPU to CPU and from
-    one kernel version to another. Generally, it tends to only make benefit with larger
-    messages. With smaller messages (say, 4 KB), it may actually be slower. 32 KB is
-    enough for almost all CPUs, but even smaller values are optimal for some of them.
-    For example, 4 KB is OK for EPYC Milan/Genoa and 12 KB is OK for Xeon Ice Lake
-    (but verify it yourself please).
-
-    Verification instructions:
-    1. Add `iommu=pt` into your Linux kernel command line and reboot.
-    2. Upgrade your kernel. For example, it's very important to use 6.11+ with recent AMD EPYCs.
-    3. Run some tests with the [send-zerocopy liburing example](https://github.com/axboe/liburing/blob/master/examples/send-zerocopy.c)
-       to find the minimal message size for which zero-copy is optimal.
-       Use `./send-zerocopy tcp -4 -R` at the server side and
-       `time ./send-zerocopy tcp -4 -b 0 -s BUFFER_SIZE -D SERVER_IP` at the client side with
-       `-z 0` (no zero-copy) and `-z 1` (zero-copy), and compare MB/s and used CPU time
-       (user+system).
-  info_ru: |
-    OSD и клиенты будут пробовать использовать TCP-отправку без копирования (zero-copy) на
-    основе io_uring для буферов, больших, чем это число байт. Отправка без копирования
-    поддерживается в io_uring, начиная с версии ядра Linux 6.1. Наличие поддержки
-    проверяется автоматически и zero-copy отключается, когда поддержки нет. Также
-    её можно отключить явно, установив данный параметр в отрицательное значение.
-
-    ⚠️ Внимание! Производительность данной функции может сильно отличаться на разных
-    процессорах и на разных версиях ядра Linux. В целом, zero-copy обычно быстрее с
-    большими сообщениями, а с мелкими (например, 4 КБ) zero-copy может быть даже
-    медленнее. 32 КБ достаточно почти для всех процессоров, но для каких-то можно
-    использовать даже меньшие значения. Например, для EPYC Milan/Genoa подходит 4 КБ,
-    а для Xeon Ice Lake - 12 КБ (но, пожалуйста, перепроверьте это сами).
-
-    Инструкция по проверке:
-    1. Добавьте `iommu=pt` в командную строку загрузки вашего ядра Linux и перезагрузитесь.
-    2. Обновите ядро. Например, для AMD EPYC очень важно использовать версию 6.11+.
-    3. Позапускайте тесты с помощью [send-zerocopy из примеров liburing](https://github.com/axboe/liburing/blob/master/examples/send-zerocopy.c),
-       чтобы найти минимальный размер сообщения, для которого zero-copy отправка оптимальна.
-       Запускайте `./send-zerocopy tcp -4 -R` на стороне сервера и
-       `time ./send-zerocopy tcp -4 -b 0 -s РАЗМЕР_БУФЕРА -D АДРЕС_СЕРВЕРА` на стороне клиента
-       с опцией `-z 0` (обычная отправка) и `-z 1` (отправка без копирования), и сравнивайте
-       скорость в МБ/с и занятое процессорное время (user+system).
-- name: use_sync_send_recv
-  type: bool
-  default: false
-  info: |
-    If true, synchronous send/recv syscalls are used instead of io_uring for
-    socket communication. Useless for OSDs because they require io_uring anyway,
-    but may be required for clients with old kernel versions.
-  info_ru: |
-    Если установлено в истину, то вместо io_uring для передачи данных по сети
-    будут использоваться обычные синхронные системные вызовы send/recv. Для OSD
-    это бессмысленно, так как OSD в любом случае нуждается в io_uring, но, в
-    принципе, это может применяться для клиентов со старыми версиями ядра.

docs/config/src/osd.en.md

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

docs/config/src/osd.ru.md

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

docs/config/src/osd.yml

@@ -1,26 +1,3 @@
-- name: bind_address
-  type: string or array of strings
-  type_ru: строка или массив строк
-  info: |
-    Instead of the network masks ([osd_network](network.en.md#osd_network) and
-    [osd_cluster_network](network.en.md#osd_cluster_network)), you can also set
-    OSD listen addresses explicitly using this parameter. May be useful if you
-    want to start OSDs on interfaces that are not UP + RUNNING.
-  info_ru: |
-    Вместо использования масок подсети ([osd_network](network.ru.md#osd_network) и
-    [osd_cluster_network](network.ru.md#osd_cluster_network)), вы также можете явно
-    задать адрес(а), на которых будут ожидать соединений OSD, с помощью данного
-    параметра. Это может быть полезно, например, чтобы запускать OSD на неподнятых
-    интерфейсах (не UP + RUNNING).
-- name: bind_port
-  type: int
-  info: |
-    By default, OSDs pick random ports to use for incoming connections
-    automatically. With this option you can set a specific port for a specific
-    OSD by hand.
-  info_ru: |
-    По умолчанию OSD сами выбирают случайные порты для входящих подключений.
-    С помощью данной опции вы можете задать порт для отдельного OSD вручную.
 - name: osd_iothread_count
   type: int
   default: 0
@@ -79,6 +56,44 @@
     реализовать дополнительный режим для монитора, который позволит отделять
     первичные OSD от вторичных, но пока не понятно, зачем это может кому-то
     понадобиться, поэтому это не реализовано.
+- name: osd_network
+  type: string or array of strings
+  type_ru: строка или массив строк
+  info: |
+    Network mask of the network (IPv4 or IPv6) to use for OSDs. Note that
+    although it's possible to specify multiple networks here, this does not
+    mean that OSDs will create multiple listening sockets - they'll only
+    pick the first matching address of an UP + RUNNING interface. Separate
+    networks for cluster and client connections are also not implemented, but
+    they are mostly useless anyway, so it's not a big deal.
+  info_ru: |
+    Маска подсети (IPv4 или IPv6) для использования для соединений с OSD.
+    Имейте в виду, что хотя сейчас и можно передать в этот параметр несколько
+    подсетей, это не означает, что OSD будут создавать несколько слушающих
+    сокетов - они лишь будут выбирать адрес первого поднятого (состояние UP +
+    RUNNING), подходящий под заданную маску. Также не реализовано разделение
+    кластерной и публичной сетей OSD. Правда, от него обычно всё равно довольно
+    мало толку, так что особенной проблемы в этом нет.
+- name: bind_address
+  type: string
+  default: "0.0.0.0"
+  info: |
+    Instead of the network mask, you can also set OSD listen address explicitly
+    using this parameter. May be useful if you want to start OSDs on interfaces
+    that are not UP + RUNNING.
+  info_ru: |
+    Этим параметром можно явным образом задать адрес, на котором будет ожидать
+    соединений OSD (вместо использования маски подсети). Может быть полезно,
+    например, чтобы запускать OSD на неподнятых интерфейсах (не UP + RUNNING).
+- name: bind_port
+  type: int
+  info: |
+    By default, OSDs pick random ports to use for incoming connections
+    automatically. With this option you can set a specific port for a specific
+    OSD by hand.
+  info_ru: |
+    По умолчанию OSD сами выбирают случайные порты для входящих подключений.
+    С помощью данной опции вы можете задать порт для отдельного OSD вручную.
 - name: autosync_interval
   type: sec
   default: 5
@@ -253,33 +268,21 @@
   type: bool
   default: true
   info: |
-    Only for the old store ([meta_format](layout-osd.en.md#meta_format) 2).
-
-    This parameter makes Vitastor keep a copy of metadata area in memory as it is
-    on disk, in addition to the metadata database. When the option is enabled, every
-    metadata entry is effectively stored in RAM twice. It's required for good performance
-    because it allows to avoid additional read-modify-write cycles during metadata
-    modifications. Metadata area size with the old store is roughly 224 MB per 1 TB
-    of data. You can turn the option off to reduce memory usage by this value, but
-    it will reduce performance.
-
-    For the new store ([meta_format](layout-osd.en.md#meta_format) 3), the option
-    may be changed in the future to support operation without loading full metadata
-    database in memory.
+    This parameter makes Vitastor always keep metadata area of the block device
+    in memory. It's required for good performance because it allows to avoid
+    additional read-modify-write cycles during metadata modifications. Metadata
+    area size is currently roughly 224 MB per 1 TB of data. You can turn it off
+    to reduce memory usage by this value, but it will hurt performance. This
+    restriction is likely to be removed in the future along with the upgrade
+    of the metadata storage scheme.
   info_ru: |
-    Только для старого хранилища ([meta_format](layout-osd.en.md#meta_format) 2).
-
-    Данный параметр заставляет Vitastor всегда держать копию области метаданных
-    в памяти в том же виде, как она лежит на диске, в дополнение к БД метаданных.
-    То есть, с включённой опцией каждая запись метаданных хранится в памяти дважды.
-    Это нужно, чтобы избегать дополнительных операций чтения с диска при записи.
-    Размер области метаданных в старом хранилище составляет примерно 224 МБ на
-    1 ТБ данных. Вы можете отключить опцию, чтобы снизить потребление памяти
-    примерно на эту величину, но при этом также снизится и производительность.
-
-    Для нового хранилища ([meta_format](layout-osd.en.md#meta_format) 3) опция,
-    возможно, будет переработана в будущем для поддержки работы без полной
-    загрузки метаданных в памяти.
+    Данный параметр заставляет Vitastor всегда держать область метаданных диска
+    в памяти. Это нужно, чтобы избегать дополнительных операций чтения с диска
+    при записи. Размер области метаданных на данный момент составляет примерно
+    224 МБ на 1 ТБ данных. При включении потребление памяти снизится примерно
+    на эту величину, но при этом также снизится и производительность. В будущем,
+    после обновления схемы хранения метаданных, это ограничение, скорее всего,
+    будет ликвидировано.
 - name: inmemory_journal
   type: bool
   default: true
@@ -312,7 +315,7 @@
     decrease write performance for fast disks because page cache is an overhead
     itself.
 
-    Choose "directsync" to use [immediate_commit](layout-cluster.en.md#immediate_commit)
+    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
@@ -398,15 +401,11 @@
     blocks. The only situation when you should increase it to a larger value
     is when you enable journal_no_same_sector_overwrites. In this case set
     it to, for example, 1024.
-
-    Not applicable to the new store ([meta_format](layout-osd.en.md#meta_format) 3).
   info_ru: |
     Максимальное число буферов, разрешённых для использования под записываемые
     в журнал блоки метаданных. Единственная ситуация, в которой этот параметр
     нужно менять - это если вы включаете journal_no_same_sector_overwrites. В
     этом случае установите данный параметр, например, в 1024.
-
-    Неприменимо к новому хранилищу ([meta_format](layout-osd.en.md#meta_format) 3).
 - name: journal_no_same_sector_overwrites
   type: bool
   default: false
@@ -418,8 +417,6 @@
     journal after writing it instead of possibly overwriting it the second time.
 
     Most (99%) other SSDs don't need this option.
-
-    Not applicable to the new store ([meta_format](layout-osd.en.md#meta_format) 3).
   info_ru: |
     Включайте данную опцию для SSD вроде Intel D3-S4510 и D3-S4610, которые
     ОЧЕНЬ не любят, когда ПО перезаписывает один и тот же сектор несколько раз
@@ -430,20 +427,6 @@
     самого сектора.
 
     Почти все другие SSD (99% моделей) не требуют данной опции.
-
-    Неприменимо к новому хранилищу ([meta_format](layout-osd.en.md#meta_format) 3).
-- name: skip_corrupted_meta_entries
-  type: bool
-  default: false
-  info: |
-    Only for the new store ([meta_format](layout-osd.en.md#meta_format) 3).
-    Allow OSD to start when some metadata entries or blocks are corrupted by
-    skipping them. Should be only used as an emergency measure.
-  info_ru: |
-    Только для нового хранилища ([meta_format](layout-osd.en.md#meta_format) 3).
-    Разрешить OSD запускаться, даже если часть блоков или записей метаданных
-    повреждена, пропуская их. Опция предназначена для использования только в
-    целях аварийного восстановления.
 - name: throttle_small_writes
   type: bool
   default: false
@@ -598,7 +581,7 @@
     сильно влияет на пользовательскую нагрузку.
 - name: scrub_list_limit
   type: int
-  default: 262144
+  default: 1000
   online: true
   info: |
     Number of objects to list in one listing operation during scrub.
@@ -782,163 +765,3 @@
     Максимальное возможное значение авто-подстроенного recovery_sleep_us.
     Большие значения считаются случайными выбросами и игнорируются в
     усреднении.
-- name: discard_on_start
-  type: bool
-  info: Discard (SSD TRIM) unused data device blocks on every OSD startup.
-  info_ru: Освобождать (SSD TRIM) неиспользуемые блоки диска данных при каждом запуске OSD.
-- name: min_discard_size
-  type: int
-  default: 1048576
-  info: Minimum consecutive block size to TRIM it.
-  info_ru: Минимальный размер последовательного блока данных, чтобы освобождать его через TRIM.
-- name: allow_net_split
-  type: bool
-  default: false
-  info: |
-    Allow "safe" cases of network splits/partitions - allow to start PGs without
-    connections to some OSDs currently registered as alive in etcd, if the number
-    of actually connected PG OSDs is at least pg_minsize. That is, allow some OSDs to lose
-    connectivity with some other OSDs as long as it doesn't break pg_minsize guarantees.
-    The downside is that it increases the probability of writing data into just pg_minsize
-    OSDs during failover which can lead to PGs becoming incomplete after additional outages.
-
-    The old behaviour in versions up to 2.0.0 was equal to enabled allow_net_split.
-  info_ru: |
-    Разрешить "безопасные" случаи разделений сети - разрешить активировать PG без
-    соединений к некоторым OSD, помеченным активными в etcd, если общее число активных
-    OSD в PG составляет как минимум pg_minsize. То есть, разрешать некоторым OSD терять
-    соединения с некоторыми другими OSD, если это не нарушает гарантий pg_minsize.
-    Минус такого разрешения в том, что оно повышает вероятность записи данных ровно в
-    pg_minsize OSD во время переключений, что может потом привести к тому, что PG станут
-    неполными (incomplete), если упадут ещё какие-то OSD.
-
-    Старое поведение в версиях до 2.0.0 было идентично включённому allow_net_split.
-- name: enable_pg_locks
-  type: bool
-  info: |
-    Vitastor 2.2.0 introduces a new layer of split-brain prevention mechanism in
-    addition to etcd: PG locks. They prevent split-brain even in abnormal theoretical cases
-    when etcd is extremely laggy. As a new feature, by default, PG locks are only enabled
-    for pools where they're required - pools with [localized reads](pool.en.md#local_reads).
-    Use this parameter to enable or disable this function for all pools.
-  info_ru: |
-    В Vitastor 2.2.0 появился новый слой защиты от сплитбрейна в дополнение к etcd -
-    блокировки PG. Они гарантируют порядок даже в теоретических ненормальных случаях,
-    когда etcd очень сильно тормозит. Так как функция новая, по умолчанию она включается
-    только для пулов, в которых она необходима - а именно, в пулах с включёнными
-    [локальными чтениями](pool.ru.md#local_reads). Ну а с помощью данного параметра
-    можно включить блокировки PG для всех пулов.
-- name: pg_lock_retry_interval_ms
-  type: ms
-  default: 100
-  info: Retry interval for failed PG lock attempts.
-  info_ru: Интервал повтора неудачных попыток блокировки PG.
-- name: atomic_write_size
-  type: int
-  default: 4096
-  info: |
-    Maximum data device atomic write size allowed for OSD to use.
-
-    Atomic writes allow to reduce the Write Amplification factor with the new store
-    ([meta_format](layout-osd.en.md#meta_format)=3) to almost 1 (i.e. almost no extra writes)
-    with replicated pools and reach the best possible write performance.
-
-    Default value is auto-detected during OSD initialization from
-    `/sys/block/xx/queue/atomic_write_max_bytes` or assumed to be 4096 bytes
-    because all known disks support 4 KB atomic writes. Auto-detection is only used for
-    NVMe disks because SAS disks require the explicit WRITE ATOMIC command which requires
-    RWF_ATOMIC (see below [#use_atomic_flag]) but that flag works incorrectly in current
-    Linux versions.
-
-    You can also check if your NVMe drives support atomic writes by running
-    the command `nvme id-ctrl /dev/nvme0n1 | grep awupf`. If the reported value,
-    plus 1, multiplied by the currently selected block size of the NVMe,
-    is more than 4 KB, then the new store can utilize it for better performance.
-    The only drives known to support it currently are [Micron and Kioxia](../intro/quickstart.en.md).
-
-    Atomic writes allow to skip double data writes in replicated pools, thus
-    reducing Write Amplification and improving write performance up to 2 times.
-  info_ru: |
-    Максимальный размер атомарной записи на диск данных, который OSD разрешено использовать.
-
-    Поддержка атомарной записи позволяет снизить мультипликатор записи (Write Amplification)
-    на диск с новым хранилищем ([meta_format](layout-osd.ru.md#meta_format)=3)
-    практически до 1 (то есть, почти до нулевого объёма лишней записи) в реплицированных
-    пулах и достигнуть наилучшей возможной производительности записи.
-
-    Значение по умолчанию авто-определяется во время инициализации OSD из
-    `/sys/block/xx/queue/atomic_write_max_bytes` либо принимается равным 4096,
-    так как все известные диски поддерживают атомарную запись 4 КБ блоков.
-    Автоопределение применяется только для NVMe-дисков, так как SAS диски требуют
-    использования отдельной команды WRITE ATOMIC, а для неё нужен флаг RWF_ATOMIC
-    (см. ниже [#use_atomic_flag]), а он в текущих версиях Linux работает некорректно.
-
-    Вы также можете проверить, поддерживают ли ваши NVMe-диски атомарную запись,
-    с помощью команды `nvme id-ctrl /dev/nvme0n1 | grep awupf`. Если значение awupf
-    плюс 1, умноженное на текущий выбранный размер блока NVMe-диска, больше 4 КБ,
-    то новое хранилище может использовать атомарные записи для достижения лучшей
-    производительности. Единственные известные диски, которые поддерживают это сейчас -
-    [Micron и Kioxia](../intro/quickstart.ru.md).
-
-    Атомарная запись позволяет не использовать двойную запись данных (в журнал и на
-    устройство данных) в реплицированных пулах и таким образом снижает амплификацию
-    записи (объём служебной записи на диск) и улучшает производительность записи
-    вплоть до 2-х кратного прироста.
-- name: use_atomic_flag
-  type: bool
-  info: |
-    This option controls whether Vitastor OSDs use RWF_ATOMIC write flag with atomic writes.
-    This flag is supported since Linux 6.11 and adds some safety to atomic writes - the kernel
-    guarantees to not fragment write requests with it and also to check them against the actual
-    device atomic write capabilities.
-
-    However, the option is disabled by default because the flag is currently UNUSABLE - Linux
-    incorrectly requires writes with that flag to be of power-of-2 length and length-aligned.
-    I.e., for example, 12 KB writes and not-8-KB aligned 8 KB writes are forbidden by the kernel,
-    even though the NVMe specification allows them.
-
-    For NVMe disks with `scheduler=none` writes aren't fragmented anyway so it's not a big deal.
-    However, you can rebuild your kernel with [this patch](../../patches/linux-fix-atomic-write-checks.diff)
-    and turn this option on. It will make your atomic writes a bit safer.
-  info_ru: |
-    Данная опция контролирует использование Vitastor OSD флага RWF_ATOMIC при атомарной записи
-    блоков. Этот флаг поддерживается, начиная с версии ядра Linux 6.11 и добавляет немного корректности
-    атомарным записям - ядро гарантирует отсутствие фрагментации запросов записи с этим флагом и
-    проверяет их на соответствие реальным возможностям устройства.
-
-    Однако, данная опция по умолчанию отключена, так как флаг в текущих версиях Linux работает
-    абсолютно НЕКОРРЕКТНО - при нём Linux требует, чтобы запросы записи имели длину, равную
-    степени двойки и были выровнены на эту длину. То есть, например, 12 КБ запросы записи, а также
-    8 КБ запросы записи по не-кратному 8 КБ смещению запрещаются ядром, хотя спецификация NVMe их
-    разрешает.
-
-    Для NVMe-дисков с `scheduler=none` запросы записи и так не фрагментируются, так что это не так
-    уж и важно, однако вы можете пересобрать своё ядро с [этим патчем](../../patches/linux-fix-atomic-write-checks.diff)
-    и включить данную опцию. Это сделает вашу атомарную запись капельку безопаснее.
-- name: pg_reshard_chunk_size
-  type: int
-  default: 100000
-  info: |
-    Pool PG count change is a CPU-intensive operation because OSDs store the full object database
-    in memory and have to move all entries between old and new PGs. Thus it's performed in chunks,
-    with pauses between chunks to prevent blocking OSD's event loop and other clients' operations.
-    This option sets the maximum number of object is a chunk. Moving 100k objects usually takes
-    50-100ms. Chunk size equal to 0 means unlimited.
-  info_ru: |
-    Изменение числа PG в пуле заметно загружает процессор, так как OSD хранят полную базу данных
-    объектов в памяти и им приходится перемещать все записи объектов между старыми и новыми PG.
-    Поэтому изменение применяется порциями, с паузами между порциями, чтобы не блокировать обработку
-    событий OSD и операции остальных клиентов. Данная опция задаёт максимальное число объектов
-    в порции. Перемещение 100 тысяч объектов (значение по умолчанию) обычно занимает порядка
-    50-100 миллисекунд. Значение опции 0 отключает лимит размера порции.
-- name: pg_reshard_chunk_pause_ms
-  type: ms
-  default: 100
-  info: |
-    This option sets the interval between handling two PG count change chunks.
-  info_ru: |
-    Данная опция задаёт интервал между обработкой двух порций изменения числа PG пулов.
-- name: gc_on_start
-  type: bool
-  info: Forcibly clean all garbage entries in the new store on every OSD restart.
-  info_ru: Принудительно очищать все мусорные записи в новом хранилище при каждом запуске OSD.

docs/config/src/package.json

@@ -1,5 +0,0 @@
-{
-  "dependencies": {
-    "yaml": "^2.8.2"
-  }
-}

docs/config/src/security.en.md

@@ -1,9 +0,0 @@
-# Security Parameters
-
-These parameters affect your Vitastor installation security and apply to OSDs, monitors and clients.
-
-Most of them can be set in /etc/vitastor/vitastor.conf and in etcd, but don't support online modification.
-
-All certificate and private key parameters mentioned may contain a path to a PEM file or just
-a PEM string with certificate or a private key. In the latter case, the string must begin with
-"-----BEGIN CERTIFICATE-----" or "-----BEGIN PRIVATE KEY-----".

docs/config/src/security.ru.md

@@ -1,11 +0,0 @@
-# Параметры безопасности
-
-Данные параметры затрагивают безопасность инсталляций Vitastor и используются
-OSD, мониторами и клиентами.
-
-Большая их часть может задаваться в /etc/vitastor/vitastor.conf и в etcd, но не
-поддерживает онлайн-изменение.
-
-Все параметры сертификатов и закрытых ключей могут быть путём к файлу или просто
-строкой с сертификатом в формате PEM. В последнем случае строка должна начинаться с
-"-----BEGIN CERTIFICATE-----" или "-----BEGIN PRIVATE KEY-----".

docs/config/src/security.yml

@@ -1,282 +0,0 @@
-- name: use_perms
-  type: bool
-  default: false
-  info: |
-    Enable client permissions in a Vitastor cluster, including Antietcd built into the Monitor.
-    Requires configured encryption. Also note that separate Antietcd requires separate configuration
-    to use permissions (see [security documentation](../usage/security.en.md) for details).
-  info_ru: |
-    Включает клиентские привилегии в кластере Vitastor, в том числе во встроенном в мониторе Antietcd.
-    Требует настроенного шифрования протокола. Также обратите внимание, что отдельно установленный Antietcd
-    требует отдельной настройки привилегий (подробности смотрите в [документации безопасности](../usage/security.ru.md)).
-- name: cert
-  type: string
-  info: |
-    Client certificate of the current Vitastor user. Required for Vitastor protocol encryption.
-    Must be signed with [client_ca](#client_ca). Also used as the client certificate for etcd/Antietcd
-    connections by default.
-  info_ru: |
-    Клиентский сертификат текущего пользователя Vitastor. Требуется для шифрования протокола Vitastor.
-    Должен быть подписан [client_ca](#client_ca). Также по умолчанию используется как клиентский
-    сертификат для подключения к etcd/Antietcd и Vault.
-- name: pkey
-  type: string
-  info: Private key of the current Vitastor user.
-  info_ru: Закрытый ключ текущего пользователя Vitastor.
-- name: etcd_ca
-  type: string
-  info: |
-    Trusted TLS CA to verify etcd server certificate. Or just the etcd server's
-    certificate itself - it's fine to use it for etcd_ca.
-  info_ru: |
-    Доверенный корневой TLS-сертификат для проверки сертификата сервера etcd.
-    Либо же просто сам сертификат сервера etcd - его можно использовать как etcd_ca.
-- name: client_ca
-  type: string
-  info: |
-    Trusted TLS CA to verify Vitastor client certificates.
-    Mandatory for Vitastor protocol encryption.
-  info_ru: |
-    Доверенный TLS-сертификат для проверки сертификатов клиентов Vitastor.
-    Требуется для шифрования протокола Vitastor.
-- name: admin_ca
-  type: string
-  info: |
-    Trusted TLS CA to verify Vitastor administrator certificates.
-  info_ru: |
-    Доверенный TLS-сертификат для проверки сертификатов администраторов Vitastor.
-- name: osd_ca
-  type: string
-  info: |
-    Trusted TLS CA to verify Vitastor OSD certificates. Also mandatory for Vitastor protocol
-    encryption. Must be different from client_ca. May be equal to osd_cert - different OSDs
-    don't require separate certificates at the moment because their permissions don't differ.
-  info_ru: |
-    Доверенный TLS-сертификат для проверки сертификатов OSD Vitastor. Также обязателен
-    для шифрования протокола Vitastor. Должен отличаться от client_ca. Может быть равен
-    osd_cert - разные OSD не требуют разных сертификатов, потому что на данный момент
-    привилегии разных OSD никак не отличаются.
-- name: mon_ca
-  type: string
-  info: |
-    Trusted TLS CA to verify Vitastor Monitor certificates. Used only for separate Antietcd,
-    not required when a monitor built-in Antietcd is used. May be equal to mon_client_etcd_cert.
-  info_ru: |
-    Доверенный TLS-сертификат для проверки сертификатов мониторов Vitastor. Используется
-    только отдельно установленным Antietcd, не требуется при использовании встроенного в монитор
-    Antietcd. Может быть равен mon_client_etcd_cert.
-- name: antietcd_cert
-  type: string
-  info: Server TLS certificate for Antietcd built into the Monitor.
-  info_ru: Серверный TLS-сертификат для Antietcd, встроенного в монитор.
-- name: antietcd_key
-  type: string
-  info: Private key for antietcd_cert.
-  info_ru: Закрытый ключ для сертификата antietcd_cert.
-- name: etcd_proxy.urls
-  type: string or array of strings
-  type_ru: строка или массив строк
-  info: |
-    etcd URLs for Antietcd etcd proxy mode.
-    See [Mon as Etcd proxy](../usage/security.en.md#mon-as-etcd-proxy) for details.
-  info_ru: |
-    Адреса etcd для режима Antietcd etcd-прокси.
-    Смотрите подробности в разделе [Mon в роли Etcd proxy](../usage/security.ru.md#mon-в-роли-etcd-proxy).
-- name: etcd_proxy.cert
-  type: string
-  info: Client certificate for Antietcd connections to etcd in proxy mode.
-  info_ru: Клиентский сертификат для подключений от Antietcd к etcd в режиме прокси.
-- name: etcd_proxy.key
-  type: string
-  info: Private key for etcd_proxy.cert.
-  info_ru: Закрытый ключ для сертификата etcd_proxy.cert.
-- name: etcd_proxy.ca
-  type: string
-  info: Trusted TLS CA to verify etcd server certificate when connecting to it from Antietcd.
-  info_ru: Доверенный TLS-сертификат для проверки сертификата сервера etcd при подключениях от Antietcd.
-- name: osd_cert
-  type: string
-  info: |
-    Vitastor OSD server certificate. Required for Vitastor protocol encryption. May be equal
-    to [osd_ca](#osd_ca) - all OSDs share the same permission set for now. Also used as the client
-    certificate for connections from OSD to etcd/Antietcd by default.
-  info_ru: |
-    Сертификат сервера Vitastor OSD. Требуется для шифрования протокола Vitastor. Может быть равен
-    [osd_ca](#osd_ca) - все OSD на данный момент имеют одинаковые привилегии. Также по умолчанию
-    используется как клиентский сертификат для подключения от OSD к etcd/Antietcd.
-- name: osd_pkey
-  type: string
-  info: Private key for osd_cert.
-  info_ru: Закрытый ключ для сертификата osd_cert.
-- name: api_cert
-  type: string
-  info: Server TLS certificate for [vitastor-cli serve](../usage/cli.en.md#serve) API server.
-  info_ru: Серверный TLS-сертификат для API-сервера [vitastor-cli serve](../usage/cli.ru.md#serve).
-- name: api_pkey
-  type: string
-  info: Private key for api_cert.
-  info_ru: Закрытый ключ для сертификата api_cert.
-- name: etcd_client_cert
-  type: string
-  info: |
-    Client TLS certificate to use for connections from Vitastor clients to etcd/Antietcd if you don't want
-    to use the common client certificate [cert](#cert).
-  info_ru: |
-    Клиентский TLS сертификат для подключений от клиентов Vitastor к etcd/Antietcd, если вы не хотите
-    использовать общий клиентский сертификат [cert](#cert).
-- name: etcd_client_key
-  type: string
-  info: Private key for etcd_client_cert.
-  info_ru: Закрытый ключ для сертификата etcd_client_cert.
-- name: osd_etcd_client_cert
-  type: string
-  info: |
-    Client TLS certificate to use for connections from Vitastor OSDs to etcd/Antietcd if you don't want
-    to use the common OSD certificate [osd_cert](#osd_cert).
-  info_ru: |
-    Клиентский TLS сертификат для подключений от Vitastor OSD к etcd/Antietcd, если вы не хотите
-    использовать общий сертификат OSD [osd_cert](#osd_cert).
-- name: osd_etcd_client_key
-  type: string
-  info: Private key for osd_etcd_client_cert.
-  info_ru: Закрытый ключ для сертификата osd_etcd_client_cert.
-- name: mon_etcd_client_cert
-  type: string
-  info: |
-    Client TLS certificate to use for connections from Vitastor Monitors to etcd/Antietcd - required
-    if you don't use the built-in Antietcd. In case you use it Monitor has direct access to Antietcd data
-    and doesn't require any connection.
-  info_ru: |
-    Клиентский TLS сертификат для подключений от мониторов Vitastor к etcd/Antietcd - требуется, если
-    вы не используете встроенный в монитор Antietcd. Если вы используете его, то монитор и так имеет
-    прямой доступ к данным Antietcd и не требует никаких соединений.
-- name: mon_etcd_client_key
-  type: string
-  info: Private key for mon_etcd_client_cert.
-  info_ru: Закрытый ключ для сертификата mon_etcd_client_cert.
-- name: proto_checksums
-  type: string
-  default: payload
-  info: |
-    One of "full", "payload", "gcm", "none":
-    - "full" means calculate and verify transport level checksums from the full message data
-      including the header - recommended for unencrypted setups.
-    - "payload" enables checksums only for the actual read/write data, but skips them for message
-      headers - recommended for encrypted setups because headers are already protected by AES-GCM.
-    - "gcm" disables checksums and enables AES-GCM encryption of the whole messages including headers
-      and data - AES-GCM already includes MAC which is actually a stronger checksum. This option is
-      slower and is only recommended for untrusted networks.
-    - "none" disables transport level checksums at all.
-  info_ru: |
-    Одно из значений "full", "payload", "gcm" и "none":
-    - "full" означает расчёт и проверку контрольных сумм на транспортном уровне от полных сообщений,
-      включая их заголовки и данные - рекомендуется для кластеров без шифрования.
-    - "payload" включает контрольные суммы только для данных сообщений, но пропускает заголовки -
-      такая настройка рекомендуется для кластеров с включённым шифрованием, потому что в них заголовки
-      и так защищены шифрованием AES-GCM.
-    - "gcm" отключает контрольные суммы и включает шифрование полных сообщений включая заголовки и
-      данные - AES-GCM уже включает в себя MAC, который по сути является криптостойкой контрольной
-      суммой. Такая настройка медленнее и рекомендуется только для недоверенных сетей.
-    - "none" полностью отключает контрольные суммы на транспортном уровне.
-- name: force_proto_checksums
-  type: string
-  info: |
-    To allow older clients to connect to a Vitastor cluster with enabled checksums, Vitastor OSDs
-    allow clients to downgrade their proto_checksums by default. force_proto_checksums sets the
-    minimum security level allowed for connecting clients. When encryption is disabled, default
-    force_proto_checksums is none and clients without checksums are allowed. With enabled
-    encryption, force_proto_checksums becomes "payload" by default to block unauthenticated data
-    on the transport level.
-  info_ru: |
-    Чтобы старые клиенты Vitastor могли подключаться к кластеру с включёнными контрольными
-    суммами, Vitastor OSD по умолчанию разрешают клиентам отключать контрольные суммы
-    данных (proto_checksums). Настройка force_proto_checksums задаёт минимальный уровень
-    безопасности, разрешённый для подключающихся клиентов. Когда шифрование отключено,
-    force_proto_checksums по умолчанию равно none и подключения клиентов без контрольных
-    сумм разрешаются. При включённом шифровании значение по умолчанию force_proto_checksums
-    становится "payload", чтобы блокировать подключения с неаутентифицированными данными.
-- name: max_cipher_pool_size
-  type: int
-  default: 256
-  info: |
-    Maximum number of OpenSSL cipher contexts cached in OSD memory, counted separately
-    for each cipher and for encryption/decryption. Probably doesn't require modification.
-  info_ru: |
-    Максимальное количество кэшируемых в памяти OSD контекстов шифра OpenSSL, учитываемое
-    отдельно для каждого шифра и для шифрования и расшифровки. Вряд ли требует изменения.
-- name: vault_url
-  type: string
-  info: |
-    Vault base URL.
-
-    Vitastor clients support AES-256-XTS image data encryption with different per-image keys.
-    Encryption is performed by the client, OSDs don't have access to decrypted data.
-
-    Encryption keys may be stored in etcd or, for the increased security level, in an external
-    [HashiCorp Vault](https://developer.hashicorp.com/vault/) or [OpenBao](https://openbao.org/)
-    instance.
-
-    Vitastor clients use [v1 k/v secrets engine](https://openbao.org/api-docs/secret/kv/kv-v1/)
-    and [TLS authentication engine](https://openbao.org/api-docs/auth/cert/) in Vault.
-
-    In that case, only key IDs are stored in etcd.
-  info_ru: |
-    Базовый адрес Vault.
-
-    Клиенты Vitastor поддерживают AES-256-XTS шифрование данных образов с отдельными ключами на
-    каждый образ. Данные шифруются клиентами, OSD не имеют доступа к незашифрованным данным.
-
-    Ключи шифрования могут храниться в etcd или, для повышенного уровня безопасности, во внешнем
-    [HashiCorp Vault](https://developer.hashicorp.com/vault/) или [OpenBao](https://openbao.org/).
-
-    Клиенты Vitastor используют [движок секретов v1](https://openbao.org/api-docs/secret/kv/kv-v1/)
-    и [TLS-аутентификацию](https://openbao.org/api-docs/auth/cert/) в Vault.
-
-    В этом случае, только ID ключей хранятся в etcd.
-- name: vault_secret_api_path
-  type: string
-  default: /v1/secret/
-  info: Vault v1 secret API mount path to use.
-  info_ru: Путь к API секретов v1 для использования клиентами.
-- name: vault_client_cert
-  type: string
-  info: |
-    Client TLS certificate to use for Vault connections if you don't want to use the common Vitastor
-    client certificate [cert](#cert) which is also used for Vault connections by default.
-  info_ru: |
-    Клиентский TLS сертификат для подключений к Vault на тот случай, если вы не хотите использовать
-    общий сертификат клиента Vitastor [cert](#cert), используемый для подключений к Vault по умолчанию.
-- name: vault_client_key
-  type: string
-  info: Private key for the vault_client_cert certificate.
-  info_ru: Закрытый ключ для сертификата vault_client_cert.
-- name: vault_ca
-  type: string
-  info: |
-    Trusted TLS CA to verify Vault server certificate. May be path to a file,
-    directory or just a PEM string with certificate.
-  info_ru: |
-    Доверенный корневой TLS-сертификат для проверки сертификата сервера Vault.
-    Может быть путём к файлу, директории или просто строкой с сертификатом в
-    формате PEM.
-- name: vault_timeout_ms
-  type: int
-  default: 5000
-  info: Timeout for Vault requests in milliseconds.
-  info_ru: Максимально время выполнения Vault-запросов в миллисекундах.
-- name: vault_error_timeout_sec
-  type: int
-  default: 60
-  info: |
-    Time (in seconds) to wait before retrying after receiving an error from Vault.
-  info_ru: |
-    Время (в секундах) для ожидания перед повторной попыткой при получении ошибки от Vault.
-- name: vault_refresh_leeway_sec
-  type: int
-  default: 60
-  info: |
-    Extra time (in seconds) before real Vault token lease_timeout to refresh it, just
-    in case of system clock drift.
-  info_ru: |
-    Зазор времени (в секундах), чтобы обновлять токены Vault чуть раньше их реального
-    lease_timeout, на случай "ухода" системных часов.

docs/installation/docker.en.md

@@ -26,37 +26,13 @@ at Vitastor Kubernetes operator: https://github.com/Antilles7227/vitastor-operat
 The instruction is very simple.
 
 1. Download a Docker image of the desired version: \
-   `docker pull vitalif/vitastor:v3.2.2`
+   `docker pull vitastor:1.10.2`
 2. Install scripts to the host system: \
-   `docker run --rm -it -v /etc:/host-etc -v /usr/bin:/host-bin vitalif/vitastor:v3.2.2 install.sh`
+   `docker run --rm -it -v /etc:/host-etc -v /usr/bin:/host-bin vitastor:1.10.2 install.sh`
 3. Reload udev rules: \
    `udevadm control --reload-rules`
-4. Enable the vitastor-host service: \
-   `systemctl enable --now vitastor-host`
 
-After these steps, you can return to [Quick Start](../intro/quickstart.en.md).
-
-## Podman
-
-If you use Podman, run the following commands as root before installing Vitastor containers:
-
-```
-ln -s podman /usr/bin/docker
-
-mkdir -p /etc/systemd/system/systemd-udevd.service.d
-
-cat >/etc/systemd/system/systemd-udevd.service.d/override.conf <<EOF
-[Service]
-CapabilityBoundingSet=~
-SystemCallFilter=@mount capset
-EOF
-
-systemctl daemon-reload
-
-systemctl restart systemd-udevd
-```
-
-Without it, udev fails to do calls into a Podman container and Vitastor disk detection doesn't work.
+And you can return to [Quick Start](../intro/quickstart.en.md).
 
 ## Upgrading Containers
 

docs/installation/docker.ru.md

@@ -25,39 +25,14 @@ Vitastor можно установить в Docker/Podman. При этом etcd,
 Инструкция по установке максимально простая.
 
 1. Скачайте Docker-образ желаемой версии: \
-   `docker pull vitalif/vitastor:v3.2.2`
+   `docker pull vitastor:1.10.2`
 2. Установите скрипты в хост-систему командой: \
-   `docker run --rm -it -v /etc:/host-etc -v /usr/bin:/host-bin vitalif/vitastor:v3.2.2 install.sh`
+   `docker run --rm -it -v /etc:/host-etc -v /usr/bin:/host-bin vitastor:1.10.2 install.sh`
 3. Перезагрузите правила udev: \
    `udevadm control --reload-rules`
-4. Включите сервис vitastor-host: \
-   `systemctl enable --now vitastor-host`
 
 После этого вы можете возвращаться к разделу [Быстрый старт](../intro/quickstart.ru.md).
 
-## Podman
-
-Если вы используете Podman, перед установкой контейнеров Vitastor выполните следующие
-команды от имени суперпользователя:
-
-```
-ln -s podman /usr/bin/docker
-
-mkdir -p /etc/systemd/system/systemd-udevd.service.d
-
-cat >/etc/systemd/system/systemd-udevd.service.d/override.conf <<EOF
-[Service]
-CapabilityBoundingSet=~
-SystemCallFilter=@mount capset
-EOF
-
-systemctl daemon-reload
-
-systemctl restart systemd-udevd
-```
-
-Без этих настроек udev не может делать вызовы внутрь Podman-контейнеров и определение дисков Vitastor не работает.
-
 ## Обновление контейнеров
 
 Сначала обязательно проверьте раздел [Обновление Vitastor](../usage/admin.ru.md#обновление-vitastor),

docs/installation/openstack.en.md

@@ -30,7 +30,7 @@ volume_backend_name = vitastor-testcluster
 image_volume_cache_enabled = True
 volume_clear = none
 vitastor_etcd_address = 192.168.7.2:2379
-vitastor_etcd_prefix = /vitastor
+vitastor_etcd_prefix =
 vitastor_config_path = /etc/vitastor/vitastor.conf
 vitastor_pool_id = 1
 image_upload_use_cinder_backend = True

docs/installation/openstack.ru.md

@@ -29,7 +29,7 @@ volume_backend_name = vitastor-testcluster
 image_volume_cache_enabled = True
 volume_clear = none
 vitastor_etcd_address = 192.168.7.2:2379
-vitastor_etcd_prefix = /vitastor
+vitastor_etcd_prefix =
 vitastor_config_path = /etc/vitastor/vitastor.conf
 vitastor_pool_id = 1
 image_upload_use_cinder_backend = True

docs/installation/packages.en.md

@@ -11,34 +11,29 @@
 - Trust Vitastor package signing key:
   `wget https://vitastor.io/debian/pubkey.gpg -O /etc/apt/trusted.gpg.d/vitastor.gpg`
 - Add Vitastor package repository to your /etc/apt/sources.list:
-  - Debian 13 (Trixie/Sid): `deb https://vitastor.io/debian trixie main`
-  - Debian 12 (Bookworm): `deb https://vitastor.io/debian bookworm main`
+  - Debian 12 (Bookworm/Sid): `deb https://vitastor.io/debian bookworm main`
   - Debian 11 (Bullseye): `deb https://vitastor.io/debian bullseye main`
-  - Ubuntu 26.04 (Resolute): `deb https://vitastor.io/debian resolute main`
-  - Ubuntu 24.04 (Noble): `deb https://vitastor.io/debian noble main`
+  - Debian 10 (Buster): `deb https://vitastor.io/debian buster main`
   - Ubuntu 22.04 (Jammy): `deb https://vitastor.io/debian jammy main`
-- To always prefer vitastor-patched QEMU and Libvirt versions, add the following to `/etc/apt/preferences`:
-  ```
-  Package: *
-  Pin: origin "vitastor.io"
-  Pin-Priority: 501
-  ```
+  - Add `-oldstable` to bookworm/bullseye/buster in this line to install the last
+    stable version from 0.9.x branch instead of 1.x
 - Install packages: `apt update; apt install vitastor lp-solve etcd linux-image-amd64 qemu-system-x86`
 
 ## CentOS
 
 - Add Vitastor package repository:
+  - CentOS 7: `yum install https://vitastor.io/rpms/centos/7/vitastor-release.rpm`
   - CentOS 8: `dnf install https://vitastor.io/rpms/centos/8/vitastor-release.rpm`
   - AlmaLinux 9 and other RHEL 9 clones (Rocky, Oracle...): `dnf install https://vitastor.io/rpms/centos/9/vitastor-release.rpm`
-  - AlmaLinux 10 and other RHEL 10 clones: `dnf install https://vitastor.io/rpms/centos/10/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/10 clones: not required
+  - 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`
-  - RHEL 10 clones: not required
 - Install packages: `yum/dnf install vitastor lpsolve etcd kernel-ml qemu-kvm`
 
 ## Installation requirements
@@ -47,6 +42,7 @@
   recommended because io_uring is a relatively new technology and there is
   at least one bug which reproduces with io_uring and HP SmartArray
   controllers in 5.4
+- liburing 0.4 or newer
 - lp_solve
 - 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).

docs/installation/packages.ru.md

@@ -11,34 +11,29 @@
 - Добавьте ключ репозитория Vitastor:
   `wget https://vitastor.io/debian/pubkey.gpg -O /etc/apt/trusted.gpg.d/vitastor.gpg`
 - Добавьте репозиторий Vitastor в /etc/apt/sources.list:
-  - Debian 13 (Trixie/Sid): `deb https://vitastor.io/debian trixie main`
-  - Debian 12 (Bookworm): `deb https://vitastor.io/debian bookworm main`
+  - Debian 12 (Bookworm/Sid): `deb https://vitastor.io/debian bookworm main`
   - Debian 11 (Bullseye): `deb https://vitastor.io/debian bullseye main`
-  - Ubuntu 26.04 (Resolute): `deb https://vitastor.io/debian resolute main`
-  - Ubuntu 24.04 (Noble): `deb https://vitastor.io/debian noble main`
+  - Debian 10 (Buster): `deb https://vitastor.io/debian buster main`
   - Ubuntu 22.04 (Jammy): `deb https://vitastor.io/debian jammy main`
-- Чтобы всегда предпочитались версии пакетов QEMU и Libvirt с патчами Vitastor, добавьте в `/etc/apt/preferences`:
-  ```
-  Package: *
-  Pin: origin "vitastor.io"
-  Pin-Priority: 501
-  ```
+  - Добавьте `-oldstable` к слову bookworm/bullseye/buster в этой строке, чтобы
+    установить последнюю стабильную версию из ветки 0.9.x вместо 1.x
 - Установите пакеты: `apt update; apt install vitastor lp-solve etcd linux-image-amd64 qemu-system-x86`
 
 ## CentOS
 
 - Добавьте в систему репозиторий Vitastor:
+  - CentOS 7: `yum install https://vitastor.io/rpms/centos/7/vitastor-release.rpm`
   - CentOS 8: `dnf install https://vitastor.io/rpms/centos/8/vitastor-release.rpm`
   - AlmaLinux 9 и другие клоны RHEL 9 (Rocky, Oracle...): `dnf install https://vitastor.io/rpms/centos/9/vitastor-release.rpm`
-  - AlmaLinux 10 и другие клоны RHEL 10: `dnf install https://vitastor.io/rpms/centos/10/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/10: не нужно
+  - Клоны 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`
-  - Клоны RHEL 10: не нужно
 - Установите пакеты: `yum/dnf install vitastor lpsolve etcd kernel-ml qemu-kvm`
 
 ## Установочные требования
@@ -46,6 +41,7 @@
 - Ядро Linux 5.4 или новее, для поддержки io_uring. Рекомендуется даже 5.8,
   так как io_uring - относительно новый интерфейс и в версиях до 5.8 встречались
   некоторые баги, например, зависание с io_uring и контроллером HP SmartArray
+- liburing 0.4 или новее
 - lp_solve
 - etcd 3.4.15 или новее. Более старые версии не будут работать из-за разных багов,
   например, [#12402](https://github.com/etcd-io/etcd/pull/12402).

docs/installation/proxmox.en.md

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

docs/installation/proxmox.ru.md

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

docs/installation/s3.en.md

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

docs/installation/s3.ru.md

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

docs/installation/source.en.md

@@ -15,8 +15,9 @@
 - gcc and g++ 8 or newer, clang 10 or newer, or other compiler with C++11 plus
   designated initializers support from C++20
 - CMake
-- jerasure, c-ares headers and libraries
-- ISA-L, libibverbs, librdmacm, libnl3 headers and libraries (optional)
+- liburing, jerasure headers and libraries
+- ISA-L, libibverbs headers and libraries (optional)
+- tcmalloc (google-perftools-dev)
 
 ## Basic instructions
 

docs/installation/source.ru.md

@@ -15,8 +15,9 @@
 - gcc и g++ >= 8, либо clang >= 10, либо другой компилятор с поддержкой C++11 плюс
   назначенных инициализаторов (designated initializers) из C++20
 - CMake
-- Заголовки и библиотеки jerasure, c-ares
-- Опционально - заголовки и библиотеки ISA-L, libibverbs, librdmacm, libnl3
+- Заголовки и библиотеки liburing, jerasure
+- Опционально - заголовки и библиотеки ISA-L, libibverbs
+- tcmalloc (google-perftools-dev)
 
 ## Базовая инструкция
 

docs/intro/architecture.en.md

@@ -125,13 +125,6 @@ All other client-side components are based on the client library:
   all current read/write operations to it fail with EPIPE error and are retried by clients.
 - After completing all secondary read/write requests, primary OSD sends the response to
   the client.
-- When [localized reads](../config/pool.en.md#local_reads) are enabled for a PG in a
-  replicated pool, and the PG is in an active and clean state (active or
-  active+left_on_dead), the client can send the request to one of secondary OSDs instead
-  of the primary. Secondary OSD checks the [PG lock](../config/osd.en.md#enable_pg_locks)
-  and handles the request locally without communicating to the primary. PG lock is required
-  for the secondary OSD to know for sure that the PG is in clean state and not switching
-  primary at the moment.
 
 ### Nuances of request handling
 

docs/intro/architecture.ru.md

@@ -125,12 +125,6 @@
   и если любое из этих соединений отключается, PG перезапускается, а все текущие запросы чтения
   и записи в неё завершаются с ошибкой EPIPE, после чего повторяются клиентами.
 - После завершения всех вторичных операций чтения/записи первичный OSD отправляет ответ клиенту.
-- Если в реплицированном пуле включены [локализованные чтения](../config/pool.ru.md#local_reads),
-  а PG находится в чистом активном состоянии (active или active+left_on_dead), клиент может
-  послать запрос к одному из вторичных OSD вместо первичного. Вторичный OSD проверяет
-  [блокировку PG](../config/osd.ru.md#enable_pg_locks) и обрабатывает запрос локально, не
-  обращаясь к первичному. Блокировка PG здесь нужна, чтобы вторичный OSD мог точно знать,
-  что PG находится в чистом состоянии и не переключается на другой первичный OSD.
 
 ### Особенности обработки запросов
 

docs/intro/author.en.md

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

docs/intro/author.ru.md

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

docs/intro/features.en.md

@@ -14,8 +14,6 @@
 
 - Basic part: highly-available block storage with symmetric clustering and no SPOF
 - [Performance](../performance/bench2.en.md) ;-D
-  - [NVMe atomic write support](../config/osd.en.md#atomic_write_size) for reducing the amount
-    of "extra" disk writes to almost zero (Write Amplification = 1)
 - [Multiple redundancy schemes](../config/pool.en.md#scheme): Replication, XOR n+1, Reed-Solomon erasure codes
   based on jerasure and ISA-L libraries with any number of data and parity drives in a group
 - Configuration via simple JSON data structures in etcd (parameters, pools and images)
@@ -27,11 +25,10 @@
 - Recovery of degraded blocks
 - Rebalancing (data movement between OSDs)
 - [Lazy fsync support](../config/layout-cluster.en.md#immediate_commit)
-- [Localized read support](../config/pool.en.md#local_reads) for cross-datacenter setup optimization
 - Per-OSD and per-image I/O and space usage statistics in etcd
 - Snapshots and copy-on-write image clones
 - [Write throttling to smooth random write workloads in SSD+HDD configurations](../config/osd.en.md#throttle_small_writes)
-- RDMA/RoCEv2 support [via libibverbs](../config/network.en.md#use_rdma) or [RDMA-CM](../config/network.en.md#use_rdmacm)
+- [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)
@@ -40,9 +37,6 @@
 - [Experimental internal etcd replacement - antietcd](../config/monitor.en.md#use_antietcd)
 - [Built-in Prometheus metric exporter](../config/monitor.en.md#enable_prometheus)
 - [NFS RDMA support](../usage/nfs.en.md#rdma) (probably also usable for GPUDirect)
-- [S3](../installation/s3.en.md)
-- [Full transport encryption and access control](../usage/security.en.md)
-- [AES-256-XTS end-to-end image encryption](../usage/security.en.md#end-to-end-image-data-encryption-aes-xts) with [Vault support](../usage/security.en.md#vaultopenbao-setup) for key storage
 
 ## Plugins and tools
 
@@ -56,7 +50,7 @@
 - Generic user-space client library
 - [Native QEMU driver](../usage/qemu.en.md)
 - [Loadable fio engine for benchmarks](../usage/fio.en.md)
-- [UBLK](../usage/ublk.en.md) and [NBD](../usage/nbd.en.md) servers for kernel mounts
+- [NBD proxy for kernel mounts](../usage/nbd.en.md)
 - [Simplified NFS proxy for file-based image access emulation (suitable for VMWare)](../usage/nfs.en.md#pseudo-fs)
 
 ## Roadmap
@@ -69,6 +63,7 @@ The following features are planned for the future:
 - iSCSI and NVMeoF gateways
 - Multi-threaded client
 - Faster failover
+- S3
 - Tiered storage (SSD caching)
 - NVDIMM support
 - Compression (possibly)

docs/intro/features.ru.md

@@ -14,8 +14,6 @@
 
 - Базовая часть - надёжное кластерное блочное хранилище без единой точки отказа
 - [Производительность](../performance/bench2.ru.md) ;-D
-  - [Поддержка атомарной записи NVMe](../config/osd.ru.md#atomic_write_size) для снижения объёма
-    служебной записи практически до нуля (Write Amplification = 1)
 - [Несколько схем отказоустойчивости](../config/pool.ru.md#scheme): репликация, XOR n+1 (1 диск чётности), коды коррекции ошибок
   Рида-Соломона на основе библиотек jerasure и ISA-L с любым числом дисков данных и чётности в группе
 - Конфигурация через простые человекочитаемые JSON-структуры в etcd
@@ -27,13 +25,12 @@
 - Восстановление деградированных блоков
 - Ребаланс, то есть перемещение данных между OSD (дисками)
 - [Поддержка "ленивого" fsync (fsync не на каждую операцию)](../config/layout-cluster.ru.md#immediate_commit)
-- [Локальные чтения](../config/pool.ru.md#local_reads) для оптимизации при нескольких датацентрах
 - Сбор статистики ввода/вывода в etcd
 - Статистика операций ввода/вывода и занятого места в разрезе инодов
 - Именование инодов через хранение их метаданных в etcd
 - Снапшоты и copy-on-write клоны
 - [Сглаживание производительности случайной записи в SSD+HDD конфигурациях](../config/osd.ru.md#throttle_small_writes)
-- Поддержка RDMA/RoCEv2 [через libibverbs](../config/network.ru.md#use_rdma) или [RDMA-CM](../config/network.ru.md#use_rdmacm)
+- [Поддержка 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)
@@ -42,9 +39,6 @@
 - [Экспериментальная встроенная замена etcd - antietcd](../config/monitor.ru.md#use_antietcd)
 - [Встроенный Prometheus-экспортер метрик](../config/monitor.ru.md#enable_prometheus)
 - [Поддержка NFS RDMA](../usage/nfs.ru.md#rdma) (вероятно, также подходящая для GPUDirect)
-- [S3](../installation/s3.ru.md)
-- [Полное транспортное шифрование и контроль доступа](../usage/security.ru.md)
-- [AES-256-XTS сквозное шифрование данных](../usage/security.ru.md#сквозное-шифрование-данных-образов-aes-xts) с [поддержкой Vault](../usage/security.ru.md#настройка-vaultopenbao) для хранения ключей
 
 ## Драйверы и инструменты
 
@@ -58,7 +52,7 @@
 - Общая пользовательская клиентская библиотека для работы с кластером
 - [Драйвер диска для QEMU](../usage/qemu.ru.md)
 - [Драйвер диска для утилиты тестирования производительности fio](../usage/fio.ru.md)
-- [UBLK](../usage/ublk.ru.md) и [NBD](../usage/nbd.ru.md) серверы для монтирования образов ядром ("блочное устройство в режиме пользователя")
+- [NBD-прокси для монтирования образов ядром](../usage/nbd.ru.md) ("блочное устройство в режиме пользователя")
 - [Упрощённая NFS-прокси для эмуляции файлового доступа к образам (подходит для VMWare)](../usage/nfs.ru.md#псевдо-фс)
 
 ## Планы развития
@@ -69,6 +63,7 @@
 - iSCSI и NVMeoF прокси
 - Многопоточный клиент
 - Более быстрое переключение при отказах
+- S3
 - Поддержка SSD-кэширования (tiered storage)
 - Поддержка NVDIMM
 - Возможно, сжатие

docs/intro/quickstart.en.md

@@ -18,10 +18,9 @@
 
 ## Preparation
 
-- Get some SATA or NVMe SSDs with capacitors (server-grade drives). The best performance
-  is achieved with Micron or Kioxia NVMes with atomic write support (see below). 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).
+- Get some SATA or NVMe SSDs with capacitors (server-grade drives). You can use desktop SSDs
+  with lazy fsync, but prepare for inferior single-thread latency. Read more about capacitors
+  [here](../config/layout-cluster.en.md#immediate_commit).
 - If you want to use HDDs, get modern HDDs with Media Cache or SSD Cache: HGST Ultrastar,
   Toshiba MG, Seagate EXOS or something similar. If your drives don't have such cache then
   you also need small SSDs for journal and metadata (even 2 GB per 1 TB of HDD space is enough).
@@ -31,33 +30,27 @@
 
 ## Recommended drives
 
-- NVMe with atomic write support (ideal!): Micron 7450/7500/7550, Kioxia CD6/CD7/CD8/CD9
-- Other NVMe: Micron 9100/9200/9300/9400/9550, Micron 7300, Samsung PM983/PM9A3, Samsung PM1723/1735/1743,
-  Intel DC-P3700/P4500/P4600, Intel/Solidigm D5-P4320/P5530, Intel/Solidigm D7-P5500/P5600, Solidigm D7-PS1010/PS1030/P5810,
-  Intel Optane, Kingston DC1000B/DC1500M, Kioxia CD6/CD7/CD8/CD9
-- SATA SSD: Micron 5100/5200/5300/5400, Samsung PM863/PM883/PM893, Intel/Solidigm D3-S4510/4520/4610/4620, Kingston DC500M
+- SATA SSD: Micron 5100/5200/5300/5400, Samsung PM863/PM883/PM893, Intel D3-S4510/4520/4610/4620, Kingston DC500M
+- NVMe: Micron 9100/9200/9300/9400, Micron 7300/7450, Samsung PM983/PM9A3, Samsung PM1723/1735/1743,
+  Intel DC-P3700/P4500/P4600, Intel D5-P4320/P5530, Intel D7-P5500/P5600, Intel Optane, Kingston DC1000B/DC1500M
 - HDD: HGST Ultrastar, Toshiba MG, Seagate EXOS
 
 ## Configure monitors
 
 On the monitor hosts:
-- Create minimal configuration in `/etc/vitastor/vitastor.conf`:
+- Put identical etcd_address into `/etc/vitastor/vitastor.conf`. Example:
   ```
   {
-    "etcd_address": ["http://10.200.1.10:2379","http://10.200.1.11:2379","http://10.200.1.12:2379"],
-    "osd_network": "10.200.1.0/24",
-    "use_perms": false
+    "etcd_address": ["10.200.1.10:2379","10.200.1.11:2379","10.200.1.12:2379"]
   }
   ```
-- Note that you can enable encryption by using `https://` and `use_perms` option.
-  [Details](security.en.md#quick-setup) about encryption setup with make-etcd.
 - Create systemd units for etcd by running: `/usr/lib/vitastor/mon/make-etcd`
   Or, if you installed Vitastor in Docker, run `systemctl start vitastor-host; docker exec vitastor make-etcd`.
 - Start etcd and monitors: `systemctl enable --now vitastor-etcd vitastor-mon`
 
 ## Configure OSDs
 
-- Put etcd_address and [osd_network](../config/network.en.md#osd_network) into `/etc/vitastor/vitastor.conf`. Example:
+- Put etcd_address and osd_network into `/etc/vitastor/vitastor.conf`. Example:
   ```
   {
     "etcd_address": ["10.200.1.10:2379","10.200.1.11:2379","10.200.1.12:2379"],

docs/intro/quickstart.ru.md

@@ -18,9 +18,8 @@
 
 ## Подготовка
 
-- Возьмите серверы с SSD (SATA или NVMe), желательно с конденсаторами (серверные SSD). Наилучшая
-  производительность достигается на дисках Micron и Kioxia с поддержкой атомарной записи (см. ниже).
-  Можно использовать и десктопные SSD, включив режим отложенного fsync, но производительность будет хуже.
+- Возьмите серверы с SSD (SATA или NVMe), желательно с конденсаторами (серверные SSD). Можно
+  использовать и десктопные SSD, включив режим отложенного fsync, но производительность будет хуже.
   О конденсаторах читайте [здесь](../config/layout-cluster.ru.md#immediate_commit).
 - Если хотите использовать HDD, берите современные модели с Media или SSD кэшем - HGST Ultrastar,
   Toshiba MG, Seagate EXOS или что-то похожее. Если такого кэша у ваших дисков нет,
@@ -31,33 +30,33 @@
 
 ## Рекомендуемые диски
 
-- NVMe с поддержкой атомарной записи (идеально!): Micron 7450/7500/7550, Kioxia CD6/CD7/CD8/CD9
-- Другие NVMe: Micron 9100/9200/9300/9400/9550, Micron 7300, Samsung PM983/PM9A3, Samsung PM1723/1735/1743,
-  Intel DC-P3700/P4500/P4600, Intel/Solidigm D5-P4320/P5530, Intel/Solidigm D7-P5500/P5600, Solidigm D7-PS1010/PS1030/P5810,
-  Intel Optane, Kingston DC1000B/DC1500M, Kioxia CD6/CD7/CD8/CD9
-- SATA SSD: Micron 5100/5200/5300/5400, Samsung PM863/PM883/PM893, Intel/Solidigm D3-S4510/4520/4610/4620, Kingston DC500M
+- SATA SSD: Micron 5100/5200/5300/5400, Samsung PM863/PM883/PM893, Intel D3-S4510/4520/4610/4620, Kingston DC500M
+- NVMe: Micron 9100/9200/9300/9400, Micron 7300/7450, Samsung PM983/PM9A3, Samsung PM1723/1735/1743,
+  Intel DC-P3700/P4500/P4600, Intel D5-P4320/P5530, Intel D7-P5500/P5600, Intel Optane, Kingston DC1000B/DC1500M
 - HDD: HGST Ultrastar, Toshiba MG, Seagate EXOS
 
 ## Настройте мониторы
 
 На хостах, выделенных под мониторы:
-- Создайте минимальную конфигурацию в `/etc/vitastor/vitastor.conf`:
+- Пропишите одинаковые etcd_address в `/etc/vitastor/vitastor.conf`. Например:
   ```
   {
-    "etcd_address": ["http://10.200.1.10:2379","http://10.200.1.11:2379","http://10.200.1.12:2379"],
-    "osd_network": "10.200.1.0/24",
-    "use_perms": false
+    "etcd_address": ["10.200.1.10:2379","10.200.1.11:2379","10.200.1.12:2379"]
   }
   ```
-- Обратите внимание, что с помощью схемы `https://` и опции `use_perms` можно включить шифрование.
-  [Подробно](security.ru.md#быстрая-настройка) о настройке шифрования через make-etcd.
 - Инициализируйте сервисы etcd, запустив `/usr/lib/vitastor/mon/make-etcd`.\
   Либо, если вы установили Vitastor в Docker, запустите `systemctl start vitastor-host; docker exec vitastor make-etcd`.
 - Запустите etcd и мониторы: `systemctl enable --now vitastor-etcd vitastor-mon`
 
 ## Настройте OSD
 
-- Создайте/скопируйте с узлов с мониторами файл конфигурации `/etc/vitastor/vitastor.conf`.
+- Пропишите etcd_address и osd_network в `/etc/vitastor/vitastor.conf`. Например:
+  ```
+  {
+    "etcd_address": ["10.200.1.10:2379","10.200.1.11:2379","10.200.1.12:2379"],
+    "osd_network": "10.200.1.0/24"
+  }
+  ```
 - Инициализуйте OSD:
   - Только SSD или только HDD: `vitastor-disk prepare /dev/sdXXX [/dev/sdYYY ...]`.
     Если вы используете десктопные SSD без конденсаторов, добавьте опцию `--disable_data_fsync off`,

docs/performance/theoretical.en.md

@@ -14,7 +14,7 @@ Replicated setups:
 - Linear read: `min(total network bandwidth, sum(disk read MB/s))`.
 - Linear write: `min(total network bandwidth, sum(disk write MB/s / number of replicas))`.
 - 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))`.
+- 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):
 - Single-threaded (T1Q1) read latency: 1.5 network roundtrips + 1 disk read.
@@ -26,36 +26,28 @@ EC/XOR setups (EC N+K):
 - Linear read: `min(total network bandwidth, sum(disk read MB/s))`.
 - Linear write: `min(total network bandwidth, sum(disk write MB/s * N/(N+K)))`.
 - Saturated parallel read iops: `min(total network bandwidth, sum(disk read iops))`.
-- Saturated parallel write iops: roughly `total iops / (N+K) / WA`. More exactly:
-  - With the new store: `min(total network bandwidth * N/(N+K), sum(disk randrw iops / (2 + N-1 + K*2)))`,
-    with random read/write mix corresponding to `(N-1)/(2 + N-1 + K*2)*100 % reads`.
-    - For example, with EC 2+1 it is: `(20% randrw iops) / 5`.
-    - With EC 6+3 it is: `(38% randrw iops) / 13`.
-  - With the old store: `min(total network bandwidth * N/(N+K), sum(disk randrw iops / (3 + N-1 + K*3)))`,
-    with random read/write mix corresponding to `(N-1)/(3 + N-1 + K*3)*100 % reads`.
-    - For example, with EC 2+1 it is: `(14% randrw iops) / 7`.
-    - With EC 6+3 it is: `(30% randrw iops) / 17`.
+- 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 factor:
-- For the new store and for 4 KB writes: WA is always 1 unless you set [atomic_write_size](../config/osd.en.md#atomic_write_size) to 0 manually.
-- For the new store and for 8-124 KB writes: WA is 1 if you use NVMe drives with atomic write support, or roughly 2 if you use other drives.
-- For the old store, WA is roughly `(2 * write size + 4 KB) / (write size)`. So, for 4 KB writes it's 3, and for 8-124 KB writes it's closer to 2.
-- For both the new and the old store and for writes of [block_size](../config/layout-cluster.en.md#block_size): WA is almost 1.
+Write amplification for 4 KB blocks is usually 3-5 in Vitastor:
+1. Journal block write
+2. Journal data write
+3. Metadata block write
+4. Another journal block write for EC/XOR setups
+5. Data block write
 
-Write Amplification consists of:
-- For the new store:
-  - Buffer block write if non-atomic
-  - Data block write
-  - Metadata write(s) (amortized)
-- For the old store:
-  - Journal block write (amortized)
-  - Journal data write
-  - Metadata block write
-  - Another journal block write for EC/XOR setups (amortized)
-  - Data block write
+If you manage to get an SSD which handles 512 byte blocks well (Optane?) you may
+lower 1, 3 and 4 to 512 bytes (1/8 of data size) and get WA as low as 2.375.
 
-Other possibilities to reduce WA would be to use SSDs with internal 512-byte blocks
-or NVDIMM, but both options seem unavailable on the market at the moment.
+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
 

docs/performance/theoretical.ru.md

@@ -27,36 +27,29 @@
 - Линейное чтение: сумма МБ/с чтения всех дисков, либо общая производительность сети, если в сеть упрётся раньше.
 - Линейная запись: сумма МБ/с записи всех дисков * N/(N+K), либо производительность сети * N / (N+K), если в сеть упрётся раньше.
 - Параллельное случайное мелкое чтение: сумма IOPS чтения всех дисков либо производительность сети, если в сеть упрётся раньше.
-- Параллельная случайная мелкая запись: грубо `(сумма IOPS / (N+K) / WA)`.
-  Либо `производительность сети * N/(N+K)`, если в сеть упрётся раньше. Если точнее, то:
-  - С новым хранилищем: сумма смешанного IOPS всех дисков при `(N-1)/(2 + N-1 + K*2)*100 %` чтения, делённая на `(2 + N-1 + K*2)`.
-    - Например, при EC 2+1 это: `(сумма IOPS при 20% чтения) / 5`.
-    - При EC 6+3 это: `(сумма IOPS при 38% чтения) / 13`.
-  - Со старым хранилищем: сумма смешанного IOPS всех дисков при `(N-1)/(3 + N-1 + K*3)*100 %` чтения, делённая на `(3 + N-1 + K*3)`.
-    - Например, при EC 2+1 это: `(сумма IOPS при 14% чтения) / 7`.
-    - При EC 6+3 это: `(сумма IOPS при 30% чтения) / 17`.
+- Параллельная случайная мелкая запись: грубо `(сумма 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 (Write Amplification, мультипликатор записи):
-- С новым хранилищем для 4 КБ записи: WA всегда примерно 1, если только вы не установите [atomic_write_size](../config/osd.ru.md#atomic_write_size) вручную в 0.
-- С новым хранилищем и большими записями (8-124 КБ): WA примерно 1, если вы используете NVMe-диски с поддержкой атомарной записи,
-  или примерно 2, если вы используете другие диски.
-- Со старым хранилищем, WA примерно `(2 * размер записи + 4 КБ) / (размер записи)`. То есть, для 4 КБ записи WA=3, а для 8-124 КБ WA ближе к 2.
-- И с новым, и со старым хранилищем и для записи размером [block_size](../config/layout-cluster.ru.md#block_size): WA примерно равен 1.
+WA (мультипликатор записи) для 4 КБ блоков в Vitastor обычно составляет 3-5:
+1. Запись метаданных в журнал
+2. Запись блока данных в журнал
+3. Запись метаданных в БД
+4. Ещё одна запись метаданных в журнал при использовании EC
+5. Запись блока данных на диск данных
 
-Мультипликатор записи состоит из:
-- С новым хранилищем:
-  - Запись блока буфера, если диски без поддержки атомарной записи
-  - Запись блока данных
-  - Запись(-и) блоков метаданных (амортизированные)
-- Со старым хранилищем:
-  - Запись блока журнала (амортизированная)
-  - Запись данных в журнал
-  - Запись блока метаданных
-  - Ещё одна запись блока журнала для EC/XOR пулов (амортизированная)
-  - Запись блока данных
+Если вы найдёте SSD, хорошо работающий с 512-байтными блоками данных (Optane?),
+то 1, 3 и 4 можно снизить до 512 байт (1/8 от размера данных) и получить WA всего 2.375.
 
-Другими потенциальными возможностями снижения WA могли бы быть SSD с внутренним 512-байтным блоком
-либо NVDIMM, но и то, и другое сейчас выглядит недоступным на рынке.
+Если реализовать поддержку NVDIMM, то WA можно, условно говоря, ликвидировать вообще - все
+дополнительные операции записи смогут обслуживаться DRAM памятью. Но для этого необходим
+тестовый кластер с NVDIMM - пишите, если готовы предоставить такой для тестов.
+
+Кроме того, WA снижается при использовании отложенного/ленивого сброса при параллельной
+нагрузке, т.к. блоки журнала записываются на диск только когда они заполняются или явным
+образом запрашивается fsync.
 
 ## На практике
 

docs/tests/pg-chaos.en.md

@@ -1,220 +0,0 @@
-[Documentation](../../README.md#documentation) → Tests → The PG chaos-test model
-
------
-
-[Читать на русском](pg-chaos.ru.md)
-
-# The PG chaos-test model
-
-A seed-driven stress test of the PG machinery (`src/test/test_pg_chaos.cpp`): ONE
-real `osd_t` (the primary) with a real blockstore over a mock disk (entirely in
-RAM, `ringloop_mock`) owns a single PG (number 1, pool 1, four 128 K objects, 4 K
-granularity). The other PG members are fake secondary OSDs inside the test. The
-pool is either replicated x3 (members 2,3, spare 4) or EC 2+2 (members 2..4,
-spare 5, one object = one parity stripe). The seed uniquely determines the
-configuration and the whole event sequence; a failing run is reproduced with
-the same `--seed`.
-
-What it mainly verifies is the PG machinery (the subop fan-out,
-peering/LIST/rollback/stabilize, repeer daemons, stop_pg, INCOMPLETE, recovery) and
-partly the primary OSD's storage; checking the storage is not the test's main goal -
-test_blockstore_chaos covers it.
-
-## Configurations (10)
-
-- replicated/EC ×
-- immediate_commit none/all ×
-- csum_block none/4096/16384
-
-`--recovery` enables recovery/rebalance after a set change (off by default so that
-degraded states get exercised).
-
-## The world model
-
-Each object has an ordered version history; a version enters the model at SUBMIT
-time (the delta = the request's exact bytes/length/granule bitmap), with a state:
-- `V_SUBMITTED` - the op was sent and has no answer yet (in flight). It behaves
-  like V_OPTIONAL in every respect but one: concurrent reads are entitled not to
-  show this write's result, and that must not mark the version DEAD.
-- `V_OPTIONAL` - the write was sent but not acknowledged: it either applied (then
-  as a whole) or did not apply at all. Versions reach this state from V_SUBMITTED
-  and, in the explicit-fsync modes, from V_ACKED when the client session dies
-  before a SYNC request (that counts as a marker that the write is unacknowledged).
-  Observing an OPTIONAL write's effect in a later read restores it to ACKED;
-  observing its absence (not visible over its own range) makes it DEAD.
-- `V_ACKED` - the write was acknowledged; the model records `ack_live` (the live set
-  at ack time - used to check that the failure model wasn't exceeded). With
-  immediate_commit=all it is immediately considered on-disk durable. An ACKED write
-  must not roll back while the client's session is alive.
-- `V_SYNCED` - acknowledged and SYNCed: durable on disk, and it may never roll back
-  again at all.
-- `V_PARTIAL` - deleted, but possibly not from every OSD (the PG stayed LEFT_ON_DEAD).
-- `V_DEAD` - the version was either definitely refused (-EAGAIN, possibly -ENOSPC in
-  the future), or it was OPTIONAL and it later became certain that it was refused
-  because a subsequent read did NOT observe it. A DEAD version showing again fails
-  the test.
-
-Object contents are self-identifying: the pattern encodes the object, the version and
-the offset, so a read result decodes back into "which version wrote these bytes".
-
-Verification reads ONLY through the primary OSD and checks that the answer is
-explained by a merge of ONE consistent subset of the written versions, where every
-durable version is definitely present, every refused one is definitely absent, and
-the contents never lie about their authorship. With an incomplete deletion, EC may
-legitimately answer INCOMPLETE, and replicated pools may resurrect the object.
-
-Everything derives from version states and events, with no extra flags: an ACKED
-version cannot vanish except through an event that first breaks the session's
-guarantee - a crash (taking the session down with the process) or a
-repeer/stop_pg (which stop dirty sessions BEFORE peering starts).
-
-The test's checks look ONLY at what the write path exposes to the client; the model
-deliberately ignores things the client cannot know about, such as paired OSD
-deaths per se.
-
-## The simulated reality
-
-- **Disk simulator**: requests carry delays; `power_loss()` = power outage -
-  uncommitted writes are lost, committed ones survive. An unknown FD/opcode aborts
-  the test (a stub guard).
-- **etcd simulator**: keys/values + leases; revoke/TTL are emulated on a crash (the
-  OSD's keys are removed, its lease revoked).
-- **Peer OSD simulator**: answers per the secondary-OSD/blockstore contract -
-  read/write/delete, SYNC, LIST. When a peer OSD dies, non-SYNCed writes die with it
-  with probability `peer_cache_loss`% (default 50 - modelling a volatile disk cache);
-  SYNCed ones always survive. A peer crash by itself does NOT change the world model:
-  the model only knows what the client sees. The crash repeers the PG, the repeer
-  kills dirty client sessions (volatile ACKED writes are exactly what makes a client
-  dirty), the session dies - and THAT is what the client observes
-  (PEER_STOPPED/EPIPE), and only session_died() demotes. If a crash rolled something
-  back under a live session, that would be a rollback invisible to the client -
-  check 5 catches it.
-- **Network simulator**: service_peers runs every round. The request-phase delay:
-  a random `--p-wire`% (default 70) of each peer's queued subops gets applied; the
-  response-phase delay: a random `p_reply`% of the already-applied replies gets
-  delivered. A reply belongs to its connection: the connection died - undelivered
-  replies die with `-EPIPE` (the apply stays). When an OSD instance dies, however,
-  mutating ops still in `sent_ops` are copied into a separate "wire" queue; they are
-  applied later at the `--p-wire` rate WITHOUT an answer (the connection fell).
-  Non-mutating ops (READ/LIST) are dropped (nobody left to answer), and the harvested
-  queue is capped at 64 entries.
-
-## Operations (one per step)
-
-Each step picks an action by weight (`--p-*`; 0 disables it):
-
-- **wait (500)** - send nothing, just run the simulation (event windows).
-- **write (60)** - write a random range of a random object; bump the version; the
-  delta is remembered as OPTIONAL; at most max_inflight (8) in flight.
-- **delete (6)** - delete a random object; the version is remembered as OPTIONAL with
-  zero length (a full delete); LEFT_ON_DEAD/ack are tracked in account().
-- **read (40)** - read an object: whole with probability `full_read`%, otherwise an
-  arbitrary range; a whole read verifies the object.
-- **sync (30)** - flush the cache (fsync); on confirmation the versions are marked
-  SYNCED (durable).
-- **restart (1)** - a CLEAN OSD restart: drain the queue (all inflight finish), wait
-  for the disk to go idle, destroy, recreate, wait for the OSD to come up, then,
-  with `--p-post` (50%) chance, read and verify all object contents ("a clean restart
-  that lost nothing").
-- **takeover (1)** - a PG handover: first stop the PG by pointing the primary at a
-  fake member in the etcd stub -> stop_pg stops the PG; right after the
-  `/pg/state/1/1` key disappears (meaning the OSD released the PG) -> recreate the OSD
-  and point the primary back at it -> re-verify the objects as in restart.
-- **crash (2)** - the primary OSD crashes: a disk power loss (un-synced writes lost),
-  lease cancel + removal of the OSD's keys without cancelling the ops in flight to
-  peer OSDs, a new instance starts, objects re-verified.
-- **peer_down (3)** - a peer OSD crashes: a victim is chosen that breaks no object's
-  quorum (all latest OPTIONAL versions down to the first SYNCED are checked), the peer
-  OSD stops and its connection drops.
-- **peer_up (3)** - a peer OSD comes back (connects - if the PG or its history still
-  involves it); then settle(): wait for the PG to come up (ACTIVE|INCOMPLETE +
-  quiescence), then run recover_pending - deferred checks of objects whose chains may
-  have re-settled.
-- **set_change (1)** - the PG moves to another OSD set through etcd; with
-  `--recovery` - recovery reads; without it, degradation is legal and the
-  "surviving copies" world is protected by the checks.
-
-At the end - wait for completion: clean up until "the PG is healthy and every op has
-finished", at most MAX_STEPS=1e6 steps -> exceeding that aborts with a "did not
-settle" error.
-
-## Op outcome accounting (account)
-
-- Completed with the expected retval -> V_ACKED. A delete without LEFT_ON_DEAD closes
-  the partial-deletion window. A delete with LEFT_ON_DEAD must be repeated after the
-  peers come back, and in EC it allows a future INCOMPLETE unless the object is
-  rewritten in the meantime.
-- Completed with EAGAIN -> V_DEAD: the version was definitely not applied; currently
-  unreachable in the test, kept as a placeholder for the future - it would also apply
-  to e.g. ENOSPC.
-- Completed with EPIPE -> the version stays OPTIONAL: a refusal is not an ack, but the
-  op may have applied (or not). An optional delete must also be repeated after the
-  peers come back and likewise allows EC INCOMPLETE until the next rewrite.
-- Completed with any other error -> the test aborts ("failed with retval").
-
-## Checks (every abort point)
-
-**Data consistency (world_check):**
-1. world_check - the answer must be explained by a subset of the versions: every
-   required (durable) one is present; bytes are answered by exactly their own version
-   ("record obj/seq/off mismatch", a bitmap granule "carries data from wrong
-   version").
-2. "shows %s but the highest..." - an old version of the object was read while later
-   writes are lost (monotonicity broken).
-3. "read shows seq over acked v's granule" - a granule's contents (obj/seq/off in the
-   record) contradict the version that owns the granule in the model: stitched or
-   torn contents instead of the acknowledged bytes.
-4. "DEAD version showed again" - refused versions must not come back.
-5. "committed version read fully absent over floor" / "established version read
-   absent over its granule" - acknowledged ops must not disappear.
-6. A read -EIO "OSD deems unrecoverable" is legal in exactly one window: an
-   unfinished EC deletion. Outside it, -EIO aborts the test - including a "clean" ack
-   delete + INCOMPLETE after a revival (the OSD lied about completeness) and a chain
-   rollback under a live session with no deletion window; any other retval != len
-   aborts the test.
-7. bitmap_len != the expected read answer length -> abort the test.
-8. "came back INCOMPLETE" after set_change/crash - same criterion: an unfinished
-   deletion window makes INCOMPLETE legal and the deletion is repeated; anything
-   else aborts the test.
-9. "came back ... which no world of the recorded versions explains" - the final
-   check of object contents after the test settles.
-10. "changed across a clean restart that lost nothing" - object immutability across
-    a clean restart.
-
-**Liveness/timing:**
-
-11. "did not settle in MAX_STEPS" - the ops never completed within a huge step count
-    (a possible self-deadlock);
-12. "operations did not complete" - stuck ops, printed in the dump; "a read of
-    object N did not complete in MAX_STEPS ... deadlock?"; "OSD did not load PGs
-    from etcd in MAX_STEPS" / "OSD did not finish peering in MAX_STEPS" - start-up
-    checks.
-13. "did not release the PG" - the OSD didn't give the PG up when commanded;
-14. "disk did not go idle" - a use-after-free guard: every disk op must finish
-    before the OSD is destroyed;
-15. "PG did not become healthy after reviving every peer" - the PG stayed down after
-    all its OSDs came back;
-16. "pending recovery/repeated deletion could not complete on a healthy PG" - a
-    deletion/recovery that never finished on a live PG.
-
-**Test-stub guards:**
-
-17. An unexpected SQE (fd/opcode) on the disk stub; "unexpected secondary opcode" on
-    a peer; arguments like `--p-reply >= 1`, `--max-inflight >= 1`, etc.
-
-**Coverage checks:**
-
-18. `peer_cache_loss<100` + a volatile config + >=8 peer deaths -> verify that the
-    variant where a peer OSD kept its journal ran at least once.
-19. >=10 dirty OSD deaths/PG handovers -> wire_harvested > 0: at least one op of the
-    primary OSD that was in flight must have been harvested into the "wire" on the
-    way down - the "delivery from a dead OSD" path was exercised.
-
-## Reporting and reproducibility
-
-The OK line: writes(refused)/deletes/syncs/crashes/restarts/takeovers/peer
-deaths(kept journal)/recoveries/set changes/verified reads/stragglers
-(applied/captured/lost)/disk ops.
-
-Determinism: one seed -> the same configuration and the same schedule; `-v` traces
-disk and peer-OSD operations, op harvesting on peer deaths, and etcd changes.

docs/tests/pg-chaos.ru.md

@@ -1,197 +0,0 @@
-[Документация](../../README-ru.md#документация) → Тесты → Модель хаос-теста PG (`src/test/test_pg_chaos.cpp`)
-
------
-
-[Read in English](pg-chaos.en.md)
-
-# Модель хаос-теста PG
-
-Seed-driven стресс-тест PG-машинерии (`src/test/test_pg_chaos.cpp`): ОДИН настоящий
-`osd_t` (primary) с настоящим хранилищем на заглушке диска (полностью в RAM, `ringloop_mock`)
-владеет одной PG (номер 1, пул 1, объекты — 4 шт по 128 К, гранула 4 К). Остальные члены PG —
-фейковые вторичные OSD внутри теста. PG: реплицированная x3 (members 2,3, spare 4) или
-EC 2+2 (members 2..4, spare 5, объект = один parity-stripe). Сид однозначно задаёт
-конфигурацию и всю последовательность событий; упавший прогон воспроизводится тем же `--seed`.
-
-Проверяется в первую очередь PG-машинерия (subop-веер, peering/LIST/rollback/stabilize, repeer-демоны,
-stop_pg, INCOMPLETE, recovery) и частично хранилище первичного OSD; однако, проверка хранилища —
-не главная цель теста, его покрывает test_blockstore_chaos.
-
-## Конфигурации (10)
-
-- replicated/EC ×
-- immediate_commit none/all ×
-- csum_block нет/4096/16384
-
-`--recovery` включает recovery/rebalance после set-change (по умолчанию выкл, чтобы
-гонять degraded-состояния).
-
-## Модель мира
-
-Для каждого объекта — упорядоченная история версий; версия пишется в модель в момент
-SUBMIT (дельта = точные байты/длина/битмап гранул запроса), состояние:
-- `V_SUBMITTED` — операция отправлена, ответа ещё нет (выполняется). Ведёт себя как
-  V_OPTIONAL во всём, кроме одного: параллельные чтения вправе не показывать результат
-  этой записи, и это не будет маркировать её DEAD.
-- `V_OPTIONAL` — запись отправлена, но не подтверждена, и может быть либо применена
-  (но тогда целиком), либо не применена вообще. Версии попадают в это состояние из
-  V_SUBMITTED и, в режимах с явными fsync, V_ACKED при гибели клиентской сессии до
-  запроса SYNC (это считается маркером, что запись не подтверждена).
-  Наблюдение эффекта OPTIONAL записи в последующем чтении восстанавливает её в ACKED;
-  наблюдение её отсутствия (когда она не видна в своём диапазоне) ⇒ DEAD.
-- `V_ACKED` — запись подтверждена; запоминается `ack_live` (живой набор на момент ack —
-  используется для проверки превышения модели отказов). При immediate_commit=all сразу
-  считается зафиксированной на диске. ACKED запись не должна откатываться, пока сессия
-  клиента жива.
-- `V_SYNCED` — подтверждена и SYNC-нута ⇒ зафиксирована на диске и более не должна
-  откатываться вообще.
-- `V_PARTIAL` — удалена, но, возможно, не со всех OSD (PG осталась в LEFT_ON_DEAD).
-- `V_DEAD` — версия либо точно отказана (-EAGAIN, возможно -ENOSPC в будущем), либо
-  была OPTIONAL, но после этого стало точно известно, что она откачена, так как последующее
-  чтение её уже НЕ наблюдало. Повторное появление DEAD-версии — провал теста.
-
-Содержимое объектов самоидентифицируется версией: паттерн кодирует объект, версию и смещение —
-прочитанное можно декодировать обратно в «какая версия записала эти байты».
-
-Верификация читает ТОЛЬКО через первичный OSD и проверяет, что ответ объясняется слиянием
-ОДНОГО согласованного подмножества записанных версий, где все зафиксированные точно присутствуют,
-все откаченные точно отсутствуют, а содержимое не врёт об авторстве. При неполном удалении
-разрешается INCOMPLETE в EC, а в репликах допускается воскрешение объекта.
-
-Всё выводится из состояний версий и событий, без дополнительных флагов: ACKED не может
-исчезнуть, кроме как через событие, которое сначала ломает гарантию сессии — краш (уносит
-сессию вместе с процессом) или repeer/stop_pg (останавливают dirty-сессии ДО начала пиринга).
-
-Проверки в тесте смотрят ТОЛЬКО на то, как процесс записи видит клиент, и не учитывают
-в модели, например, падения парных OSD сами по себе, так как клиент не может о них знать.
-
-## Симулируемая реальность
-
-- **Симулятор диска**: запросы с задержками; `power_loss()` = потеря питания — незафиксированные
-  записи теряются, зафиксированные остаются. Неизвестный FD/opcode → падение теста (защита заглушки).
-- **Симулятор etcd**: ключ/значение + lease; revoke/TTL эмулируются при крахе (ключи OSD'а
-  удаляются, lease отзывается).
-- **Симулятор парных OSD**: отвечает в соответствии с контрактом вторичного OSD / blockstore.
-  Чтение/запись/удаление, SYNC, LIST. При падении парного OSD не-SYNC-нутые записи гибнут
-  с вероятностью `peer_cache_loss`% (по умолчанию 50 — моделирует волатильный кэш диска),
-  SYNC-нутые выживают всегда. Модель мира на краш пира сама НЕ реагирует: она знает
-  только то, что видит клиент. Краш реперит PG, репер убивает dirty-сессии клиентов
-  (volatile ACKED — это и есть dirty-клиент), сессия гибнет — вот это клиент наблюдает
-  (PEER_STOPPED/EPIPE), и только session_died() делает demote. Если краш откатит
-  что-то при живой сессии — это ненаблюдаемый клиентом откат, проверка 5 его ловит.
-- **Симулятор сети**: service_peers, каждый раунд. Задержка на этапе запроса — применяются случайные
-  `--p-wire`% (по умолчанию 70) очередей subop'ов пира; задержка на этапе ответа — доставляются
-  случайные `p_reply`% применённых ответов. Ответ принадлежит соединению: соединение
-  умерло — недоставленные ответы гибнут с `-EPIPE` (применение остаётся). Однако, при
-  гибели экземпляра OSD мутирующие операции в `sent_ops` копируются в отдельную очередь
-  «сети»; применяются позже (`--p-wire`%) БЕЗ ответа (соединение упало). Немутирующие
-  операции (READ/LIST) отбрасываются (отвечать некому), очередь собранных операций
-  ограничивается 64.
-
-## Операции (step)
-
-На каждом шаге (веса `--p-*`; 0 выключает действие):
-
-- **wait (500)** — ничего не слать, прокрутить симуляцию (событийные окна).
-- **write (60)** — запись случайного диапазона случайного объекта; увеличение версии;
-  дельта запоминается как OPTIONAL; ≤ max_inflight (8) одновременно.
-- **delete (6)** — удаление случайного объекта; версия запоминается как OPTIONAL с
-  нулевой длиной (полное удаление); LEFT_ON_DEAD/ack отслеживаются в account().
-- **read (40)** — чтение объекта, полное с вероятностью `full_read`%, иначе произвольный
-  диапазон; при полном чтении объект проверяется.
-- **sync (30)** — синхронизация кэша (fsync); при подтверждении версии помечаются SYNCED
-  (зафиксированными).
-- **restart (1)** — ЧИСТАЯ перезагрузка OSD: очистка очереди (все inflight закончены), ожидание
-  простоя диска, уничтожение, пересоздание, ожидание подъёма OSD и, с шансом `--p-post`,
-  чтение и проверка содержимого всех объектов («чистый перезапуск, который ничего не потерял»).
-- **takeover (1)** — передача PG: сначала остановка PG через смену первичного OSD на
-  фейковый в заглушке etcd → stop_pg останавливает PG; далее сразу после удаления ключа
-  `/pg/state/1/1` (означающего, что OSD остановил PG) → пересоздание OSD и его переустановка
-  в качестве первичного → перепроверка объектов, как в restart.
-- **crash (2)** — падение первичного OSD: потеря питания диска (потеря не-синкнутых записей),
-  отмена лизы + удаление ключей OSD без отмены операций в полёте к парным OSD, запуск нового
-  экземпляра, перепроверка объектов.
-- **peer_down (3)** — крах парного OSD: выбирается жертва, не ломающая кворум ни
-  одного объекта (проверяются все последние OPTIONAL версии до первой SYNCED), парный OSD
-  останавливается, соединение с ним разрывается.
-- **peer_up (3)** — подъём парного OSD (соединение — если PG или её история его ещё
-  касается); после — settle(): ждать подъёма PG (ACTIVE|INCOMPLETE + покой), затем
-  прогнать recover_pending — отложенные проверки объектов, чьи цепи могли перегласоваться.
-- **set_change (1)** — переезд PG на другой OSD-набор через etcd; с `--recovery` —
-  восстановительные чтения; без — деградация легальна, мир «выживших копий» защищён
-  проверками.
-
-В конце — ожидание завершения: очистка до «PG в порядке и все операции завершены», максимум
-до MAX_STEPS=1e6 шагов → если превышается, то падение с ошибкой «did not settle».
-
-## Учёт результатов операций (account)
-
-- Завершена с ожидаемым кодом возврата → V_ACKED. Удаление без LEFT_ON_DEAD закрывает
-  окно частичного удаления. Удаление с LEFT_ON_DEAD требует повтора после подъёма
-  пиров, а с EC допускает будущий INCOMPLETE, если объект не перезаписан вновь.
-- Завершена с EAGAIN → V_DEAD: версия точно не применена; в тесте сейчас недостижимо,
-  оставлено как заготовка на будущее, также применимо, например, к ENOSPC.
-- Завершена с EPIPE → версия остаётся OPTIONAL: отказ — не ack, но операция могла
-  примениться (а могла и нет). Опциональное удаление также требует повтора после
-  подъёма пиров и тоже разрешает EC INCOMPLETE до следующей перезаписи.
-- Завершена с другой ошибкой → падение теста («failed with retval»).
-
-## Проверки (все точки abort)
-
-**Согласованность данных (world_check):**
-1. world_check — ответ обязан объясняться подмножеством версий: все обязательные
-   (зафиксированные) присутствуют; байты отвечают ровно своей версией
-   («record obj/seq/off mismatch», битмап-гранула «carries data from wrong version»).
-2. «shows %s but the highest…» — прочитана старая версия объекта, последние записи
-   потеряны (монотонность нарушена).
-3. «read shows seq over acked v's granule» — содержимое гранулы (obj/seq/off в record)
-   противоречит версии, которой гранула принадлежит по модели: сборное/порванное
-   содержимое вместо подтверждённых байт.
-4. «DEAD version showed again» — откаченные версии не должны возвращаться.
-5. «committed version read fully absent over floor» / «established version read absent
-   over its granule» — подтверждённые операции не должны исчезать.
-6. read -EIO «OSD deems unrecoverable» — легален ровно в одном окне: незавершённое
-   EC-удаление. Вне его -EIO — падение теста, в т.ч. «чистый» ack удаления + INCOMPLETE
-   после revival (OSD соврал о полноте) и откат цепей при живой сессии без окна удаления;
-   прочие retval ≠ len → падение теста.
-7. bitmap_len ≠ ожидаемому в ответах чтения → падение теста.
-8. «came back INCOMPLETE» после set_change/crash — тот же критерий: окно незавершённого
-   удаления ⇒ INCOMPLETE легален и удаление повторяется; в ином случае → падение теста.
-9. «came back … which no world of the recorded versions explains» — финальная проверка
-   корректности содержимого объектов после завершения теста.
-10. «changed across a clean restart that lost nothing» — неизменность объектов после перезапуска.
-
-**Живость/тайминг:**
-
-11. «did not settle in MAX_STEPS» — операции не завершились за большое число шагов (возможна
-    самоблокировка);
-12. «operations did not complete» — залипшие операции, печатаются в дампе;
-    «a read of object N did not complete in MAX_STEPS ... deadlock?»; «OSD did not load
-    PGs from etcd in MAX_STEPS» / «OSD did not finish peering in MAX_STEPS» — проверка на старте OSD.
-13. «did not release the PG» — OSD не отпустил PG по команде;
-14. «disk did not go idle» — проверка против use-after-free, что все операции диска завершены
-    перед уничтожением OSD;
-15. «PG did not become healthy after reviving every peer» — PG не поднялась после подъёма всех OSD;
-16. «pending recovery/repeated deletion could not complete on a healthy PG» — удаление/восстановление
-    не завершено на живой PG.
-
-**Защиты тестовых заглушек:**
-
-17. Неожиданный SQE (fd/opcode) на заглушке диска; «unexpected secondary opcode» у пира;
-    аргументы `--p-reply ≥ 1`, `--max-inflight ≥ 1` и т.п.
-
-**Проверки покрытия:**
-
-18. `peer_cache_loss<100` + volatile-конфиг + ≥8 смертей пира ⇒ проверка, что хотя бы
-    раз выполнен вариант, в котором парный OSD не потерял журнал.
-19. ≥10 грязных смертей OSD/передач PG ⇒ wire_harvested > 0: хотя бы одна операция
-    первичного OSD, бывшая в полёте, обязана была собраться в «сеть» при остановке —
-    путь «доставки от мёртвого OSD» выполнен.
-
-## Отчёт и воспроизводимость
-
-OK-строка: writes(refused)/deletes/syncs/crashes/restarts/takeovers/peer deaths
-(kept journal)/recoveries/set changes/verified reads/stragglers (applied/captured/lost)/disk ops.
-
-Детерминизм: один seed ⇒ та же конфигурация и то же расписание; `-v` — трасса операций
-диска и парных OSD, захватов операций при падении пиров и изменений etcd.

docs/usage/admin.en.md

@@ -14,7 +14,6 @@
 - [Removing a failed disk](#removing-a-failed-disk)
 - [Adding a disk](#adding-a-disk)
 - [Restoring from lost pool configuration](#restoring-from-lost-pool-configuration)
-- [Incompatibility problems](#Incompatibility-problems)
 - [Upgrading Vitastor](#upgrading-vitastor)
 - [OSD memory usage](#osd-memory-usage)
 
@@ -36,19 +35,10 @@ PG state consists of exactly 1 base state and an arbitrary number of additional
 
 PG state always includes exactly 1 of the following base states:
 - **active** — PG is active and handles user I/O.
-- **incomplete** — Not enough OSDs are available to activate this PG. More exactly, that
-  means one of the following:
-  - Less than pg_minsize current target OSDs are available for the PG. I.e. more disks
-    are lost than allowed by the pool's redundancy scheme.
-  - All OSDs of some of PG's history records are unavailable, or, for EC pools, less
-    than (pg_size-parity_chunks) OSDs are available in one of the history records.
-    In other words it means that some data in this PG was written to an OSD set such that
-    it's currently impossible to read it back because these OSDs are down. For example,
-    if the pool has pg_size=3 and pg_minsize=1, part of the data may be written only to
-    1 OSD. If that exact OSD is lost, PG becomes **incomplete**.
-  - [allow_net_split](../config/osd.en.md#allow_net_split) is disabled (default) and
-    primary OSD of the PG can't connect to some secondary OSDs marked as alive in etcd.
-    I.e. a network partition happened: OSDs can talk to etcd, but not to some other OSDs.
+- **incomplete** — Not enough OSDs are available to activate this PG. That is, more disks
+  are lost than it's allowed by the pool's redundancy scheme. For example, if the pool has
+  pg_size=3 and pg_minsize=1, part of the data may be written only to 1 OSD. If that exact
+  OSD is lost, PG will become **incomplete**.
 - **offline** — PG isn't activated by any OSD at all. Either primary OSD isn't set for
   this PG at all (if the pool is just created), or an unavailable OSD is set as primary,
   or the primary OSD refuses to start this PG (for example, because of wrong block_size),
@@ -167,17 +157,6 @@ done
 
 After that all PGs should peer and find all previous data.
 
-## Incompatibility problems
-
-### ISA-L 2.31
-
-⚠ It is FORBIDDEN to use Vitastor 2.1.0 and earlier versions with ISA-L 2.31 and newer if
-you use EC N+K pools and K > 1 on a CPU with GF-NI instruction support, because it WILL
-lead to **data loss** during EC recovery.
-
-If you accidentally upgraded ISA-L to 2.31 but didn't upgrade Vitastor and restarted OSDs,
-then stop them as soon as possible and either update Vitastor or roll back ISA-L.
-
 ## Upgrading Vitastor
 
 Every upcoming Vitastor version is usually compatible with previous both forward
@@ -231,18 +210,6 @@ Upgrading from <= 0.5.x to >= 0.6.x is not supported.
 
 Downgrade are also allowed freely, except the following specific instructions:
 
-### 3.x -> 2.x
-
-Versions 3.0.0 and newer contain two store implementations - an old one and a new
-one, unsupported in 2.x and previous versions. So you should check your OSD store
-versions before downgrading to 2.x with the following command:
-
-`vitastor-disk read-sb /dev/vitastor/osdXX-data | jq -r .meta_format`
-
-If it prints 3 then OSD uses the new store and you can't downgrade it to 2.x.
-
-If it prints 2 or nothing then OSD uses the old store and the downgrade is allowed.
-
 ### 1.8.0 to 1.7.1
 
 Before downgrading from version >= 1.8.0 to version <= 1.7.1