Use 32-bit big write location (OK for up to 512 TB OSDs)

This is required to:
1) later inline the last "big_write" entry into the object to slightly reduce memory usage
2) eliminate an ugly hack where entry type is determined by its size
3) make the storage scheme extensible i.e. when adding new entry types

.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 \
+RUN apt-get -y install etcd qemu-system-x86 qemu-block-extra qemu-utils fio libasan5 \
     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,20 @@
-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 "2.4.3")
 
 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"
+add_custom_target(test
+	COMMAND
+	echo leak:tcmalloc > ${CMAKE_CURRENT_BINARY_DIR}/lsan-suppress.txt &&
+	env LSAN_OPTIONS=suppressions=${CMAKE_CURRENT_BINARY_DIR}/lsan-suppress.txt ${CMAKE_CTEST_COMMAND}
 )
-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_dependencies(test build_tests)
 add_subdirectory(src)

README-ru.md

@@ -26,15 +26,11 @@ Vitastor поддерживает QEMU-драйвер, протоколы UBLK,
 
 ## Презентации и записи докладов
 
-- 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)
 
 ## Документация
 
@@ -62,7 +58,6 @@ 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)
 - Использование
@@ -73,7 +68,6 @@ Vitastor поддерживает QEMU-драйвер, протоколы UBLK,
   - [NBD](docs/usage/nbd.ru.md) - старый интерфейс для монтирования ядром
   - [QEMU, qemu-img и VDUSE](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

@@ -26,15 +26,11 @@ Read more details in the documentation. You can start from here: [Quick Start](d
 
 ## 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
 
@@ -62,7 +58,6 @@ 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
@@ -73,7 +68,6 @@ Read more details in the documentation. You can start from here: [Quick Start](d
   - [NBD](docs/usage/nbd.en.md) - old interface for kernel mounts
   - [QEMU, qemu-img and VDUSE](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 && \
+    wget https://vitastor.io/archive/qemu/qemu-bookworm-9.2.2%2Bds-1%2Bvitastor4/qemu-utils_9.2.2%2Bds-1%2Bvitastor4_amd64.deb && \
+    wget https://vitastor.io/archive/qemu/qemu-bookworm-9.2.2%2Bds-1%2Bvitastor4/qemu-block-extra_9.2.2%2Bds-1%2Bvitastor4_amd64.deb && \
     dpkg -x qemu-utils*.deb tmp1 && \
     dpkg -x qemu-block-extra*.deb tmp1 && \
     cp -a tmp1/usr/bin/qemu-storage-daemon /usr/bin/ && \

csi/Dockerfile.local

@@ -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,8 +25,8 @@ 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)
 
@@ -36,8 +36,8 @@ 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 && \
+    wget https://vitastor.io/archive/qemu/qemu-bookworm-9.2.2%2Bds-1%2Bvitastor4/qemu-utils_9.2.2%2Bds-1%2Bvitastor4_amd64.deb && \
+    wget https://vitastor.io/archive/qemu/qemu-bookworm-9.2.2%2Bds-1%2Bvitastor4/qemu-block-extra_9.2.2%2Bds-1%2Bvitastor4_amd64.deb && \
     dpkg -x qemu-utils*.deb tmp1 && \
     dpkg -x qemu-block-extra*.deb tmp1 && \
     cp -a tmp1/usr/bin/qemu-storage-daemon /usr/bin/ && \

csi/Makefile

@@ -1,4 +1,4 @@
-VITASTOR_VERSION ?= v3.2.2
+VITASTOR_VERSION ?= v2.4.3
 
 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:v2.4.3
           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:v2.4.3
           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 = "2.4.3"
 )
 
 // 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

@@ -96,16 +96,18 @@ func NewNodeServer(driver *Driver) *NodeServer
     {
         ns.restoreUblkDaemons()
     }
-    ns.restoreNfsDaemons()
-    dur, err := time.ParseDuration(os.Getenv("RESTART_INTERVAL"))
-    if (err != nil)
+    if (ns.method == MOUNT_VDUSE || ns.method == MOUNT_UBLK)
     {
-        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,8 +134,10 @@ 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
@@ -147,7 +151,6 @@ func (ns *NodeServer) restarter()
         {
             ns.restoreUblkDaemons()
         }
-        ns.restoreNfsDaemons()
     }
 }
 
@@ -326,10 +329,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 +363,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 +400,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",
@@ -737,7 +725,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 +754,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 +815,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
@@ -1055,131 +1030,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 +1048,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

@@ -20,7 +20,6 @@ import (
 
     "google.golang.org/grpc/codes"
     "google.golang.org/grpc/status"
-    "golang.org/x/sys/unix"
 )
 
 type MountMethod int
@@ -520,22 +519,3 @@ func GetDeviceNameFromMount(mountPath string) (string, error)
 
     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-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 (2.4.3-1) unstable; urgency=medium
 
   * Bugfixes
 

debian/control

@@ -3,7 +3,7 @@ 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,
+  linux-libc-dev, libgoogle-perftools-dev, libjerasure-dev, libgf-complete-dev,
   libibverbs-dev, librdmacm-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

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

@@ -37,8 +37,14 @@ rm -rf a b
 
 echo "dep:fio=$FIO" > debian/fio_version
 
+cd /root/vitastor/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/vitastor/packages/vitastor-$REL
-if [[ ( "$REL" = "trixie" || "$REL" = "resolute" ) && -e ../vitastor-bookworm/vitastor_$VER.orig.tar.xz ]]; then
+if [[ "$REL" = "trixie" && -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

debian/vitastor-buildenv.Dockerfile

@@ -14,18 +14,18 @@ WORKDIR /root
 RUN set -e -x; \
     if [ "$REL" = "buster" ]; then \
         perl -i -pe 's/deb.debian.org/archive.debian.org/' /etc/apt/sources.list; \
+        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; \
-    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 install fio 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

debian/vitastor-client.install

@@ -4,8 +4,6 @@ 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*

docker/Dockerfile

@@ -1,6 +1,6 @@
 # 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

docker/Makefile

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

docker/etc/apt/preferences

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

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

@@ -1,2 +1,2 @@
-deb http://vitastor.io/debian trixie main
-#deb http://http.debian.net/debian/ trixie-backports main
+deb http://vitastor.io/debian bookworm main
+deb http://http.debian.net/debian/ bookworm-backports 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,7 +7,7 @@ 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 \
+ExecStart=bash -c 'docker run --rm -i -v /etc/vitastor:/etc/vitastor -v /dev:/dev -v /run:/run \
     --security-opt seccomp=unconfined --privileged --pid=host --log-driver none --network host --name vitastor vitastor:$VITASTOR_VERSION \
     sleep.sh'
 ExecStartPost=udevadm trigger

docker/etc/vitastor/docker.conf

@@ -4,7 +4,7 @@
 #
 
 # Desired Vitastor version
-VITASTOR_VERSION=v3.2.2
+VITASTOR_VERSION=v2.4.3
 
 # 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/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:
 
 ```

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

@@ -17,14 +17,12 @@ between clients, OSDs and etcd.
 - [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)
@@ -36,7 +34,6 @@ between clients, OSDs and etcd.
 - [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)
 
@@ -105,6 +102,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,23 +116,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
-
 ## rdma_port_num
 
 - Type: integer
@@ -158,40 +143,6 @@ 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
@@ -236,6 +187,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
@@ -341,21 +314,6 @@ 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

docs/config/network.ru.md

@@ -17,14 +17,12 @@
 - [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)
@@ -36,7 +34,6 @@
 - [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)
 
@@ -104,6 +101,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,24 +117,6 @@ 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
 
 - Тип: целое число
@@ -161,40 +146,6 @@ libibverbs < v32.
 
 Опция неприменима к 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
 
 - Тип: целое число
@@ -241,6 +192,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
 
 - Тип: секунды
@@ -348,22 +322,6 @@ Vitastor содержат 128-байтные заголовки, за котор
 поменять этот параметр и посмотреть, как он влияет на производительность
 случайного и линейного доступа.
 
-## 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
 
 - Тип: целое число

docs/config/osd.en.md

@@ -38,7 +38,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)
@@ -66,11 +65,6 @@ with an OSD restart or, for some of them, even without restarting by updating co
 - [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
 
@@ -281,19 +275,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
 
@@ -372,8 +360,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 +373,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
@@ -691,72 +666,3 @@ Use this parameter to enable or disable this function for all pools.
 - 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

@@ -39,7 +39,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)
@@ -67,11 +66,6 @@
 - [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
 
@@ -289,19 +283,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 +372,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 +387,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
 
 - Тип: булево (да/нет)
@@ -725,78 +699,3 @@ pg_minsize OSD во время переключений, что может по
 - Значение по умолчанию: 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/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/included.en.md

@@ -44,8 +44,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}}
@@ -66,8 +64,6 @@
 
 {{../../usage/nfs.en.md}}
 
-{{../../usage/security.en.md}}
-
 {{../../usage/admin.en.md}}
 
 ## Performance

docs/config/src/included.ru.md

@@ -44,8 +44,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}}
@@ -66,8 +64,6 @@
 
 {{../../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`:
 

docs/config/src/network.yml

@@ -84,6 +84,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 +97,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 +105,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,24 +120,6 @@
     коммутатора для 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
   info: |
@@ -188,53 +164,6 @@
     Правильный 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
   info: |
@@ -289,6 +218,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
@@ -405,29 +373,6 @@
     параметра читается без дополнительного копирования. Вы можете попробовать
     поменять этот параметр и посмотреть, как он влияет на производительность
     случайного и линейного доступа.
-- 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

docs/config/src/osd.yml

@@ -253,33 +253,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
@@ -398,15 +386,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 +402,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 +412,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
@@ -833,112 +801,3 @@
   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 vitalif/vitastor:v2.4.3`
 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 vitalif/vitastor:v2.4.3 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 vitalif/vitastor:v2.4.3`
 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 vitalif/vitastor:v2.4.3 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/packages.en.md

@@ -14,9 +14,11 @@
   - Debian 13 (Trixie/Sid): `deb https://vitastor.io/debian trixie main`
   - Debian 12 (Bookworm): `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`
+  - Ubuntu 24.04 (Noble): `deb https://vitastor.io/debian noble main`
+  - Add `-oldstable` to bookworm/bullseye/buster in this line to install the last
+    stable version from 0.9.x branch instead of 1.x
 - To always prefer vitastor-patched QEMU and Libvirt versions, add the following to `/etc/apt/preferences`:
   ```
   Package: *
@@ -28,17 +30,18 @@
 ## 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

docs/installation/packages.ru.md

@@ -14,9 +14,11 @@
   - Debian 13 (Trixie/Sid): `deb https://vitastor.io/debian trixie main`
   - Debian 12 (Bookworm): `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`
+  - Ubuntu 24.04 (Noble): `deb https://vitastor.io/debian noble main`
+  - Добавьте `-oldstable` к слову bookworm/bullseye/buster в этой строке, чтобы
+    установить последнюю стабильную версию из ветки 0.9.x вместо 1.x
 - Чтобы всегда предпочитались версии пакетов QEMU и Libvirt с патчами Vitastor, добавьте в `/etc/apt/preferences`:
   ```
   Package: *
@@ -28,17 +30,18 @@
 ## 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`
 
 ## Установочные требования

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.x 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
+  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, 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.x):
 
 - Добавьте соответствующий 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
+  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, buster для 6.4
 - Установите пакеты vitastor-client, pve-qemu-kvm, pve-storage-vitastor (* или см. сноску) из репозитория Vitastor
 - Определите тип хранилища в `/etc/pve/storage.cfg` (см. ниже)
 - Обязательно заблокируйте доступ от виртуальных машин к сети Vitastor (OSD и etcd), т.к. Vitastor (пока) не поддерживает аутентификацию

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)
+- jerasure headers and libraries
+- ISA-L, libibverbs and librdmacm 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
+- Заголовки и библиотеки jerasure
+- Опционально - заголовки и библиотеки ISA-L, libibverbs, librdmacm
+- tcmalloc (google-perftools-dev)
 
 ## Базовая инструкция
 

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)
@@ -41,8 +39,6 @@
 - [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
 

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
@@ -43,8 +41,6 @@
 - [Встроенный 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) для хранения ключей
 
 ## Драйверы и инструменты
 

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,26 +30,20 @@
 
 ## 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`

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](../config/network.ru.md#osd_network) в `/etc/vitastor/vitastor.conf`. Например:
+  ```
+  {
+    "etcd_address": ["10.200.1.10:2379","10.200.1.11:2379","10.200.1.12:2379"],
+    "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

@@ -231,18 +231,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

docs/usage/admin.ru.md

@@ -228,18 +228,6 @@ done
 
 Откат (понижение версии) тоже свободно разрешён, кроме указанных ниже случаев:
 
-### 3.x -> 2.x
-
-Версии 3.0.0 и более новые содержат две реализации хранилища - старую и новую, не
-поддерживаемую в 2.x и предыдущих версиях. Таким образом, перед откатом на 2.x вам
-следует проверить, какая версия хранилища используется вашими OSD - командой:
-
-`vitastor-disk read-sb /dev/vitastor/osdXX-data | jq -r .meta_format`
-
-Если выводится 3, это новое хранилище и откатить такой OSD до 2.x нельзя.
-
-Если выводится 2 или не выводится ничего, это старое хранилище и откат разрешён.
-
 ### 1.8.0 -> 1.7.1
 
 Перед понижением версии с >= 1.8.0 до <= 1.7.1 вы должны скопировать ключ

docs/usage/cli.en.md

@@ -33,11 +33,6 @@ It supports the following commands:
 - [modify-pool](#modify-pool)
 - [ls-pools](#ls-pools)
 - [rm-pool](#rm-pool)
-- [ls-user](#ls-user)
-- [modify-user](#modify-user)
-- [rm-user](#rm-user)
-- [serve](#serve)
-- [cpubench](#cpubench)
 
 Global options:
 
@@ -112,7 +107,6 @@ Options:
 --sort FIELD    Sort by specified field (name, size, used_size, <read|write|delete>_<iops|bps|lat|queue>)
 -r|--reverse    Sort in descending order
 -n|--count N    Only list first N items
---ids ID1,ID2   Only list images with specified full IDs
 --tree          Show image snapshot/clone tree
 ```
 
@@ -131,35 +125,18 @@ bench-kaveri         kaveri    10 G  10 G    0 B/s  0     0      0 us  0 B/s  0
 
 ## create
 
-`vitastor-cli create -s|--size SIZE [OPTIONS] <name>`
+`vitastor-cli create -s|--size <size> [-p|--pool <id|name>] [--parent <parent_name>[@<snapshot>]] <name>`
 
-Create an image. Options:
-
-* `-s|--size SIZE` - New image size in bytes or with a K/M/G/T unit suffix.
-* `-p|--pool POOL` - Specify pool for the new image (may be omitted if there is only 1 pool).
-* `--parent PARENT` - Create a copy-on-write image clone based on PARENT (or PARENT@SNAPSHOT).
-  If parent is not a snapshot, it must be a read-only image.
-* `--enc-key random` - Generate a new random AES-256-XTS encryption key for the new image.
-* `--enc-key HEX` - Set a specified AES-256-XTS key (64 bytes in hex) for the new image.
-* `--enc-key vault:ID` - Use an encryption key from an external Vault secret with specified ID.
-* `--owner USERNAME` - Set image owner. The default owner is the current user taken from the
-  CN of the TLS certificate used to connect to the cluster.
-* `--owner-group NAME` - Set image owner group. Users in this group get full access to the image.
-* `--reader-group NAME` - Set image reader group. Users in this group get read-only access to the image.
+Create an image. You may use K/M/G/T suffixes for `<size>`. If `--parent` is specified,
+a copy-on-write image clone is created. Parent must be a snapshot (readonly image).
+Pool must be specified if there is more than one pool.
 
 ```
-vitastor-cli create --snapshot <snapshot> [OPTIONS] <image>
-vitastor-cli snap-create [OPTIONS] <image>@<snapshot>
+vitastor-cli create --snapshot <snapshot> [-p|--pool <id|name>] <image>
+vitastor-cli snap-create [-p|--pool <id|name>] <image>@<snapshot>
 ```
 
-Create a snapshot of image `<image>`. May be used live if only a single writer is active.
-
-Options:
-
-* `-p|--pool POOL` - Move image to pool POOL, leaving the snapshot in the old pool.
-* `--enc-key random` - Change image encryption key to a new random AES-256-XTS key.
-* `--enc-key KEY` - Change image encryption key to a specified key, Vault key or to an empty key.
-  By default, the image retains its old encryption key when taking a snapshot.
+Create a snapshot of image `<name>` (either form can be used). May be used live if only a single writer is active.
 
 See also about [how to export snapshots](qemu.en.md#exporting-snapshots).
 
@@ -174,10 +151,6 @@ You should resize file system in the image, if present, before shrinking it.
 * `--deleted 1|0` - Set/clear 'deleted image' flag (set automatically during unfinished deletes).
 * `-f|--force` - Proceed with shrinking or setting readwrite flag even if the image has children.
 * `--down-ok` - Proceed with shrinking even if some data will be left on unavailable OSDs.
-* `--enc-key HEX` - Change image encryption key (allowed only with `--force`).
-* `--owner USERNAME` - Change image owner.
-* `--owner-group NAME` - Change image owner group name.
-* `--reader-group NAME` - Change image reader group name.
 
 ## dd
 
@@ -196,7 +169,6 @@ Options can be specified in classic dd style (`key=value`) or like usual (`--key
 | `iimg=<image>`  | Copy from Vitastor image `<image>`                                      |
 | `if=<file>`     | Copy from file `<file>`                                                 |
 | `oimg=<image>`  | Copy to Vitastor image `<image>`                                        |
-| `opool=<pool>`  | Pool to create output image if it doesn't exist                         |
 | `of=<file>`     | Copy to file `<file>`                                                   |
 | `bs=1M`         | Set copy block size                                                     |
 | `count=N`       | Copy only N input blocks. If N ends in B it counts bytes, not blocks    |
@@ -243,16 +215,15 @@ Flatten a layer, i.e. merge data and detach it from parents.
 
 ## rm-data
 
-`vitastor-cli rm-data --pool <id|name> --inode <inode> [--wait-list] [--min-offset <offset>]`
+`vitastor-cli rm-data --pool <pool> --inode <inode> [--wait-list] [--min-offset <offset>]`
 
-Remove inode data without changing metadata. `<inode>` may be decimal or 0x hex.
+Remove inode data without changing metadata.
 
 ```
 --wait-list   Retrieve full objects listings before starting to remove objects.
               Requires more memory, but allows to show correct removal progress.
 --min-offset  Purge only data starting with specified offset.
 --max-offset  Purge only data before specified offset.
-              Offsets are in bytes or with a K/M/G/T unit suffix, decimal or 0x hex.
 --client_wait_up_timeout 16  Timeout for waiting until PGs are up in seconds.
 ```
 
@@ -435,7 +406,6 @@ Optional parameters:
 | `--used_for_app s3:<name>`     | Mark pool as used for S3 location with name `<name>`                       |
 | `--pg_stripe_size <number>`    | Increase object grouping stripe                                            |
 | `--max_osd_combinations 10000` | Maximum number of random combinations for LP solver input                  |
-| `--creator_group <group>`      | User group allowed to create images in this pool                           |
 | `--wait`                       | Wait for the new pool to come online                                       |
 | `-f` or `--force`              | Do not check that cluster has enough OSDs to create the pool               |
 
@@ -455,9 +425,8 @@ Modify an existing pool. Modifiable parameters:
 
 ```
 [-s|--pg_size <number>] [--pg_minsize <number>] [-n|--pg_count <count>]
-[--failure_domain <level>] [--root_node <node>] [--osd_tags <tags>] [--used_for_app <type>:<name>]
+[--failure_domain <level>] [--root_node <node>] [--osd_tags <tags>] [--no_inode_stats 0|1]
 [--max_osd_combinations <number>] [--primary_affinity_tags <tags>] [--scrub_interval <time>]
-[--level_placement <rules>] [--raw_placement <rules>] [--creator_group <group>]
 ```
 
 Non-modifiable parameters (changing them WILL lead to data loss):
@@ -485,7 +454,7 @@ Remove a pool. Refuses to remove pools with images without `--force`.
 
 ## ls-pools
 
-`vitastor-cli ls-pools|pool-ls|ls-pool|pools [-l] [--detail] [--sort FIELD] [-r] [-n N] [<glob> ...]`
+`vitastor-cli ls-pools|pool-ls|ls-pool|pools [-l] [--detail] [--sort FIELD] [-r] [-n N] [--stats] [<glob> ...]`
 
 List pools (only matching <glob> patterns if passed).
 
@@ -496,77 +465,3 @@ List pools (only matching <glob> patterns if passed).
 | `--sort FIELD`       | Sort by specified field (see fields in --json output) |
 | `-r` or `--reverse`  | Sort in descending order                              |
 | `-n` or `--count N`  | Only list first N items                               |
-
-## ls-user
-
-`vitastor-cli ls-users|user-ls|ls-user|list-users [<name> ...]`
-
-List users. If names are passed, only list users with those names. User names must
-match CN (Common Name) of TLS client certificates used to connect to the cluster.
-
-See [Users and access rights](security.en.md#users-and-access-rights) for details on
-the Vitastor authorization model.
-
-## modify-user
-
-`vitastor-cli modify-user --groups <group1,group2,...> <username>`
-
-Create or update a user with the given name (matching TLS certificate CN).
-
-Options:
-
-* `--groups GROUPS` - Set user's groups (comma-separated). Groups are used together with
-  `--owner-group` / `--reader-group` fields of images and `--creator_group` of the pool to
-  authorize operations. Pass an empty string to clear the groups.
-
-## rm-user
-
-`vitastor-cli rm-user|remove-user|delete-user <username>`
-
-Remove a user.
-
-## serve
-
-`vitastor-cli serve`
-
-Start an HTTP server that handles vitastor-cli commands over a REST API in JSON format.
-
-Options:
-
-| <!-- -->              | <!-- -->                                                                      |
-|-----------------------|-------------------------------------------------------------------------------|
-| `--bind_address ADDR` | Server IP address(es), separated by space. Default is `127.0.0.1`.            |
-| `--port 8080`         | Server port. Default is `8080`.                                               |
-| `--api_cert FILE`     | Server TLS certificate.                                                       |
-| `--api_pkey FILE`     | Private key for `--api_cert`.                                                 |
-| `--cert FILE`         | Administrator or client certificate used by the server to access the cluster. |
-| `--pkey FILE`         | Private key for `--cert`.                                                     |
-
-When `api_cert`/`api_pkey` are set the server operates in HTTPS mode. If `client_ca`
-is also set (in configuration or on the command line), connecting clients are authenticated by their
-TLS certificates. When [use_perms](../config/security.en.md#use_perms) is enabled, HTTPS with client
-authentication is mandatory and per-user permissions are enforced. For regular clients the server only
-allows operations on images that the user owns or has group access to; all other operations require
-administrator privileges.
-
-The vitastor-cli process itself must be authenticated as an admin user (its own client
-[cert](../config/security.en.md#cert) must be signed with [admin_ca](../config/security.en.md#admin_ca))
-to be able to serve all requests.
-
-`vitastor-cli serve` exposes a full OpenAPI specification at `/openapi` endpoint.
-Start the server and check it out for the information about available API methods.
-
-See also [Security in Vitastor](security.en.md) for the full picture of how authentication
-and authorization work.
-
-## cpubench
-
-`vitastor-cli cpubench [--json]`
-
-Run CPU crypto performance tests: AES-256-GCM, AES-256-XTS and xxhash3. This benchmark
-does not connect to the cluster — it only measures encryption/hashing speed locally.
-
-Specify `--json` to get the output as machine-readable JSON.
-
-See [Encryption performance](security.en.md#encryption-performance) for example results
-on modern and older CPUs.

docs/usage/cli.ru.md

@@ -34,11 +34,6 @@ vitastor-cli - интерфейс командной строки для адм
 - [modify-pool](#modify-pool)
 - [ls-pools](#ls-pools)
 - [rm-pool](#rm-pool)
-- [ls-user](#ls-user)
-- [modify-user](#modify-user)
-- [rm-user](#rm-user)
-- [serve](#serve)
-- [cpubench](#cpubench)
 
 Глобальные опции:
 
@@ -114,7 +109,6 @@ kaveri    2/1     32   0 B      10 G    0 B        100%    0%
 --sort FIELD    Сортировать по заданному полю (name, size, used_size, <read|write|delete>_<iops|bps|lat|queue>)
 -r|--reverse    Сортировать в обратном порядке
 -n|--count N    Показывать только первые N записей
---ids ID1,ID2   Показывать только образы с заданными полными ID
 --tree          Вывести снапшоты и клоны в виде дерева
 ```
 
@@ -133,38 +127,19 @@ bench-kaveri         kaveri    10 G  10 G    0 B/s  0     0      0 us  0 B/s  0
 
 ## create
 
-`vitastor-cli create -s|--size SIZE [ОПЦИИ] <name>`
+`vitastor-cli create -s|--size <size> [-p|--pool <id|name>] [--parent <parent_name>[@<snapshot>]] <name>`
 
-Создать образ. Опции:
-
-* `-s|--size SIZE` - Размер нового образа в байтах или с суффиксом K/M/G/T (кило/мега/гига/терабайт).
-* `-p|--pool POOL` - Создать образ в заданном пуле (можно не указывать, если пул всего один).
-* `--parent PARENT` - Создать легковесный клон на основе образа `PARENT` или снимка `PARENT@SNAP`.
-  Если `PARENT` - не снимок, он должен быть помечен как образ только для чтения.
-* `--enc-key random` - Сгенерировать случайный ключ шифрования AES-256-XTS для нового образа.
-* `--enc-key HEX` - Установить заданный ключ AES-256-XTS (64 байта в hex) для нового образа.
-* `--enc-key vault:ID` - Использовать ключ из внешнего секрета с заданным ID из Vault.
-* `--owner USERNAME` - Задать владельца образа. По умолчанию владельцем становится текущий
-  пользователь, определяемый по CN TLS-сертификата, используемого для подключения к кластеру.
-* `--owner-group NAME` - Задать группу владельцев образа. Пользователи из этой группы получают
-  полный доступ к образу.
-* `--reader-group NAME` - Задать группу читателей образа. Пользователи из этой группы получают
-  доступ к образу только на чтение.
+Создать образ. Для размера `<size>` можно использовать суффиксы K/M/G/T (килобайт-мегабайт-гигабайт-терабайт).
+Если указана опция `--parent`, создаётся клон образа. Родитель `<parent_name>[@<snapshot>]` должен быть
+снимком (или просто немодифицируемым образом). Пул обязательно указывать, если в кластере больше одного пула.
 
 ```
-vitastor-cli create --snapshot <snapshot> [ОПЦИИ] <image>
-vitastor-cli snap-create [ОПЦИИ] <image>@<snapshot>
+vitastor-cli create --snapshot <snapshot> [-p|--pool <id|name>] <image>
+vitastor-cli snap-create [-p|--pool <id|name>] <image>@<snapshot>
 ```
 
-Создать снимок образа `<image>` (можно использовать любую форму команды).
-Снимок можно создавать без остановки клиентов, если пишущих клиентов не больше одного.
-
-Опции:
-
-* `-p|--pool POOL` - Переместить образ в пул POOL, оставив снимок в старом пуле.
-* `--enc-key random` - Изменить ключ шифрования образа на новый случайный ключ AES-256-XTS.
-* `--enc-key KEY` - Изменить ключ шифрования образа на заданный ключ, ключ из Vault или пустой ключ.
-  По умолчанию шифрованные образы сохраняют старый ключ при снятии снимка.
+Создать снимок образа `<name>` (можно использовать любую форму команды). Снимок можно создавать без остановки
+клиентов, если пишущий клиент максимум 1.
 
 Смотрите также информацию о том, [как экспортировать снимки](qemu.ru.md#экспорт-снимков).
 
@@ -181,10 +156,6 @@ vitastor-cli snap-create [ОПЦИИ] <image>@<snapshot>
 * `--deleted 1|0` - Установить/снять флаг "образ удалён" (устанавливается при незавершённом удалении).
 * `-f|--force` - Разрешить уменьшение или перевод в чтение-запись образа, у которого есть клоны.
 * `--down-ok` - Разрешить уменьшение, даже если часть данных останется неудалённой на недоступных OSD.
-* `--enc-key HEX` - Изменить ключ шифрования образа (разрешено только с `--force`).
-* `--owner USERNAME` - Изменить владельца образа.
-* `--owner-group NAME` - Изменить имя группы владельцев образа.
-* `--reader-group NAME` - Изменить имя группы читателей образа.
 
 ## dd
 
@@ -203,7 +174,6 @@ vitastor-cli dd [iimg=<image> | if=<file>] [oimg=<image> | of=<file>] [bs=1M] \
 | `iimg=<image>`  | Копировать из образа Vitastor `<image>`                                 |
 | `if=<file>`     | Копировать из файла `<file>`                                            |
 | `oimg=<image>`  | Копировать в образ Vitastor `<image>`                                   |
-| `opool=<pool>`  | Пул для создания выходного образа, если он не существует                |
 | `of=<file>`     | Копировать в файл `<file>`                                              |
 | `bs=1M`         | Задать размер блока копирования                                         |
 | `count=N`       | Копировать не более N блоков. Если N заканчивается на B - то N байт.    |
@@ -252,16 +222,15 @@ vitastor-cli dd [iimg=<image> | if=<file>] [oimg=<image> | of=<file>] [bs=1M] \
 
 ## rm-data
 
-`vitastor-cli rm-data --pool <id|name> --inode <inode> [--wait-list] [--min-offset <offset>]`
+`vitastor-cli rm-data --pool <pool> --inode <inode> [--wait-list] [--min-offset <offset>]`
 
-Удалить данные инода, не меняя метаданные образов. `<inode>` можно задать в десятичном виде или в hex с 0x.
+Удалить данные инода, не меняя метаданные образов.
 
 ```
 --wait-list   Сначала запросить полный листинг объектов, а потом начать удалять.
               Требует больше памяти, но позволяет правильно печатать прогресс удаления.
 --min-offset  Удалять только данные, начиная с заданного смещения.
 --max-offset  Удалять только данные до (исключительно) заданного смещения.
-              Смещения задаются в байтах или с суффиксом K/M/G/T, в десятичном виде или в hex с 0x.
 --client_wait_up_timeout 16  Время ожидания поднятия PG в секундах.
 ```
 
@@ -452,7 +421,6 @@ OSD  PARENT            UP    SIZE  USED%    TAGS          WEIGHT  BLOCK  BITMAP
 | `--scrub_interval <time>`      | Включить скрабы с заданным интервалом времени (число + единица s/m/h/d/M/y) |
 | `--pg_stripe_size <number>`    | Увеличить блок группировки объектов по PG                                  |
 | `--max_osd_combinations 10000` | Максимальное число случайных комбинаций OSD для ЛП-солвера                 |
-| `--creator_group <group>`      | Группа пользователей, которым разрешено создавать образы в данном пуле     |
 | `--wait`                       | Подождать, пока новый пул будет активирован                                |
 | `-f` или `--force`             | Не проверять, что в кластере достаточно доменов отказа для создания пула   |
 
@@ -472,9 +440,8 @@ OSD  PARENT            UP    SIZE  USED%    TAGS          WEIGHT  BLOCK  BITMAP
 
 ```
 [-s|--pg_size <number>] [--pg_minsize <number>] [-n|--pg_count <count>]
-[--failure_domain <level>] [--root_node <node>] [--osd_tags <tags>] [--used_for_app <type>:<name>]
+[--failure_domain <level>] [--root_node <node>] [--osd_tags <tags>]
 [--max_osd_combinations <number>] [--primary_affinity_tags <tags>] [--scrub_interval <time>]
-[--level_placement <rules>] [--raw_placement <rules>] [--creator_group <group>]
 ```
 
 Неизменяемые параметры (их изменение ПРИВЕДЁТ к потере данных):
@@ -502,7 +469,7 @@ OSD  PARENT            UP    SIZE  USED%    TAGS          WEIGHT  BLOCK  BITMAP
 
 ## ls-pools
 
-`vitastor-cli ls-pools|pool-ls|ls-pool|pools [-l] [--detail] [--sort FIELD] [-r] [-n N] [<glob> ...]`
+`vitastor-cli ls-pools|pool-ls|ls-pool|pools [-l] [--detail] [--sort FIELD] [-r] [-n N] [--stats] [<glob> ...]`
 
 Показать список пулов. Если передан(ы) шаблон(ы) `<glob>`, то только с именами,
 соответствующими одному из шаблонов (стандартные ФС-шаблоны с * и ?).
@@ -514,79 +481,3 @@ OSD  PARENT            UP    SIZE  USED%    TAGS          WEIGHT  BLOCK  BITMAP
 | `--sort FIELD`        | Сортировать по заданному полю (поля см. в выводе с --json) |
 | `-r` или `--reverse`  | Сортировать в обратном порядке                             |
 | `-n` или `--count N`  | Выводить только первые N записей                           |
-
-## ls-user
-
-`vitastor-cli ls-users|user-ls|ls-user|list-users [<name> ...]`
-
-Показать список пользователей. Если переданы имена, показать только пользователей с указанными
-именами. Имена пользователей должны совпадать с CN (Common Name) TLS-сертификатов
-клиентов, используемых для подключения к кластеру.
-
-Подробнее о модели авторизации в Vitastor см. в разделе
-[Пользователи и права доступа](security.ru.md#пользователи-и-права-доступа).
-
-## modify-user
-
-`vitastor-cli modify-user --groups <group1,group2,...> <username>`
-
-Создать или изменить пользователя с указанным именем (совпадающим с CN TLS-сертификата).
-
-Опции:
-
-* `--groups GROUPS` - Задать группы пользователя (через запятую). Группы используются
-  вместе с полями `owner-group` / `reader-group` образов и полем `--creator_group` пулов
-  для авторизации операций. Пустая строка очищает список групп.
-
-## rm-user
-
-`vitastor-cli rm-user|remove-user|delete-user <username>`
-
-Удалить пользователя.
-
-## serve
-
-`vitastor-cli serve`
-
-Запустить HTTP-сервер, обрабатывающий команды vitastor-cli через REST API в формате JSON.
-
-Опции:
-
-| <!-- -->              | <!-- -->                                                                         |
-|-----------------------|----------------------------------------------------------------------------------|
-| `--bind_address ADDR` | IP-адрес(а) сервера через пробел. По умолчанию `127.0.0.1`.                      |
-| `--port 8080`         | Порт сервера. По умолчанию `8080`.                                               |
-| `--api_cert FILE`     | TLS-сертификат сервера.                                                          |
-| `--api_pkey FILE`     | Закрытый ключ для сертификата `--api_cert`.                                      |
-| `--cert FILE`         | Сертификат администратора/клиента, используемый сервером для доступа к кластеру. |
-| `--pkey FILE`         | Закрытый ключ для сертификата `--cert`.                                          |
-
-Если заданы `api_cert`/`api_pkey`, сервер работает в режиме HTTPS. Если дополнительно
-задан `client_ca` (в файле конфигурации или в командной строке), подключающиеся клиенты аутентифицируются
-по своим TLS-сертификатам. Если включена опция [use_perms](../config/security.ru.md#use_perms), HTTPS с
-аутентификацией клиентов обязателен, и права доступа проверяются для каждого пользователя. Обычным клиентам
-сервер разрешает только операции с образами, которыми они владеют или к которым имеют доступ через группы;
-остальные операции разрешены только администраторам.
-
-Сам процесс vitastor-cli при этом должен использовать сертификат администратора ([cert](../config/security.en.md#cert),
-подписанный [admin_ca](../config/security.en.md#admin_ca)), чтобы иметь возможность обслуживать
-все виды запросов.
-
-`vitastor-cli serve` выставляет полную OpenAPI-спецификацию по адресу `/openapi`.
-Запустите сервер и посмотрите её для подробной информации о доступных методах API.
-
-Смотрите также подробную информацию о том, как устроены аутентификация и авторизация:
-[Безопасность в Vitastor](security.ru.md).
-
-## cpubench
-
-`vitastor-cli cpubench [--json]`
-
-Запустить тесты производительности CPU для криптографических операций: AES-256-GCM,
-AES-256-XTS и xxhash3. Эта команда не обращается к кластеру — она только замеряет
-скорость шифрования/хеширования локально.
-
-Укажите опцию `--json`, чтобы получить вывод в машиночитаемом JSON-формате.
-
-Примеры вывода на современных и старых процессорах см. в разделе
-[Производительность шифрования](security.ru.md#производительность-шифрования).

docs/usage/disk.en.md

@@ -51,9 +51,6 @@ Options (automatic mode):
 ```
 --osd_per_disk <N>
   Create <N> OSDs on each disk (default 1)
---meta_format 3
-  Metadata store version. 3 is the new log-structured store, 2 is the stable store
-  from Vitastor 0.9-2.x, 1 is the legacy store from Vitastor 0.6-0.8.
 --hybrid
   Prepare hybrid (HDD+SSD, NVMe+SATA or etc) OSDs using provided devices. By default,
   any passed SSDs will be used for journals and metadata, HDDs will be used for data,
@@ -95,8 +92,6 @@ Options (single-device mode):
 Options (both modes):
 
 ```
---tags tag1,tag2           Set new OSD tag(s)
---weight <number>          Set new OSD weight (between 0 to 1)
 --journal_size 1G/32M      Set journal size (area or partition size)
 --block_size 1M/128k       Set blockstore object size
 --bitmap_granularity 4k    Set bitmap granularity

docs/usage/disk.ru.md

@@ -50,9 +50,6 @@ vitastor-disk - инструмент командной строки для уп
 ```
 --osd_per_disk <N>
   Создавать по несколько (<N>) OSD на каждом диске (по умолчанию 1)
---meta_format 3
-  Версия хранилища метаданных. 3 - новое лог-структурированное хранилище,
-  2 - стабильное хранилище из Vitastor 0.9-2.x, 1 - старое хранилище из Vitastor 0.6-0.8.
 --hybrid
   Инициализировать гибридные (HDD+SSD, NVMe+SATA и т.п.) OSD на указанных дисках.
   По умолчанию, SSD будут использованы для журналов и метаданных, а HDD - для данных,
@@ -96,8 +93,6 @@ vitastor-disk - инструмент командной строки для уп
 Опции для обоих режимов:
 
 ```
---tags tag1,tag2           Задать теги для новых OSD
---weight <number>          Задать вес для новых OSD (от 0 до 1)
 --journal_size 1G/32M      Задать размер журнала (области или раздела журнала)
 --block_size 1M/128k       Задать размер объекта хранилища
 --bitmap_granularity 4k    Задать гранулярность битовых карт

docs/usage/nfs.en.md

@@ -8,27 +8,15 @@
 
 Vitastor has two file system implementations. Both can be used via `vitastor-nfs`.
 
+Commands:
+- [mount](#mount)
+- [start](#start)
+- [upgrade](#upgrade)
+- [defrag](#defrag)
+
 ⚠️ Important: follow the instructions from [Linux NFS write size](#linux-nfs-write-size)
 for optimal Vitastor NFS performance if you use EC and HDD and mount your NFS from Linux.
 
-- [Pseudo-FS](#pseudo-fs)
-- [VitastorFS](#vitastorfs)
-  - [Supported POSIX features](#supported-posix-features)
-  - [Limitations](#limitations)
-- [Linux NFS](#linux-nfs)
-  - [Sync vs async safety](#sync-vs-async-safety)
-  - [Linux NFS readahead](#linux-nfs-readahead)
-  - [Linux NFS write size](#linux-nfs-write-size)
-  - [Horizontal scaling](#horizontal-scaling)
-- [RDMA](#rdma)
-- [Commands](#commands)
-  - [mount](#mount)
-  - [start](#start)
-  - [upgrade](#upgrade)
-  - [defrag](#defrag)
-- [Mounting from /etc/fstab](#mounting-from-etc-fstab)
-- [Common options](#common-options)
-
 ## Pseudo-FS
 
 Simplified pseudo-FS proxy is used for file-based image access emulation. It's not
@@ -54,7 +42,7 @@ vitastor-nfs start --block --etcd_address 192.168.5.10:2379 --portmap 0 --port 2
 To mount the FS exported by this server, run:
 
 ```
-mount server:/ /mnt/ -o port=2050,mountport=2050,nfsvers=3,soft,sync,nolock,tcp
+mount server:/ /mnt/ -o port=2050,mountport=2050,nfsvers=3,soft,nolock,tcp
 ```
 
 ## VitastorFS
@@ -117,57 +105,7 @@ Other notable missing features which should be addressed in the future:
   in the DB. The FS is implemented is such way that this garbage doesn't affect its
   function, but having a tool to clean it up still seems a right thing to do.
 
-## Linux NFS
-
-Linux NFS client has some specific features of behaviour important for Vitastor:
-
-### Sync vs async safety
-
-Linux NFS has 2 options which affect the mount mode: **soft/hard** and **sync/async**.
-
-**⚠️ Warning: soft,async mode is dangerous and may lead to data loss!**
-
-How these options work:
-
-- In the **hard** mode all requests to the server are retried infinitely. If the NFS server becomes
-  unavailable, it becomes impossible to unmount the FS until you reboot the client host.
-- In the **soft** each request is only tried 2 times (default **retrans** option value for TCP connections).
-  In this case, unmounting a dead FS is possible.
-- In the **sync** mode all modification requests are sent to the server immediately. This is slower,
-  but allows the client to see all errors if they happen.
-- In the **async** mode, modification requests are accumulated and sent to the server in the background
-  mode in parallel. It is faster, but it can hide write errors from the client. Instead of receiving an
-  error from a write operation, the client will only get an error when he closes the file (unsuccessful
-  close() call). Another problem is that there's no convenient way to set write parallelism for NFS, so
-  the client can overload the server.
-
-That's exactly why **soft,async** is dangerous. When a large file is copied, the server is easily overwhelmed
-with write requests and starts to respond slowly. Write requests time out, soft mode retries them only 1 time
-and discards them, which results in parts of the file being lost.
-
-So to recap: always use either **soft,sync** mode, or **hard,async**. By default, `vitastor-nfs mount` uses
-**soft,sync** if mode options are not specified.
-
-### Linux NFS readahead
-
-By default, Linux uses rather small readahead value of 128 KB for NFS mounts.
-
-For simple reading/copuing of files it's way too low because it stops VitastorFS from
-using parallel reads.
-
-However, you can increase readahead. You have 3 options:
-
-1. Use the built-in `vitastor-nfs mount --readahead <SIZE>` option (for example, `--readahead 2M`).
-2. Edit `[nfsrahead]` section in `/etc/nfs.conf` - add `nfs=2048` in it (global setting for all NFS 3.0 mounts).
-3. Manually with the following command: \
-   `echo 2048 > /sys/class/bdi/$(findmnt -no MAJ:MIN /mnt/nfs 2>/dev/null | tr -d ' ')/read_ahead_kb`
-
-Here, `2048` is the desired readahead in KB, and `/mnt/nfs` is your FS mountpoint.
-
-You can easily see 2x-3x linear read improvement after you increase the parameter, so we
-really urge you to try increasing it!
-
-### Linux NFS write size
+## Linux NFS write size
 
 Linux NFS client (nfs/nfsv3/nfsv4 kernel modules) has a hard-coded maximum I/O size,
 currently set to 1 MB - see `rsize` and `wsize` in [man 5 nfs](https://linux.die.net/man/5/nfs).
@@ -223,7 +161,7 @@ modprobe nfsv3
 After these (not much complicated 🙂) manipulations NFS begins to be mounted
 with new wsize and rsize by default and it fixes Vitastor-NFS linear write performance.
 
-### Horizontal scaling
+## Horizontal scaling
 
 Linux NFS 3.0 client doesn't support built-in scaling or failover, i.e. you can't
 specify multiple server addresses when mounting the FS.
@@ -262,7 +200,6 @@ Use regular `umount <MOUNTPOINT>` to unmount the FS.
 The server will be automatically stopped when the FS is unmounted.
 
 - `-o|--options <OPT>` - Pass additional NFS mount options (ex.: -o async).
-- `--readahead <SIZE>` - Set Linux FS readahead to `<SIZE>`. Default is 128 KB, larger values increase sequential read speed (for example, try `--readahead 2M`).
 
 ### start
 
@@ -312,31 +249,6 @@ Options:
 | `--include-empty`          | Include old and empty volumes; make sure to restart NFS servers before using it |
 | `--no-rm`                  | Move, but do not delete data                                            |
 
-## Mounting from /etc/fstab
-
-Vitastor packages include mount helpers for `/etc/fstab`: **/usr/sbin/mount.vitastorfs** and **/usr/sbin/mount.vitastorblk**.
-
-Both are simple symbolic links to `vitastor-nfs` and allow to handle `mount` calls correctly.
-
-Example `/etc/fstab` entries:
-
-```
-myfs /S vitastorfs pool=fspool,readahead=2M,--etcd_address=10.0.2.15:2379,soft,sync 0 0
-none /mnt/vitastor-block vitastorblk pool=ecpool 0 0
-```
-
-When you run `mount /S`, the helper is called internally and starts VitastorFS.
-Helper call syntax is:
-
-```
-mount.vitastorfs <FSNAME> <MOUNTPOINT> -o <OPTS>
-```
-
-`<OPTS>` is comma-separated and includes all mount options from fstab. You can include
-both Vitastor and NFS mount options in it. An option is treated as an NFS option if it
-does not start with `--`, `pool=`, `readahead=` or if it doesn't contain `=` or `_`.
-Other options are treated as Vitastor options.
-
 ## Common options
 
 | <!-- -->           | <!-- -->                                                 |
@@ -350,4 +262,3 @@ Other options are treated as Vitastor options.
 | `--logfile <FILE>` | log to the specified file                                |
 | `--enforce 1`      | enforce permissions at the server side (no by default)   |
 | `--foreground 1`   | stay in foreground, do not daemonize                     |
-| `--trace`          | trace all NFS requests                                   |

docs/usage/nfs.ru.md

@@ -8,27 +8,15 @@
 
 В Vitastor есть две реализации файловой системы. Обе используются через `vitastor-nfs`.
 
+Команды:
+- [mount](#mount)
+- [start](#start)
+- [upgrade](#upgrade)
+- [defrag](#defrag)
+
 ⚠️ Важно: для оптимальной производительности Vitastor NFS в Linux при использовании
 HDD и EC (erasure кодов) выполните инструкции из раздела [Размер записи Linux NFS](#размер-записи-linux-nfs).
 
-- [Псевдо-ФС](#псевдо-фс)
-- [VitastorFS](#vitastorfs)
-  - [Поддерживаемые функции POSIX](#поддерживаемые-функции-posix)
-  - [Ограничения](#ограничения)
-- [NFS в Linux](#nfs-в-linux)
-  - [Безопасность режимов sync и async](#безопасность-режимов-sync-и-async)
-  - [Упреждающее чтение Linux NFS](#упреждающее-чтение-linux-nfs)
-  - [Размер записи Linux NFS](#размер-записи-linux-nfs)
-  - [Горизонтальное масштабирование](#горизонтальное-масштабирование)
-- [RDMA](#rdma)
-- [Команды](#команды)
-  - [mount](#mount)
-  - [start](#start)
-  - [upgrade](#upgrade)
-  - [defrag](#defrag)
-- [Монтирование из /etc/fstab](#монтирование-из-etc-fstab)
-- [Общие опции](#общие-опции)
-
 ## Псевдо-ФС
 
 Упрощённая реализация псевдо-ФС используется для эмуляции файлового доступа к блочным
@@ -54,7 +42,7 @@ vitastor-nfs start --block --etcd_address 192.168.5.10:2379 --portmap 0 --port 2
 Примонтировать ФС, запущенную с такими опциями, можно следующей командой:
 
 ```
-mount server:/ /mnt/ -o port=2050,mountport=2050,nfsvers=3,soft,sync,nolock,tcp
+mount server:/ /mnt/ -o port=2050,mountport=2050,nfsvers=3,soft,nolock,tcp
 ```
 
 ## VitastorFS
@@ -121,58 +109,7 @@ JSON-формате :-). Для инспекции содержимого БД
   записи. ФС устроена так, что на работу они не влияют, но для порядка и их стоит
   уметь подчищать.
 
-## NFS в Linux
-
-NFS в Linux имеет некоторые важные для Vitastor особенности поведения:
-
-### Безопасность режимов sync и async
-
-В Linux NFS есть 2 опции, влияющие на режим монтирования: **soft/hard** и **sync/async**.
-
-**⚠️ Внимание: сочетание soft,async опасно и может приводить к потере данных!**
-
-Логика работы опций:
-
-- В режиме **hard** все запросы к серверу повторяются бесконечно. Если NFS-сервер становится недоступен,
-  отмонтировать ФС становится невозможно до перезагрузки клиентской машины.
-- В режиме **soft** каждый запрос повторяется только 2 раза (значение опции **retrans** по умолчанию для
-  TCP соединений). В этом случае отмонтировать умершую ФС можно.
-- В режиме **sync** все запросы изменения отправляются на сервер сразу. Это медленнее, но зато любую
-  ошибку записи клиент видит сразу.
-- В режиме **async** запросы изменения накапливаются и отправляются на сервер в фоновом режиме, параллельно.
-  Это быстрее, но ошибки записи могут быть незаметны для клиента и вместо ошибки записи клиент может
-  получить ошибку в момент закрытия файла (вызова close()). Помимо этого, в NFS нет нормального способа
-  регулировать параллелизм записи, поэтому клиент может легко перегружать сервер большим количеством команд.
-
-Именно поэтому режим **soft,async** опасен. При копировании любого большого файла сервер перегружается и
-начинает медленно отвечать. Команды записи заканчиваются таймаутом, soft режим делает 1 повторную попытку,
-после чего забывает команды совсем. Часть блоков файла оказывается просто потерянной.
-
-Резюме: всегда используйте либо режим **soft,sync**, либо **hard,async**. Если опции `vitastor-nfs mount`
-не указаны, режим по умолчанию - **soft,sync**.
-
-### Упреждающее чтение Linux NFS
-
-По умолчанию Linux использует довольно небольшой размер упреждающего чтения для
-файловых систем NFS - 128 КБ.
-
-Для простого чтения/копирования файлов его не достаточно, потому что оно мешает VitastorFS
-нормально утилизировать параллелизм чтения.
-
-Однако, вы можете увеличить эту настройку целыми 3 способами:
-
-1. Встроенной опцией `vitastor-nfs mount --readahead <SIZE>` (например, `--readahead 2M`).
-2. Добавив в секцию `[nfsrahead]` файла конфигурации `/etc/nfs.conf` строку `nfs=2048` (глобальная
-   настройка для всех NFS 3.0 точек монтирования).
-3. Вручную следующей командой: \
-   `echo 2048 > /sys/class/bdi/$(findmnt -no MAJ:MIN /mnt/nfs 2>/dev/null | tr -d ' ')/read_ahead_kb`
-
-Здесь `2048` - размер readahead, а `/mnt/nfs` - путь к вашей ФС.
-
-После увеличения параметра скорость линейного чтения легко может увеличиться в 2-3 раза, так что
-советуем обязательно попробовать!
-
-### Размер записи Linux NFS
+## Размер записи Linux NFS
 
 Клиент Linux NFS (модули ядра nfs/nfsv3/nfsv4) имеет фиксированный в коде максимальный
 размер запроса ввода-вывода, равный 1 МБ - см. `rsize` и `wsize` в [man 5 nfs](https://linux.die.net/man/5/nfs).
@@ -232,7 +169,7 @@ modprobe nfsv3
 монтироваться с новыми wsize и rsize, и производительность линейной записи в Vitastor-NFS
 исправляется.
 
-### Горизонтальное масштабирование
+## Горизонтальное масштабирование
 
 Клиент Linux NFS 3.0 не поддерживает встроенное масштабирование или отказоустойчивость.
 То есть, вы не можете задать несколько адресов серверов при монтировании ФС.
@@ -272,9 +209,6 @@ VitastorFS из GPUDirect.
 Сервер автоматически останавливается при отмонтировании ФС.
 
 - `-o|--options <OPT>` - Передать дополнительные опции монтирования NFS (пример: -o async).
-- `--readahead <SIZE>` - Устанавливает размер упреждающей записи ФС Linux в `<SIZE>`.
-  Значение по умолчанию 128 KB, бОльшие значения значительно улучшают скорость линейного чтения.
-  Попробуйте, например, `--readahead 2M`.
 
 ### start
 
@@ -327,32 +261,6 @@ VitastorFS из GPUDirect.
 | `--include-empty`          | Дефрагментировать старые и пустые тома; обязательно перезапустите NFS-сервера после использования этой опции |
 | `--no-rm`                  | Перемещать, но не удалять данные                                        |
 
-## Монтирование из /etc/fstab
-
-Пакеты Vitastor включают хелперы для монтирования из `/etc/fstab`: **/usr/sbin/mount.vitastorfs** и **/usr/sbin/mount.vitastorblk**.
-
-Оба являются простыми символическими ссылками на `vitastor-nfs` и дают возможность
-корректно обрабатывать вызовы монтирования утилитой `mount`.
-
-Примеры записей `/etc/fstab`:
-
-```
-myfs /S vitastorfs pool=fspool,readahead=2M,--etcd_address=10.0.2.15:2379,soft,sync 0 0
-none /mnt/vitastor-block vitastorblk pool=ecpool 0 0
-```
-
-Когда вы запускаете `mount /S`, внутри вызывается хелпер и запускает VitastorFS.
-Синтаксис вызова самого хелпера:
-
-```
-mount.vitastorfs <FSNAME> <MOUNTPOINT> -o <OPTS>
-```
-
-`<OPTS>` - это набор опций, разделённых запятой, и в нём передаются все опции
-монтирования из fstab. В него можно включать и опции Vitastor, и опции NFS. Опция
-считается опцией NFS, если она не начинается с `--`, `pool=` и `readahead=`, а также
-если она не содержит `=` или `_`. Все прочие опции считаются опциями Vitastor.
-
 ## Общие опции
 
 | <!-- -->           | <!-- -->                                                |
@@ -366,4 +274,3 @@ mount.vitastorfs <FSNAME> <MOUNTPOINT> -o <OPTS>
 | `--logfile <FILE>` | записывать логи в заданный файл                         |
 | `--enforce 1`      | проверять права доступа на стороне сервера (по умолчанию нет) |
 | `--foreground 1`   | не уходить в фон после запуска                          |
-| `--trace`          | логгировать все запросы NFS                             |

docs/usage/security.en.md

@@ -1,665 +0,0 @@
-[Documentation](../../README.md#documentation) → Usage → Security in Vitastor
-
------
-
-[Читать на русском](security.ru.md)
-
-# Security in Vitastor
-
-- [Overview](#overview)
-- [Quick setup](#quick-setup)
-- Principles of operation
-  - [etcd transport encryption (TLS)](#etcd-transport-encryption-tls)
-  - [OSD transport encryption (AES-GCM)](#osd-transport-encryption-aes-gcm)
-  - [End-to-end image data encryption (AES-XTS)](#end-to-end-image-data-encryption-aes-xts)
-  - [Certificate-based authentication](#certificate-based-authentication)
-  - [Users and access rights](#users-and-access-rights)
-  - [etcd privileges](#etcd-privileges)
-- Manual setup
-  - [Configuring OSD transport encryption](#configuring-osd-transport-encryption)
-  - etcd/Antietcd setup options
-    - [Mon with embedded Antietcd](#mon-with-embedded-antietcd)
-    - [Mon as an Etcd proxy](#mon-as-an-etcd-proxy)
-    - [Mon with a separate Antietcd Proxy](#mon-with-a-separate-antietcd-proxy)
-    - [Standalone Antietcd without etcd](#standalone-antietcd-without-etcd)
-  - [Vault/OpenBao setup](#vaultopenbao-setup)
-    - [Vault setup example](#vault-setup-example)
-- Lists of allowed operations
-  - [etcd data access rights](#etcd-data-access-rights)
-  - [OSD data access rights](#osd-data-access-rights)
-  - [API access rights](#api-access-rights)
-- [Encryption performance](#encryption-performance)
-
-## Overview
-
-Starting from version 3.1.0, Vitastor provides full data protection:
-control plane protection (etcd), data plane protection (OSDs), and end-to-end data encryption.
-
-- Control plane protection:
-  - etcd transport encryption (TLS)
-  - Authentication via client TLS (X.509) certificates
-  - Access control of clients to etcd data
-- Data plane protection:
-  - Full AES-GCM encryption of OSD transport (similar to TLS, but faster)
-  - Alternatively, AES-GCM encryption of just operation headers with data checksums using a secret "salt"
-  - Authentication via client TLS (X.509) certificates
-  - Access control of clients on the OSD side
-- End-to-end encryption:
-  - Data is encrypted using AES-XTS on the client side, the Vitastor cluster has no access to plaintext data
-  - AES-XTS keys can be stored in etcd or in an external Vault/OpenBao
-
-All features are optional and disabled in the simplest configuration. By default, only
-transport-level data checksums ([proto_checksums](../config/security.en.md#proto_checksums)=payload)
-are enabled for clients that support them (>= 3.1.0). For older clients, connections
-without data checksums are allowed by default ([force_proto_checksums](../config/security.en.md#force_proto_checksums) is empty).
-
-For a quick setup, jump to the [Quick setup](#quick-setup) section.
-
-Descriptions of all security-related parameters can be found [here](../config/security.en.md).
-
-## Quick setup
-
-For a quick setup, use the `/usr/lib/vitastor/mon/make-etcd` script:
-
-1. Log in to the node where the first monitor and etcd will be located.
-2. Create `/etc/vitastor/vitastor.conf` with minimal parameters: etcd_address,
-   osd_network and, if you want to enable privileges, use_perms (note `https://`
-   in etcd addresses):
-   ```
-   {
-       "etcd_address": ["https://10.0.0.10:2379","https://10.0.0.11:2379","https://10.0.0.12:2379"],
-       "osd_network": "10.0.0.0/24",
-       "use_perms": true
-   }
-   ```
-3. Run `/usr/lib/vitastor/mon/make-etcd` without parameters or with the `--antietcd-only`
-   parameter if you want to initialize the cluster with Antietcd only, without etcd.
-4. The script will generate all necessary certificates and offer to copy them to the other
-   monitor nodes. Root ssh access to these nodes is required to do it, so agree if it's
-   available.
-5. If you don't have root ssh access from the first node to other nodes, copy configuration
-   manually (vitastor.conf and all certificates/keys, except CA `*_ca.key`) and call
-   `/usr/lib/vitastor/mon/make-etcd` on every node.
-
-After that, you can proceed with OSD initialization.
-
-If you want to understand the setup in more detail, read the [Principles of operation](#principles-of-operation)
-and [Manual setup](#manual-setup) sections below.
-
-## Principles of operation
-
-### etcd transport encryption (TLS)
-
-Possible setups:
-- Without encryption (http)
-- With encryption (https)
-- With encryption and client certificate authentication. Either the same certificate
-  used for authentication on the OSD side (`cert`+`pkey` / `osd_cert`+`osd_pkey`)
-  is used, or a separately specified certificate (`etcd_client_cert`+`etcd_client_key`).
-
-### OSD transport encryption (AES-GCM)
-
-Possible setups:
-- Unencrypted transport without checksums: `proto_checksums=none`.
-- Unencrypted transport with data checksums: `proto_checksums=payload` (may be omitted,
-  this is the default value). It's allowed to disable checksums on the client side, or
-  use an older client that does not support checksums. If you want to block connections
-  from clients without checksums, use the option `force_proto_checksums=payload`.
-- Header-only encryption with data checksums: activated when the options
-  `cert`, `pkey`, `osd_ca` are set on the client side and `osd_cert`, `osd_pkey`, `osd_ca`, `client_ca`
-  on the OSD side, with `proto_checksums=payload`. In this mode, disabling checksums on the client
-  side is forbidden by default, i.e. `force_proto_checksums=payload` is used.
-- Full transport encryption of all traffic: same as the previous option, but with `proto_checksums=gcm`.
-  In this case, clients are by default allowed to downgrade to checksums only, but this
-  can also be forbidden via `force_proto_checksums=gcm`. This is the slowest setup and
-  it's only recommended for insecure (public) networks. In particular, full traffic
-  encryption together with end-to-end AES-XTS image encryption encrypts data twice.
-
-Encryption uses the AES-256-GCM algorithm and a custom simplified key exchange protocol,
-fully analogous to TLS 1.3 ECDHE.
-
-### End-to-end image data encryption (AES-XTS)
-
-The Vitastor client supports encrypting each image's data with its own key. In this case,
-data is encrypted by the client before sending it to OSDs and OSDs can't see it in plain.
-The encryption key can be changed when cloning/creating image snapshots. For example,
-you can make a base VM image (say, Debian Linux) unencrypted, but have encrypted client VM
-images inheriting from it.
-
-Image encryption keys can be stored in etcd or in an external Vault. In the latter case,
-etcd only stores key IDs and Vitastor cluster can't decrypt the data at all. To use
-Vault, create an image with the `--enc_key vault:ID` option, specify vault_url and vault_ca
-options in the configuration, create accounts for all clients in Vault, and grant them access
-to the required v1 secrets.
-
-Once again, if AES-XTS is used together with full traffic encryption (`proto_checksums=gcm`),
-image data is encrypted twice — first with AES-XTS, and then with AES-GCM. Use it only if
-you are completely paranoid :-).
-
-### Certificate-based authentication
-
-When encryption is enabled, Vitastor clients, OSDs, and monitors authenticate via certificates
-for both etcd (Antietcd) and OSD connections.
-
-Separate certificates must be used for OSDs and monitors — either self-signed, or signed
-by separate CAs (`osd_ca` and `mon_ca`). All OSDs can use the same certificate, and all
-monitors can also use the same certificate, since the privileges of different OSDs or
-different monitors do not differ (theoretically, one could differentiate OSD certificates
-by pool, but there has been no need for this so far).
-
-Also, a monitor certificate may not be needed at all if Antietcd is embedded into the monitor
-itself. In this case, the monitor already has access to all etcd data directly in memory.
-
-### Users and access rights
-
-When transport encryption is disabled, Vitastor operates without access control, i.e.,
-any cluster client has full access to both the management layer and the data layer. This
-option is suitable for dedicated trusted storage networks.
-
-When OSD transport encryption is enabled (at least for headers), you can enable access
-control by turning on the `use_perms=true` option. When this option is enabled, each user
-(and even an OSD or a monitor) can perform only operations allowed for him.
-
-Each user, administrator, OSD or monitor must have their own certificate signed by a specific
-root certificate:
-- `client_ca` for regular users. Common Name of the certificate must be equal to the user's
-  name. Regular users can only read and modify explicitly permitted images and can't modify
-  cluster state.
-- `admin_ca` for administrators. Administrators can read and modify all images, and also
-  adminster the cluster: view overall statistics and status, create and delete OSDs, etc.
-  Common Name is not checked for admin users.
-- `osd_ca` for OSDs and `mon_ca` for monitors (if Antietcd runs separately). OSDs and monitors
-  also have distinct permission sets.
-
-User privileges for regular users are stored in etcd data and currently consist of only
-one property in `/vitastor/config/user/<name>`:
-- `groups` - List of group names the user is a member of.
-
-Images have the following properties:
-- Owner (`owner`) — the user name that is allowed to both read and modify the image
-- Owner group (`owner_group`) — the owner group name
-- Reader group (`reader_group`) — the name of the group of users allowed to read the image
-
-And there is also a property on the pool:
-- Creator group (`creator_group`) — the name of the group of users allowed to create images in the pool
-
-For the list of allowed operations on image data on the OSD side, see the
-[OSD data access rights](#osd-data-access-rights) section.
-
-### etcd privileges
-
-etcd privileges are implemented through Antietcd in all modes of operation.
-
-Built-in etcd privileges are not supported due to numerous inconveniences:
-- Certificate-based authentication does not work at all in etcd's REST interface,
-- Privileges are stored separately from k/v data and cannot participate in transactions,
-- Only the administrator (root) can change privileges,
-- There is no support for filtering range read responses by privileges.
-
-If etcd is used, Antietcd acts as a filtering proxy and can be embedded in the Vitastor
-monitor or run separately. In this case, etcd must allow incoming connections only from
-Antietcd, and all other components must connect to Antietcd.
-
-If Antietcd runs as a part of the Vitastor monitor, it is sufficient to enable the option
-`use_perms=true` and set the required certificates. If Antietcd is run separately, privileges
-have to be enabled separately using Antietcd options. For more details on the setup, see
-the [etcd/Antietcd setup options](#etcdantietcd-setup-options) section.
-
-For the list of allowed operations with etcd data, see the
-[etcd data access rights](#etcd-data-access-rights) section.
-
-## Manual setup
-
-### Configuring OSD transport encryption
-
-You need 3 certificates: one for OSDs, one for signing client certificates and one for
-signing administrator certificates. For OSDs, you can use a self-signed certificate (osd_ca.crt)
-or a separate certificate (osd.crt) signed by a trusted osd_ca.crt certificate. For clients,
-you must use separate certificates signed by a common CA certificate (client_ca.crt). One more
-CA certificate (admin_ca.crt) is required for signing administrator certificates.
-
-Add to the Vitastor configuration on OSD servers:
-- use_perms: true
-- osd_ca: osd_ca.crt
-- client_ca: client_ca.crt
-- admin_ca: admin_ca.crt
-- osd_cert: osd_ca.crt
-- osd_pkey: osd_ca.key
-
-On the client side:
-- use_perms: true
-- cert: client.crt
-- pkey: client.key
-
-### etcd/Antietcd setup options
-
-The following configuration options are available:
-
-#### Mon with embedded Antietcd
-
-The simplest option. Apart from OSD certificates, you only need 1 certificate for Antietcd (antietcd.crt).
-
-Vitastor settings (`/etc/vitastor/vitastor.conf`):
-- etcd_address: [ "http://mon1:2379", ... ] (addresses of your monitors with port 2379)
-- use_perms: true
-- use_antietcd: true
-- antietcd_cert: antietcd.crt
-- antietcd_key: antietcd.key
-- etcd_ca: antietcd.crt
-- osd_ca: osd_ca.crt
-- client_ca: client_ca.crt
-- admin_ca: admin_ca.crt
-
-#### Mon as an Etcd proxy
-
-If you want to enable privileges, but stay on etcd, you can use etcd proxy mode.
-
-You will need 2 separate certificates: one for etcd (etcd.crt) and one for antietcd (antietcd.crt).
-The etcd client port must be different from the standard 2379 — for example, you can pick 2381.
-
-Vitastor settings:
-- etcd_address: [ "http://mon1:2379", ... ] (addresses of your monitors with port 2379)
-- use_perms: true
-- use_antietcd: true
-- etcd_proxy:
-  ```
-  {
-    "urls": [ "http://mon1:2381", ... ], // addresses of your etcd with port 2381
-    "cert": "antietcd.crt",
-    "key": "antietcd.key",
-    "ca": "etcd.crt"
-  }
-  ```
-- antietcd_cert: antietcd.crt
-- antietcd_key: antietcd.key
-- etcd_ca: antietcd.crt
-- osd_ca: osd_ca.crt
-- client_ca: client_ca.crt
-- admin_ca: admin_ca.crt
-
-etcd command-line options:
-```
---advertise-client-urls=https://<ADDRESS>:2381 --listen-client-urls=https://<ADDRESS>:2381 \
---client-cert-auth --cert-file=etcd.crt --key-file=etcd.key --trusted-ca-file=antietcd.crt \
---peer-client-cert-auth --peer-cert-file=etcd.crt --peer-key-file=etcd.key --peer-trusted-ca-file=etcd.crt
-```
-
-#### Mon with a separate Antietcd Proxy
-
-If in addition to the previous option you want to offload Vitastor monitor's tasks from Antietcd,
-you can run it separately.
-
-Similar to the previous option, 2 certificates are needed: one for etcd and one for antietcd,
-plus a separate certificate for the monitor.
-
-Vitastor settings:
-- etcd_address: [ "http://mon1:2379", ... ] (addresses of your monitors with port 2379)
-- use_perms: true
-- use_antietcd: false
-- etcd_ca: antietcd.crt
-- osd_ca: osd_ca.crt
-- client_ca: client_ca.crt
-- admin_ca: admin_ca.crt
-- mon_etcd_client_cert: mon_ca.crt
-- mon_etcd_client_key: mon_ca.key
-
-Antietcd command-line options:
-```
---port 2379 --cert /etc/vitastor/antietcd.crt --key /etc/vitastor/antietcd.key \
---client_cert_auth 1 --auth_filter /usr/lib/vitastor/mon/vitastor_auth_filter.js \
---ca /etc/vitastor/client_ca.crt --admin_ca /etc/vitastor/admin_ca.crt \
---osd_ca /etc/vitastor/osd_ca.crt --mon_ca /etc/vitastor/mon_ca.crt \
---etcd_proxy url1,url2,... --etcd_ca /etc/vitastor/etcd.crt \
---etcd_cert /etc/vitastor/antietcd.crt --etcd_key /etc/vitastor/antietcd.key
-```
-
-etcd command-line options (same as in the previous option):
-```
---advertise-client-urls=https://<ADDRESS>:2381 --listen-client-urls=https://<ADDRESS>:2381 \
---client-cert-auth --cert-file=etcd.crt --key-file=etcd.key --trusted-ca-file=antietcd.crt \
---peer-client-cert-auth --peer-cert-file=etcd.crt --peer-key-file=etcd.key --peer-trusted-ca-file=etcd.crt
-```
-
-#### Standalone Antietcd without etcd
-
-Same as the previous option, but etcd and its certificate are not needed:
-
-Vitastor settings (same as in the previous option):
-- etcd_address: [ "http://mon1:2379", ... ] (addresses of your monitors with port 2379)
-- use_perms: true
-- use_antietcd: false
-- etcd_ca: antietcd.crt
-- osd_ca: osd_ca.crt
-- client_ca: client_ca.crt
-- admin_ca: admin_ca.crt
-- mon_etcd_client_cert: mon_ca.crt
-- mon_etcd_client_key: mon_ca.key
-
-Antietcd command-line options:
-```
---port 2379 --cert /etc/vitastor/antietcd.crt --key /etc/vitastor/antietcd.key \
---client_cert_auth 1 --auth_filter /usr/lib/vitastor/mon/vitastor_auth_filter.js \
---ca /etc/vitastor/client_ca.crt --admin_ca /etc/vitastor/admin_ca.crt \
---osd_ca /etc/vitastor/osd_ca.crt --mon_ca /etc/vitastor/mon_ca.crt \
---persist_filter /usr/lib/vitastor/mon/vitastor_persist_filter.js
-```
-
-### Vault/OpenBao setup
-
-To use Vault, each client that needs to get image keys from Vault needs a Vault account.
-Vitastor only supports client certificate-based authentication, so all client certificates
-(`cert`+`pkey`) must be registered in Vault, and they must be granted access to the
-corresponding secrets (v1 secrets API is supported).
-
-The required format of a Vault secret is a single `key` field as a hexadecimal string.
-The AES-256-XTS algorithm is used, so the key length is 64 bytes, i.e., the string must
-consist of 128 hexadecimal digits.
-
-To connect to Vault, set the following settings in Vitastor.conf:
-- `vault_url` — Vault address (e.g., `https://vault:8200`)
-- `vault_ca` — Vault's own certificate
-
-After that, if you create an image (`vitastor-cli create`) with the option `--enc_key vault:<ID>`,
-Vitastor clients will first contact Vault to obtain a token at `/v1/auth/cert/login`,
-and then request the actual secret from Vault at `/v1/secret/<ID>`.
-
-#### Vault setup example
-
-Step-by-step instructions for setting up a test Vault using OpenBao as an example:
-
-1. If TLS is not yet configured, generate a self-signed TLS certificate for Vault:
-   ```
-   openssl req -days 3650 -x509 -addext basicConstraints=critical,CA:TRUE,pathlen:1 --addext subjectAltName=DNS:vault \
-       -new -newkey rsa:4096 -nodes -keyout /etc/openbao/vault.key -out /etc/openbao/vault.crt
-   ```
-   Configure it in `/etc/openbao/openbao.hcl`:
-   ```
-   listener "tcp" {
-       address       = "0.0.0.0:8200"
-       tls_cert_file = "/etc/openbao/vault.crt"
-       tls_key_file  = "/etc/openbao/vault.key"
-   }
-   ```
-   And restart OpenBao (`systemctl restart openbao`).
-2. Copy Vault's TLS certificate for Vitastor:
-   ```
-   cp /etc/openbao/vault.crt /etc/vitastor/vault.crt
-   ```
-   Transfer it to all client nodes and specify it in `/etc/vitastor/vitastor.conf`:
-   ```
-   {
-       ...
-       "vault_url": "http://vault:8200",
-       "vault_ca": "/etc/vitastor/vault.crt"
-   }
-   ```
-3. Check Vault status:
-   ```
-   bao status -ca-cert /etc/openbao/vault.crt -address=https://vault:8200
-   ```
-4. Initialize Vault in test mode from 1 node (with 1 key share):
-   ```
-   bao operator init -n 1 -t 1 -ca-cert /etc/openbao/vault.crt -address=https://vault:8200
-   ```
-5. Unseal Vault:
-   ```
-   bao operator unseal -ca-cert /etc/openbao/vault.crt -address=https://vault:8200
-   ```
-6. Enable certificate-based authentication:
-   ```
-   bao auth enable -ca-cert /etc/openbao/vault.crt -address=https://vault:8200 cert
-   ```
-7. Enable v1 secrets:
-   ```
-   bao secrets enable -ca-cert /etc/openbao/vault.crt -address=https://vault:8200 -path=secret kv-v1
-   ```
-8. Create a test secret:
-   ```
-   bao kv put -ca-cert /etc/openbao/vault.crt -address=https://vault:8200 secret/vitastor/testimg3 key=$(openssl rand -hex 64)
-   ```
-9. Generate a signed certificate for a Vitastor user (on a machine where you have `client_ca.crt` and `client_ca.key`):
-   ```
-   openssl req -subj '/CN=testimg3' -nodes -new -keyout testimg3.key -out testimg3.csr
-   openssl x509 -req -days 3650 -CA client_ca.crt -CAkey client_ca.key -CAcreateserial -in testimg3.csr -out testimg3.crt
-   rm testimg3.csr
-   ```
-10. Create a user in Vault and grant it access to the secret:
-    ```
-    cat >testimg3.policy <<EOF
-    path "/secret/vitastor/testimg3" {
-        capabilities = ["read"]
-    }
-    EOF
-
-    bao policy write -ca-cert /etc/openbao/vault.crt -address=https://vault:8200 testimg3 testimg3.policy
-
-    bao write -ca-cert /etc/openbao/vault.crt -address=https://vault:8200 auth/cert/certs/testimg3 \
-        certificate=@testimg3.crt display_name=testimg3 token_ttl=24h token_policies=testimg3
-    ```
-11. Test access to the secret:
-    ```
-    curl --cacert /etc/vitastor/vault.crt --cert testimg3.crt --key testimg3.key \
-        --json '{}' https://vault:8200/v1/auth/cert/login
-    ```
-    A token will be printed, substitute it into the following request:
-    ```
-    curl --cacert /etc/vitastor/vault.crt --cert testimg3.crt --key testimg3.key \
-        -H 'X-Vault-Token: <RECEIVED TOKEN>' https://vault:8200/v1/secret/vitastor/testimg3
-    ```
-12. Create an image in Vitastor with the given secret (as an administrator or someone who
-    has the right to create images in your pool):
-    ```
-    vitastor-cli create -s 100G --enc_key vault:vitastor/testimg3 --owner testimg3 testimg3
-    ```
-13. Test access to the image as user testimg3:
-    ```
-    vitastor-cli --cert testimg3.crt --pkey testimg3.key dd if=/dev/urandom oimg=testimg3 bs=1M count=100
-    ```
-
-## Lists of allowed operations
-
-### etcd data access rights
-
-Below, all key names are given without the common prefix `/vitastor`.
-
-Allowed operations with keys in Antietcd for regular users:
-- Read-only:
-  - Always allowed:
-    - `/config/global`
-    - `/config/node_placement`
-    - `/config/pools`
-    - `/pg/config`
-    - `/osd/state/*`
-    - `/pg/state/*`
-    - `/index/maxid/*`
-  - For images [readable by the user](#users-and-access-rights):
-    - `/config/inode/*`
-    - `/index/image/*`
-    - `/inode/stats/*`
-- Read and write:
-  - For pools in which the user can create images:
-    - `/index/maxid/*`
-  - For images owned by the user:
-    - `/config/inode/*`
-    - `/index/image/*`
-
-Allowed operations with keys in Antietcd for administrators:
-- Read:
-  - `/stats`
-  - `/mon/*`
-  - `/pg/*`
-  - `/pgstats/*`
-  - `/inode/stats/*`
-  - `/pool/stats/*`
-- Read and write:
-  - `/config/*`
-  - `/osd/*`
-  - `/index/*`
-  - `/pg/config`
-  - `/pg/history/*`
-  - `/stats`
-  - `/history/last_clean_pgs`
-
-Allowed operations with keys in etcd for OSDs:
-- Read:
-  - `/pg/config`
-  - `/config/*`
-- Read and write:
-  - `/osd/*`
-  - `/pg/state/*`
-  - `/pg/history/*`
-  - `/pgstats/*`
-
-Allowed operations with keys in etcd for monitors:
-- Read:
-  - `/config/*`
-  - `/osd/*`
-  - `/pgstats/*`
-- Read and write:
-  - `/pg/config`
-  - `/stats`
-  - `/history/last_clean_pgs`
-  - `/mon/*`
-  - `/pg/history/*`
-  - `/pg/stats/*`
-  - `/pgstats/*`
-  - `/inode/stats/*`
-  - `/pool/stats/*`
-
-### OSD data access rights
-
-When the `use_perms` option and encryption are enabled, OSDs authenticate clients via
-certificates and allow each client only what is allowed by the access control model.
-
-Client operations:
-- READ — allowed for images the user has read access to.
-- WRITE, DELETE, SCRUB — allowed for images the user has write access to.
-- SYNC — the operation is not tied to an image and is always allowed.
-- DESCRIBE — the operation is allowed only for administrators (used by the commands
-  `vitastor-cli describe` and `fix`).
-- PING — the operation is always allowed.
-- SHOW_CONFIG — the operation is always allowed, however, if the client presents
-  itself as an OSD in it, then it is verified that it uses a certificate signed by `osd_ca`.
-- SEC_LIST (listing) — allowed for other OSDs and administrators with any parameters,
-  and for regular clients only allowed for requests limited to an image the user has
-  read access to.
-
-Cluster operations — allowed only for other OSDs:
-- SEC_READ
-- SEC_WRITE
-- SEC_WRITE_STABLE
-- SEC_SYNC
-- SEC_STABILIZE
-- SEC_ROLLBACK
-- SEC_DELETE
-- SEC_READ_BMP
-- SEC_LOCK
-
-### API access rights
-
-[vitastor-cli serve](../usage/cli.en.md#serve) also supports client authentication
-via certificates. Only certificates signed by `client_ca` are accepted. A separate
-certificate `api_cert` with the key `api_pkey` is used as the server certificate.
-
-For `vitastor-cli serve` to work correctly, it must use a certificate of an administrator
-(`cert`+`pkey` signed by `admin_ca`) to access Vitastor and serve all requests correctly.
-
-Regular users (with `client_ca`-signed certificates), when accessing the API, are only
-allowed operations on images available to them either for reading (for read-only operations)
-or for writing (for modification):
-
-- image/list — for images the user can read.
-- image/create — for pools in which the user is allowed to create images, or for
-  creating snapshots of images owned by the user.
-- image/delete, image/flatten, image/modify — for images owned by the user.
-
-All other operations are allowed only for administrators.
-
-## Encryption performance
-
-You may wonder — how fast is all this wonderful encryption?
-
-The answer is — it depends heavily on the CPU. On modern processors (with AVX512 with VAES
-support) it is very fast — AES encryption speed can reach 10-20 GB/s and above. This
-primarily concerns the CPU of client machines, because end-to-end encryption is performed
-entirely on the client, and even though transport encryption runs both on clients and OSDs,
-each client has only one thread, while there are many OSDs on the server side.
-
-On older processors, the speed is noticeably worse — for example, on a Xeon E5 v4 it is
-only 3 GB/s.
-
-You can evaluate the performance of your processors using the `vitastor-cli cpubench` command.
-
-Example output (💪 AMD EPYC 9575F):
-
-```
-$ vitastor-cli cpubench
-Vitastor transport encryption benchmark (AES-256-GCM, AES-256-XTS and xxhash3)
-
-Warmup...
-
-No transport encryption, data checksums enabled, e2e unencrypted image
-xxhash3 1 M block... 209000 iterations in 2001 ms = 104447.78 MB/s
-xxhash3 4 K block... 37000000 iterations in 2022 ms = 71479.35 MB/s
-
-Header encryption with payload checksums, e2e unencrypted image
-AES-256-GCM encrypt header + xxhash3 1 M block... 210000 iterations in 2015 ms = 104218.36 MB/s
-AES-256-GCM encrypt header + xxhash3 4 K block... 26000000 iterations in 2073 ms = 48993.01 MB/s
-
-Full transport encryption, e2e unencrypted image
-AES-256-GCM encrypt header and 1 M block... 54000 iterations in 2000 ms = 27000.00 MB/s
-AES-256-GCM encrypt header and 4 K block... 11700000 iterations in 2014 ms = 22692.71 MB/s
-
-No transport encryption, no checksums, e2e encrypted image
-AES-256-XTS encrypt 1 M block... 50000 iterations in 2039 ms = 24521.82 MB/s
-AES-256-XTS encrypt 4 K block... 12600000 iterations in 2009 ms = 24499.13 MB/s
-
-No transport encryption, e2e encrypted image, data checksums enabled
-AES-256-XTS encrypt + xxhash3 1 M block... 40000 iterations in 2013 ms = 19870.84 MB/s
-AES-256-XTS encrypt + xxhash3 4 K block... 10200000 iterations in 2011 ms = 19812.90 MB/s
-
-Header encryption with payload checksums, e2e encrypted image
-AES-256-GCM encrypt header + AES-256-XTS encrypt + xxhash3 1 M block... 40000 iterations in 2014 ms = 19860.97 MB/s
-AES-256-GCM encrypt header + AES-256-XTS encrypt + xxhash3 4 K block... 8700000 iterations in 2011 ms = 16899.24 MB/s
-
-Full transport encryption, e2e encrypted image
-AES-256-XTS + AES-256-GCM encrypt 1 M block... 26000 iterations in 2062 ms = 12609.12 MB/s
-AES-256-XTS + AES-256-GCM encrypt 4 K block... 6300000 iterations in 2006 ms = 12267.88 MB/s
-```
-
-And here is Xeon E5-2680v4:
-
-```
-$ vitastor-cli cpubench
-Vitastor transport encryption benchmark (AES-256-GCM, AES-256-XTS and xxhash3)
-
-Warmup...
-
-No transport encryption, data checksums enabled, e2e unencrypted image
-xxhash3 1 M block... 62000 iterations in 2021 ms = 30677.88 MB/s
-xxhash3 4 K block... 12400000 iterations in 2006 ms = 24146.31 MB/s
-
-Header encryption with payload checksums, e2e unencrypted image
-AES-256-GCM encrypt header + xxhash3 1 M block... 62000 iterations in 2027 ms = 30587.07 MB/s
-AES-256-GCM encrypt header + xxhash3 4 K block... 6800000 iterations in 2011 ms = 13208.60 MB/s
-
-Full transport encryption, e2e unencrypted image
-AES-256-GCM encrypt header and 1 M block... 7000 iterations in 2317 ms = 3021.15 MB/s
-AES-256-GCM encrypt header and 4 K block... 1500000 iterations in 2102 ms = 2787.52 MB/s
-
-No transport encryption, no checksums, e2e encrypted image
-AES-256-XTS encrypt 1 M block... 7000 iterations in 2317 ms = 3021.15 MB/s
-AES-256-XTS encrypt 4 K block... 1600000 iterations in 2088 ms = 2993.30 MB/s
-
-No transport encryption, e2e encrypted image, data checksums enabled
-AES-256-XTS encrypt + xxhash3 1 M block... 6000 iterations in 2188 ms = 2742.23 MB/s
-AES-256-XTS encrypt + xxhash3 4 K block... 1400000 iterations in 2053 ms = 2663.78 MB/s
-
-Header encryption with payload checksums, e2e encrypted image
-AES-256-GCM encrypt header + AES-256-XTS encrypt + xxhash3 1 M block... 6000 iterations in 2190 ms = 2739.73 MB/s
-AES-256-GCM encrypt header + AES-256-XTS encrypt + xxhash3 4 K block... 1300000 iterations in 2101 ms = 2417.00 MB/s
-
-Full transport encryption, e2e encrypted image
-AES-256-XTS + AES-256-GCM encrypt 1 M block... 4000 iterations in 2666 ms = 1500.38 MB/s
-AES-256-XTS + AES-256-GCM encrypt 4 K block... 800000 iterations in 2113 ms = 1478.94 MB/s
-```

docs/usage/security.ru.md

@@ -1,670 +0,0 @@
-[Документация](../../README-ru.md#документация) → Использование → Безопасность в Vitastor
-
------
-
-[Read in English](security.en.md)
-
-# Безопасность в Vitastor
-
-- [Обзор](#обзор)
-- [Быстрая настройка](#быстрая-настройка)
-- Принципы работы
-  - [Шифрование соединений с etcd (TLS)](#шифрование-соединений-с-etcd-tls)
-  - [Шифрование соединений с OSD (AES-GCM)](#шифрование-соединений-с-osd-aes-gcm)
-  - [Сквозное шифрование данных образов (AES-XTS)](#сквозное-шифрование-данных-образов-aes-xts)
-  - [Аутентификация по сертификатам](#аутентификация-по-сертификатам)
-  - [Пользователи и права доступа](#пользователи-и-права-доступа)
-  - [Привилегии etcd](#привилегии-etcd)
-- Ручная настройка
-  - [Настройка шифрования соединений OSD](#настройка-шифрования-соединений-osd)
-  - Варианты настройки etcd/Antietcd
-    - [Mon со встроенным Antietcd](#mon-со-встроенным-antietcd)
-    - [Mon в роли Etcd proxy](#mon-в-роли-etcd-proxy)
-    - [Mon с отдельным Antietcd Proxy](#mon-с-отдельным-antietcd-proxy)
-    - [Отдельный Antietcd без etcd](#отдельный-antietcd-без-etcd)
-  - [Настройка Vault/OpenBao](#настройка-vaultopenbao)
-    - [Пример настройки Vault](#пример-настройки-vault)
-- Списки разрешённых операций
-  - [Права доступа к данным etcd](#права-доступа-к-данным-etcd)
-  - [Права доступа к данным OSD](#права-доступа-к-данным-osd)
-  - [Права доступа к API](#права-доступа-к-api)
-- [Производительность шифрования](#производительность-шифрования)
-
-## Обзор
-
-Начиная с версии 3.1.0, Vitastor предоставляет полную защиту данных: защиту слоя
-управления (etcd), защиту слоя данных (OSD) и сквозное шифрование данных.
-
-- Защита слоя управления:
-  - Шифрование соединений с etcd (TLS)
-  - Аутентификация по клиентским TLS (X.509) сертификатам
-  - Контроль доступа клиентов к данным etcd
-- Защита слоя данных:
-  - Либо полное AES-GCM шифрование соединений с OSD (аналогично TLS, но быстрее)
-  - Либо шифрование AES-GCM только заголовков команд с контрольными суммами данных с секретной "солью"
-  - Аутентификация по клиентским TLS (X.509) сертификатам
-  - Контроль доступа клиентов на стороне OSD
-- Сквозное шифрование:
-  - Данные шифруются AES-XTS на стороне клиента, кластер Vitastor не имеет доступа к открытым данным
-  - Ключи AES-XTS могут храниться в etcd или во внешнем Vault/OpenBao
-
-Все функции опциональны и в простейшем варианте настройки выключены. По умолчанию включены
-только контрольные суммы данных на транспортном уровне ([proto_checksums](../config/security.ru.md#proto_checksums)=payload) для
-поддерживающих их клиентов (>= 3.1.0). Для более старых клиентов по умолчанию разрешены
-соединения без контрольных сумм данных ([force_proto_checksums](../config/security.ru.md#force_proto_checksums) пусто).
-
-Для быстрой настройки перейдите к разделу [Быстрая настройка](#быстрая-настройка).
-
-Описания всех параметров, связанных с безопасностью, читайте [здесь](../config/security.ru.md).
-
-## Быстрая настройка
-
-Для быстрой настройки используйте скрипт `/usr/lib/vitastor/mon/make-etcd`:
-
-1. Зайдите на узел, на котором будет располагаться первый монитор и etcd.
-2. Создайте там минимальный `/etc/vitastor/vitastor.conf` с параметрами etcd_address,
-   osd_network и, если хотите включить привилегии - use_perms (обратите внимание на `https://`
-   в адресах etcd):
-   ```
-   {
-       "etcd_address": ["https://10.0.0.10:2379","https://10.0.0.11:2379","https://10.0.0.12:2379"],
-       "osd_network": "10.0.0.0/24",
-       "use_perms": true
-   }
-   ```
-3. Запустите `/usr/lib/vitastor/mon/make-etcd` без параметров или с параметром `--antietcd-only`,
-   если хотите инициализировать кластер только с Antietcd без etcd.
-4. Скрипт сгенерирует все необходимые сертификаты и предложит скопировать их на остальные узлы
-   мониторов. Для этого нужен root ssh доступ к этим узлам. Если он есть - соглашайтесь, скрипт
-   автоматически скопирует конфигурацию и инициализирует все etcd и мониторы.
-5. Если root ssh доступа с первого узла на остальные узлы мониторов нет - скопируйте на них конфигурацию
-   вручную (vitastor.conf и все сертификаты и ключи, кроме ключей CA `*_ca.key`) и повторите на каждом
-   узле вызов `/usr/lib/vitastor/mon/make-etcd`.
-
-После этого можете переходить к инициализации OSD.
-
-Если хотите разобраться в настройке подробнее, читайте далее разделы [Принципы работы](#принципы-работы)
-и [Ручная настройка](#ручная-настройка).
-
-## Принципы работы
-
-### Шифрование соединений с etcd (TLS)
-
-Варианты настройки:
-- Без шифрования (http)
-- С шифрованием (https)
-- С шифрованием и аутентификацией по клиентским сертификатам. Используется либо тот
-  же сертификат, что используется для аутентификации на стороне OSD (`cert`+`pkey` / `osd_cert`+`osd_pkey`),
-  либо отдельно указанный сертификат (`etcd_client_cert`+`etcd_client_key`)
-
-### Шифрование соединений с OSD (AES-GCM)
-
-Варианты настройки:
-- Без шифрования и без контрольных сумм: `proto_checksums=none`.
-- Без шифрования, с контрольными суммами данных: `proto_checksums=payload` (можно не указывать,
-  т.к. это значение по умолчанию). При этом контрольные суммы можно отключить на стороне
-  клиента и можно использовать более старые версии клиента, не поддерживающие контрольные суммы.
-  Если нужно запретить подключение клиентов без контрольных сумм, можно использовать опцию
-  `force_proto_checksums=payload`.
-- С шифрованием заголовков и контрольными суммами данных: активируется при установленных опциях
-  `cert`, `pkey`, `osd_ca` на стороне клиента и `osd_cert`, `osd_pkey`, `osd_ca`, `client_ca`
-  на стороне OSD, при `proto_checksums=payload`. При этом по умолчанию запрещается
-  отключение контрольных сумм на уровне клиента, то есть используется `force_proto_checksums=payload`.
-- С полным шифрованием всего трафика: аналогично прошлому варианту, но с `proto_checksums=gcm`.
-  Клиенту при этом по умолчанию разрешается понизить уровень защиты до контрольных сумм, но
-  это тоже можно запретить через `force_proto_checksums=gcm`. Данный вариант самый медленный и
-  рекомендуется только для небезопасных (публичных) сетей. В том числе потому, что при использовании
-  и полного шифрования трафика, и сквозного шифрования образов AES-XTS, данные шифруются дважды.
-
-Для шифрования используется алгоритм AES-256-GCM и собственный упрощённый протокол согласования
-ключей, полностью аналогичный TLS 1.3 ECDHE.
-
-### Сквозное шифрование данных образов (AES-XTS)
-
-Клиент Vitastor поддерживает шифрование данных каждого образа своим ключом. В этом случае на OSD
-уходят уже зашифрованные данные и сами OSD не видят исходные данные клиента. При этом ключ можно
-менять при клонировании/создании снимков образов. Например, можно сделать базовый образ ВМ
-(условный Debian Linux) нешифрованным, но наследовать от него шифрованные образы клиентских ВМ.
-
-Ключи шифрования образов могут храниться либо в etcd, либо во внешнем Vault. Во втором случае
-в etcd хранятся только ID ключей, а Vitastor вообще не имеет доступа к данным образов. Для
-использования Vault нужно создать образ с опцией `--enc_key vault:ID`, в конфигурации указать
-опции vault_url и vault_ca, создать всем клиентам учётные записи в Vault и дать им доступ
-к требуемым секретам v1.
-
-Ещё раз повторимся, что если AES-XTS используется с полным шифрованием трафика (`proto_checksums=gcm`),
-то данные образов шифруются дважды - сначала AES-XTS, а потом AES-GCM. Можете использовать,
-только если вы совсем параноик :-).
-
-### Аутентификация по сертификатам
-
-При включённом шифровании клиенты, OSD и мониторы Vitastor аутентифицируются по сертификатам
-как при соединениях с etcd (Antietcd), так и с OSD.
-
-Для OSD и мониторов должны использоваться отдельные сертификаты - либо самоподписанные, либо
-подписанные отдельными CA (`osd_ca` и `mon_ca`). При этом все OSD могут использовать один и
-тот же сертификат и все мониторы тоже могут использовать один и тот же сертификат, так как
-привилегии разных OSD или разных мониторов ничем не отличаются (теоретически можно было бы
-сделать разграничение сертификатов OSD по пулам, но пока что такой необходимости не было).
-
-Также сертификат монитора может быть вообще не нужен, если Antietcd встраивается в сам монитор.
-В этом случае монитор и так имеет доступ ко всем данным etcd прямо в памяти.
-
-### Пользователи и права доступа
-
-При отключённом шифровании трафика Vitastor работает без контроля доступа, то есть,
-любой клиент кластера имеет полный доступ как к слою управлению, так и к слою данных. Такой
-вариант подходит для выделенных доверенных сетей хранения.
-
-При включённом шифровании трафика OSD (хотя бы заголовков) есть возможность задействовать
-контроль доступа, включив опцию `use_perms=true`. При включённой опции каждый пользователь
-(и даже OSD и монитор) может выполнять только те операции, которые ему разрешены.
-
-Каждый обычный пользователь, администратор, OSD или монитор должен иметь свой сертификат,
-подписанный отдельным корневым сертификатом:
-- Для обычных пользователей - `client_ca`. Common Name сертификата при этом должен быть равен
-  имени пользователя. Обычные пользователи могут только читать и модифицировать явным образом
-  разрешённые им образы и не могут менять общее состояние кластера.
-- Для администраторов - `admin_ca`. Администраторы могут читать и модифицировать все образы,
-  а также администрировать кластер: смотреть общую статистику и состояние, создавать и удалять
-  OSD и так далее.
-- Для OSD - `osd_ca`, для мониторов - `mon_ca` (если Antietcd запускаются отдельно от мониторов).
-  OSD и мониторы тоже имеют свои наборы разрешённых операций.
-
-Настройки привилегий для обычных пользователей хранятся в etcd и на данный момент состоят
-всего из одного свойства в ключах `/vitastor/config/user/<имя>`:
-- `groups` - Список имён групп, членом которых пользователь является.
-
-У образов есть следующие свойства:
-- Владелец (`owner`) - имя пользователя, которому разрешено и читать, и менять образ
-- Группа владельцев (`owner_group`) - имя группы владельцев
-- Группа читателей (`reader_group`) - имя группы пользователей, которым разрешено читать образ
-
-И также есть свойство у пула:
-- Группа создателей (`creator_group`) - имя группы пользователей, которым разрешено создавать образы в пуле
-
-Перечень разрешённых операций с данными образов на стороне OSD смотрите в разделе
-[Права доступа к данным OSD](#права-доступа-к-данным-osd).
-
-### Привилегии etcd
-
-Привилегии etcd реализуются через Antietcd во всех режимах работы.
-
-Встроенные привилегии etcd не поддерживаются по причине их многочисленных неудобств:
-- Аутентификация по сертификатам вообще не работает в REST интерфейсе etcd,
-- Привилегии хранятся отдельно от k/v данных и не могут участвовать в транзакциях,
-- Менять привилегии может только администратор (root),
-- Нет поддержки фильтрации диапазонных ответов чтения по привилегиям.
-
-Если используется etcd, то Antietcd выступает в роли фильтрующего прокси, при этом он
-может быть встроен в монитор Vitastor или запущен отдельно. В этом случае etcd должен
-разрешать входящие подключения только от Antietcd, а все остальные компоненты должны
-соединяться с Antietcd.
-
-Если Antietcd запускается в составе монитора Vitastor, то достаточно включить опцию
-`use_perms=true` и задать нужные сертификаты. Если Antietcd запускается отдельно, то
-привилегии нужно включать отдельно опциями Antietcd. Подробнее о настройке смотрите
-раздел [Варианты настройки etcd/Antietcd](#варианты-настройки-etcdantietcd).
-
-Перечень разрешённых операций с данными etcd смотрите в разделе
-[Права доступа к данным etcd](#права-доступа-к-данным-etcd).
-
-## Ручная настройка
-
-### Настройка шифрования соединений OSD
-
-Вам нужно 3 сертификата: один для OSD и по одному для подписи сертификатов клиентов и администраторов.
-Для OSD можно использовать самоподписанный сертификат (osd_ca.crt) или отдельный сертификат (osd.crt),
-подписанный доверенным сертификатом osd_ca.crt. Для клиентов нужно использовать отдельные
-сертификаты, подписанные общим доверенным (client_ca.crt), для администраторов - отдельным доверенным
-(admin_ca.crt).
-
-В конфигурацию Vitastor на серверах OSD нужно добавить:
-- use_perms: true
-- osd_ca: osd_ca.crt
-- client_ca: client_ca.crt
-- admin_ca: admin_ca.crt
-- osd_cert: osd_ca.crt
-- osd_pkey: osd_ca.key
-
-На стороне клиентов:
-- use_perms: true
-- osd_ca: osd_ca.crt
-- cert: client.crt
-- pkey: client.key
-
-### Варианты настройки etcd/Antietcd
-
-Доступны следующие варианты настройки:
-
-#### Mon со встроенным Antietcd
-
-Самый простой вариант. Кроме сертификатов OSD вам нужен всего 1 сертификат для Antietcd (antietcd.crt).
-
-Настройки Vitastor (`/etc/vitastor/vitastor.conf`):
-- etcd_address: [ "http://mon1:2379", ... ] (адреса ваших мониторов с портом 2379)
-- use_perms: true
-- use_antietcd: true
-- antietcd_cert: antietcd.crt
-- antietcd_key: antietcd.key
-- etcd_ca: antietcd.crt
-- osd_ca: osd_ca.crt
-- client_ca: client_ca.crt
-- admin_ca: admin_ca.crt
-
-#### Mon в роли Etcd proxy
-
-Если вы хотите включить привилегии, но остаться на etcd, можно задействовать режим etcd proxy.
-
-Вам понадобится 2 отдельных сертификата: один для etcd (etcd.crt) и один для antietcd (antietcd.crt).
-Клиентский порт etcd должен отличаться от стандартного 2379, например, можно выбрать 2381.
-
-Настройки Vitastor:
-- etcd_address: [ "http://mon1:2379", ... ] (адреса ваших мониторов с портом 2379)
-- use_perms: true
-- use_antietcd: true
-- etcd_proxy:
-  ```
-  {
-    "urls": [ "http://mon1:2381", ... ], // адреса ваших etcd с портом 2381
-    "cert": "antietcd.crt",
-    "key": "antietcd.key",
-    "ca": "etcd.crt"
-  }
-  ```
-- antietcd_cert: antietcd.crt
-- antietcd_key: antietcd.key
-- etcd_ca: antietcd.crt
-- osd_ca: osd_ca.crt
-- client_ca: client_ca.crt
-- admin_ca: admin_ca.crt
-
-Опции командной строки etcd:
-```
---advertise-client-urls=https://<АДРЕС>:2381 --listen-client-urls=https://<АДРЕС>:2381 \
---client-cert-auth --cert-file=etcd.crt --key-file=etcd.key --trusted-ca-file=antietcd.crt \
---peer-client-cert-auth --peer-cert-file=etcd.crt --peer-key-file=etcd.key --peer-trusted-ca-file=etcd.crt
-```
-
-#### Mon с отдельным Antietcd Proxy
-
-Если в дополнение к предыдущему варианту вы хотите разгрузить Antietcd от задач монитора Vitastor,
-можно запустить его отдельно.
-
-Аналогично предыдущему варианту нужно 2 сертификата: один для etcd и один для antietcd, плюс понадобится
-отдельный сертификат для монитора.
-
-Настройки Vitastor:
-- etcd_address: [ "http://mon1:2379", ... ] (адреса ваших мониторов с портом 2379)
-- use_perms: true
-- use_antietcd: false
-- etcd_ca: antietcd.crt
-- osd_ca: osd_ca.crt
-- client_ca: client_ca.crt
-- admin_ca: admin_ca.crt
-- mon_etcd_client_cert: mon_ca.crt
-- mon_etcd_client_key: mon_ca.key
-
-Опции командной строки Antietcd:
-```
---port 2379 --cert /etc/vitastor/antietcd.crt --key /etc/vitastor/antietcd.key \
---client_cert_auth 1 --auth_filter /usr/lib/vitastor/mon/vitastor_auth_filter.js \
---ca /etc/vitastor/client_ca.crt --admin_ca /etc/vitastor/admin_ca.crt \
---osd_ca /etc/vitastor/osd_ca.crt --mon_ca /etc/vitastor/mon_ca.crt \
---etcd_proxy url1,url2,... --etcd_ca /etc/vitastor/etcd.crt \
---etcd_cert /etc/vitastor/antietcd.crt --etcd_key /etc/vitastor/antietcd.key
-```
-
-Опции командной строки etcd (не отличаются от предыдущего варианта):
-```
---advertise-client-urls=https://<АДРЕС>:2381 --listen-client-urls=https://<АДРЕС>:2381 \
---client-cert-auth --cert-file=etcd.crt --key-file=etcd.key --trusted-ca-file=antietcd.crt \
---peer-client-cert-auth --peer-cert-file=etcd.crt --peer-key-file=etcd.key --peer-trusted-ca-file=etcd.crt
-```
-
-#### Отдельный Antietcd без etcd
-
-Аналогично предыдущему варианту, но etcd и его сертификат не нужны:
-
-Настройки Vitastor (не отличаются от предыдущего варианта):
-- etcd_address: [ "http://mon1:2379", ... ] (адреса ваших мониторов с портом 2379)
-- use_perms: true
-- use_antietcd: false
-- etcd_ca: antietcd.crt
-- osd_ca: osd_ca.crt
-- client_ca: client_ca.crt
-- admin_ca: admin_ca.crt
-- mon_etcd_client_cert: mon_ca.crt
-- mon_etcd_client_key: mon_ca.key
-
-Опции командной строки Antietcd:
-```
---port 2379 --cert /etc/vitastor/antietcd.crt --key /etc/vitastor/antietcd.key \
---client_cert_auth 1 --auth_filter /usr/lib/vitastor/mon/vitastor_auth_filter.js \
---ca /etc/vitastor/client_ca.crt --admin_ca /etc/vitastor/admin_ca.crt \
---osd_ca /etc/vitastor/osd_ca.crt --mon_ca /etc/vitastor/mon_ca.crt \
---persist_filter /usr/lib/vitastor/mon/vitastor_persist_filter.js
-```
-
-### Настройка Vault/OpenBao
-
-Для использования Vault каждому клиенту, который будет получать из Vault ключи
-образов, нужна учётная запись в Vault. Vitastor поддерживает только аутентификацию
-по клиентским сертификатам, так что все сертификаты клиентов (`cert`+`pkey`) должны
-быть зарегистрированы в Vault и им должен быть дан доступ к соответствующим секретам
-(поддерживается API секретов v1).
-
-Требуемый формат секрета Vault - одно поле `key` в формате шестнадцатеричной строки.
-Используется алгоритм AES-256-XTS, так что длина ключа - 64 байта, то есть строка
-должна состоять из 128 шестнадцатеричных цифр.
-
-Для подключения Vault включите следующие настройки в Vitastor.conf:
-- `vault_url` - адрес Vault (например, `https://vault:8200`)
-- `vault_ca` - сертификат самого Vault
-
-После этого, если создать образ (`vitastor-cli create`) с опцией `--enc_key vault:<ID>`,
-то для получения ключа клиенты Vitastor сначала обратятся к Vault для получения токена
-по адресу `/v1/auth/cert/login`, а потом запросят из Vault сам секрет по адресу `/v1/secret/<ID>`.
-
-#### Пример настройки Vault
-
-Пошаговая инструкция для настройки тестового Vault на примере OpenBao:
-
-1. Если ещё не настроен TLS, генерируем самоподписанный TLS сертификат для Vault:
-   ```
-   openssl req -days 3650 -x509 -addext basicConstraints=critical,CA:TRUE,pathlen:1 --addext subjectAltName=DNS:vault \
-       -new -newkey rsa:4096 -nodes -keyout /etc/openbao/vault.key -out /etc/openbao/vault.crt
-   ```
-   Настраиваем его в `/etc/openbao/openbao.hcl`:
-   ```
-   listener "tcp" {
-       address       = "0.0.0.0:8200"
-       tls_cert_file = "/etc/openbao/vault.crt"
-       tls_key_file  = "/etc/openbao/vault.key"
-   }
-   ```
-   И перезапускаем OpenBao (`systemctl restart openbao`).
-2. Копируем TLS сертификат Vault для Vitastor:
-   ```
-   cp /etc/openbao/vault.crt /etc/vitastor/vault.crt
-   ```
-   Переносим его на все клиентские ноды и прописываем в `/etc/vitastor/vitastor.conf`:
-   ```
-   {
-       ...
-       "vault_url": "http://vault:8200",
-       "vault_ca": "/etc/vitastor/vault.crt"
-   }
-   ```
-3. Проверяем статус Vault:
-   ```
-   bao status -ca-cert /etc/openbao/vault.crt -address=https://vault:8200
-   ```
-4. Инициализируем Vault в тестовом режиме из 1 ноды (с 1 частью ключа):
-   ```
-   bao operator init -n 1 -t 1 -ca-cert /etc/openbao/vault.crt -address=https://vault:8200
-   ```
-5. Разблокируем Vault:
-   ```
-   bao operator unseal -ca-cert /etc/openbao/vault.crt -address=https://vault:8200
-   ```
-6. Включаем аутентификацию по сертификатам:
-   ```
-   bao auth enable -ca-cert /etc/openbao/vault.crt -address=https://vault:8200 cert
-   ```
-7. Включаем секреты v1:
-   ```
-   bao secrets enable -ca-cert /etc/openbao/vault.crt -address=https://vault:8200 -path=secret kv-v1
-   ```
-8. Создаём тестовый секрет:
-   ```
-   bao kv put -ca-cert /etc/openbao/vault.crt -address=https://vault:8200 secret/vitastor/testimg3 key=$(openssl rand -hex 64)
-   ```
-9. Генерируем подписанный сертификат для пользователя Vitastor (там, где у вас есть `client_ca.crt` и `client_ca.key`):
-   ```
-   openssl req -subj '/CN=testimg3' -nodes -new -keyout testimg3.key -out testimg3.csr
-   openssl x509 -req -days 3650 -CA client_ca.crt -CAkey client_ca.key -CAcreateserial -in testimg3.csr -out testimg3.crt
-   rm testimg3.csr
-   ```
-10. Создаём пользователя в Vault и даём ему доступ к секрету:
-    ```
-    cat >testimg3.policy <<EOF
-    path "/secret/vitastor/testimg3" {
-        capabilities = ["read"]
-    }
-    EOF
-
-    bao policy write -ca-cert /etc/openbao/vault.crt -address=https://vault:8200 testimg3 testimg3.policy
-
-    bao write -ca-cert /etc/openbao/vault.crt -address=https://vault:8200 auth/cert/certs/testimg3 \
-        certificate=@testimg3.crt display_name=testimg3 token_ttl=24h token_policies=testimg3
-    ```
-11. Тестируем доступ к секрету:
-    ```
-    curl --cacert /etc/vitastor/vault.crt --cert testimg3.crt --key testimg3.key \
-        --json '{}' https://vault:8200/v1/auth/cert/login
-    ```
-    Будет выведен токен, подставляем его в следующий запрос:
-    ```
-    curl --cacert /etc/vitastor/vault.crt --cert testimg3.crt --key testimg3.key \
-        -H 'X-Vault-Token: <ПОЛУЧЕННЫЙ ТОКЕН>' https://vault:8200/v1/secret/vitastor/testimg3
-    ```
-12. Создаём образ в Vitastor с заданным секретом (от имени администратора или того, кто имеет
-    право создавать образы в вашем пуле):
-    ```
-    vitastor-cli create -s 100G --enc_key vault:vitastor/testimg3 --owner testimg3 testimg3
-    ```
-13. Тестируем доступ к образу от имени пользователя testimg3:
-    ```
-    vitastor-cli --cert testimg3.crt --pkey testimg3.key dd if=/dev/urandom oimg=testimg3 bs=1M count=100
-    ```
-
-## Списки разрешённых операций
-
-### Права доступа к данным etcd
-
-Ниже все названия ключей приведены без общего префикса `/vitastor`.
-
-Разрешённые операции с ключами в Antietcd для обычных пользователей:
-- Только чтение:
-  - Разрешено всегда:
-    - `/config/global`
-    - `/config/node_placement`
-    - `/config/pools`
-    - `/pg/config`
-    - `/osd/state/*`
-    - `/pg/state/*`
-    - `/index/maxid/*`
-  - Для образов, которые [может читать пользователь](#пользователи-и-права-доступа):
-    - `/config/inode/*`
-    - `/index/image/*`
-    - `/inode/stats/*`
-- Чтение и запись:
-  - Для пулов, в которых может создавать образы пользователь:
-    - `/index/maxid/*`
-  - Для образов, которыми владеет пользователь:
-    - `/config/inode/*`
-    - `/index/image/*`
-
-Разрешённые операции с ключами в Antietcd для администраторов:
-- Чтение:
-  - `/stats`
-  - `/mon/*`
-  - `/pg/*`
-  - `/pgstats/*`
-  - `/inode/stats/*`
-  - `/pool/stats/*`
-- Чтение и запись:
-  - `/config/*`
-  - `/osd/*`
-  - `/index/*`
-  - `/pg/config`
-  - `/pg/history/*`
-  - `/stats`
-  - `/history/last_clean_pgs`
-
-Разрешённые операции с ключами в etcd для OSD:
-- Чтение:
-  - `/pg/config`
-  - `/config/*`
-- Чтение и запись:
-  - `/osd/*`
-  - `/pg/state/*`
-  - `/pg/history/*`
-  - `/pgstats/*`
-
-Разрешённые операции с ключами в etcd для мониторов:
-- Чтение:
-  - `/config/*`
-  - `/osd/*`
-  - `/pgstats/*`
-- Чтение и запись:
-  - `/pg/config`
-  - `/stats`
-  - `/history/last_clean_pgs`
-  - `/mon/*`
-  - `/pg/history/*`
-  - `/pg/stats/*`
-  - `/pgstats/*`
-  - `/inode/stats/*`
-  - `/pool/stats/*`
-
-### Права доступа к данным OSD
-
-При включённой опции `use_perms` и шифровании OSD аутентифицирует клиентов по сертификатам
-и разрешает каждому клиенту только то, что ему разрешено согласно модели прав доступа.
-
-Клиентские операции:
-- READ - разрешено для образов, доступных пользователю на чтение.
-- WRITE, DELETE, SCRUB - разрешены для образов, доступных пользователю на запись.
-- SYNC - операция не связана с образом и разрешена всегда.
-- DESCRIBE - операция разрешена только для администраторов (используются командами
-  `vitastor-cli describe` и `fix`).
-- PING - операция разрешена всегда.
-- SHOW_CONFIG - операция разрешена всегда, однако если в ней клиент представляется
-  как OSD, то проверяется, что он использует сертификат, подписанный `osd_ca`.
-- SEC_LIST (листинг) - разрешена другим OSD и администраторам с любыми параметрами,
-  а обычным клиентам разрешена только для запросов, ограниченных образом, доступным
-  пользователю на чтение.
-
-Кластерные операции - разрешаются только другим OSD:
-- SEC_READ
-- SEC_WRITE
-- SEC_WRITE_STABLE
-- SEC_SYNC
-- SEC_STABILIZE
-- SEC_ROLLBACK
-- SEC_DELETE
-- SEC_READ_BMP
-- SEC_LOCK
-
-### Права доступа к API
-
-[vitastor-cli serve](../usage/cli.ru.md#serve) также поддерживает клиентскую
-аутентификацию по сертификатам. Принимаются только сертификаты, подписанные
-`client_ca`. В качестве серверного сертификата используется отдельный сертификат
-`api_cert` с ключом `api_pkey`.
-
-При этом для корректной работы `vitastor-cli serve` он сам должен использовать
-для доступа в Vitastor сертификат администратора (`cert`+`pkey`, подписанный `admin_ca`),
-чтобы корректно обрабатывать любые запросы.
-
-Обычным пользователям (с сертификатами, подписанными `client_ca`) при доступе к API
-разрешаются только API-операции с образами, доступными им либо на чтение (для чтения),
-либо на запись (для модификации):
-
-- image/list - для образов, которые пользователь может читать.
-- image/create - для пулов, в которых пользователю разрешено создавать образы, либо
-  для создания снимков образов, которыми пользователь владеет.
-- image/delete, image/flatten, image/modify - для образов, которыми пользователь владеет.
-
-Все остальные операции разрешаются только администраторам.
-
-## Производительность шифрования
-
-У вас может возникнуть вопрос - а как быстро всё это прекрасное шифрование работает?
-
-Ответ - сильно зависит от процессора. На современных процессорах (при наличии AVX512 с VAES)
-очень быстро - скорость шифрования AES может составлять 10-20 Гбайт/с и выше. В первую очередь
-подразумевается CPU клиентских машин, потому что сквозное шифрование выполняется целиком на
-клиенте, а транспортное хоть также и затрагивает OSD, но у клиента поток один, а OSD на стороне
-сервера много и добавить там ресурсов легче.
-
-На более старых процессорах скорость заметно хуже, например, на Xeon E5 v4 она составляет
-буквально 3 Гбайт/с.
-
-Вы можете оценить производительность своих процессоров с помощью команды `vitastor-cli cpubench`.
-
-Пример вывода (💪 AMD EPYC 9575F):
-
-```
-$ vitastor-cli cpubench
-Vitastor transport encryption benchmark (AES-256-GCM, AES-256-XTS and xxhash3)
-
-Warmup...
-
-No transport encryption, data checksums enabled, e2e unencrypted image
-xxhash3 1 M block... 209000 iterations in 2001 ms = 104447.78 MB/s
-xxhash3 4 K block... 37000000 iterations in 2022 ms = 71479.35 MB/s
-
-Header encryption with payload checksums, e2e unencrypted image
-AES-256-GCM encrypt header + xxhash3 1 M block... 210000 iterations in 2015 ms = 104218.36 MB/s
-AES-256-GCM encrypt header + xxhash3 4 K block... 26000000 iterations in 2073 ms = 48993.01 MB/s
-
-Full transport encryption, e2e unencrypted image
-AES-256-GCM encrypt header and 1 M block... 54000 iterations in 2000 ms = 27000.00 MB/s
-AES-256-GCM encrypt header and 4 K block... 11700000 iterations in 2014 ms = 22692.71 MB/s
-
-No transport encryption, no checksums, e2e encrypted image
-AES-256-XTS encrypt 1 M block... 50000 iterations in 2039 ms = 24521.82 MB/s
-AES-256-XTS encrypt 4 K block... 12600000 iterations in 2009 ms = 24499.13 MB/s
-
-No transport encryption, e2e encrypted image, data checksums enabled
-AES-256-XTS encrypt + xxhash3 1 M block... 40000 iterations in 2013 ms = 19870.84 MB/s
-AES-256-XTS encrypt + xxhash3 4 K block... 10200000 iterations in 2011 ms = 19812.90 MB/s
-
-Header encryption with payload checksums, e2e encrypted image
-AES-256-GCM encrypt header + AES-256-XTS encrypt + xxhash3 1 M block... 40000 iterations in 2014 ms = 19860.97 MB/s
-AES-256-GCM encrypt header + AES-256-XTS encrypt + xxhash3 4 K block... 8700000 iterations in 2011 ms = 16899.24 MB/s
-
-Full transport encryption, e2e encrypted image
-AES-256-XTS + AES-256-GCM encrypt 1 M block... 26000 iterations in 2062 ms = 12609.12 MB/s
-AES-256-XTS + AES-256-GCM encrypt 4 K block... 6300000 iterations in 2006 ms = 12267.88 MB/s
-```
-
-А вот Xeon E5-2680v4:
-
-```
-$ vitastor-cli cpubench
-Vitastor transport encryption benchmark (AES-256-GCM, AES-256-XTS and xxhash3)
-
-Warmup...
-
-No transport encryption, data checksums enabled, e2e unencrypted image
-xxhash3 1 M block... 62000 iterations in 2021 ms = 30677.88 MB/s
-xxhash3 4 K block... 12400000 iterations in 2006 ms = 24146.31 MB/s
-
-Header encryption with payload checksums, e2e unencrypted image
-AES-256-GCM encrypt header + xxhash3 1 M block... 62000 iterations in 2027 ms = 30587.07 MB/s
-AES-256-GCM encrypt header + xxhash3 4 K block... 6800000 iterations in 2011 ms = 13208.60 MB/s
-
-Full transport encryption, e2e unencrypted image
-AES-256-GCM encrypt header and 1 M block... 7000 iterations in 2317 ms = 3021.15 MB/s
-AES-256-GCM encrypt header and 4 K block... 1500000 iterations in 2102 ms = 2787.52 MB/s
-
-No transport encryption, no checksums, e2e encrypted image
-AES-256-XTS encrypt 1 M block... 7000 iterations in 2317 ms = 3021.15 MB/s
-AES-256-XTS encrypt 4 K block... 1600000 iterations in 2088 ms = 2993.30 MB/s
-
-No transport encryption, e2e encrypted image, data checksums enabled
-AES-256-XTS encrypt + xxhash3 1 M block... 6000 iterations in 2188 ms = 2742.23 MB/s
-AES-256-XTS encrypt + xxhash3 4 K block... 1400000 iterations in 2053 ms = 2663.78 MB/s
-
-Header encryption with payload checksums, e2e encrypted image
-AES-256-GCM encrypt header + AES-256-XTS encrypt + xxhash3 1 M block... 6000 iterations in 2190 ms = 2739.73 MB/s
-AES-256-GCM encrypt header + AES-256-XTS encrypt + xxhash3 4 K block... 1300000 iterations in 2101 ms = 2417.00 MB/s
-
-Full transport encryption, e2e encrypted image
-AES-256-XTS + AES-256-GCM encrypt 1 M block... 4000 iterations in 2666 ms = 1500.38 MB/s
-AES-256-XTS + AES-256-GCM encrypt 4 K block... 800000 iterations in 2113 ms = 1478.94 MB/s
-```

mon/antietcd_adapter.js

@@ -3,7 +3,6 @@
 
 const AntiEtcd = require('antietcd');
 
-const vitastor_auth_filter = require('./vitastor_auth_filter.js');
 const vitastor_persist_filter = require('./vitastor_persist_filter.js');
 const { b64, local_ips } = require('./utils.js');
 
@@ -19,7 +18,7 @@ class AntiEtcdAdapter
                 cluster = cluster ? (''+(cluster||'')).split(/,+/) : [];
             cluster = Object.keys(cluster.reduce((a, url) =>
             {
-                a[url.toLowerCase().replace(/^(https?:\/\/)?(.*?)(\/.*)?$/, (m, m1, m2) => (m1||'http://')+m2)] = true;
+                a[url.toLowerCase().replace(/^(https?:\/\/)/, '').replace(/\/.*$/, '')] = true;
                 return a;
             }, {}));
             const cfg_port = config.antietcd_port;
@@ -27,18 +26,7 @@ class AntiEtcdAdapter
             is_local['0.0.0.0'] = true;
             is_local['::'] = true;
             is_local[''] = true;
-            // split :, 3 -> <schema>:<//ip>:<port>
-            const selected = [];
-            for (let i = 0; i < cluster.length; i++)
-            {
-                const m = /^(https?:\/\/)?(?:\[(.*)\]|([^\[\:]+))(?::(\d+))?$/.exec(cluster[i]);
-                if (!m)
-                    continue;
-                const ip = m[3] || m[2];
-                const port = m[4] || 2379;
-                if (is_local[ip] && (!cfg_port || port == cfg_port))
-                    selected.push({ idx: i, ip, port });
-            }
+            const selected = cluster.map(s => s.split(':', 2)).filter(ip => is_local[ip[0]] && (!cfg_port || ip[1] == cfg_port));
             if (selected.length > 1)
             {
                 console.error('More than 1 etcd_address matches local IPs, please specify port');
@@ -47,46 +35,16 @@ class AntiEtcdAdapter
             else if (selected.length == 1)
             {
                 const antietcd_config = {
-                    ip: selected[0].ip,
-                    port: selected[0].port,
-                    cert: config.antietcd_cert,
-                    key: config.antietcd_key,
-                    ca: config.client_ca,
-                    data: config.antietcd_data_file || ((config.antietcd_data_dir || '/var/lib/vitastor') + '/mon_'+selected[0].port+'.json.gz'),
+                    ip: selected[0][0],
+                    port: selected[0][1],
+                    data: config.antietcd_data_file || ((config.antietcd_data_dir || '/var/lib/vitastor') + '/mon_'+selected[0][1]+'.json.gz'),
                     persist_filter: vitastor_persist_filter({ vitastor_prefix: config.etcd_prefix || '/vitastor' }),
-                    node_id: cluster[selected[0].idx].replace(/^(https?:\/\/)/, ''), // same as in <cluster> below
-                    cluster: (cluster.length == 1 ? null : cluster.reduce((a, c) => { a[c.replace(/^(https?:\/\/)/, '')] = c; return a; }, {})),
+                    node_id: selected[0][0]+':'+selected[0][1], // node_id = ip:port
+                    cluster: (cluster.length == 1 ? null : cluster.reduce((a, c) => { a[c] = "http://"+c; return a; }, {})),
                     cluster_key: (config.etcd_prefix || '/vitastor'),
                     stale_read: 1,
                     log_level: 1,
-                    logs: { cluster: true },
                 };
-                if (config.etcd_proxy)
-                {
-                    // Monitor may use the builtin etcd_proxy mode
-                    if (!config.etcd_proxy.urls)
-                    {
-                        console.error('etcd_proxy.urls are empty');
-                        process.exit(1);
-                    }
-                    antietcd_config.etcd_proxy = config.etcd_proxy.urls;
-                    antietcd_config.etcd_cert = config.etcd_proxy.cert;
-                    antietcd_config.etcd_key = config.etcd_proxy.key;
-                    antietcd_config.etcd_ca = config.etcd_proxy.ca;
-                    delete antietcd_config.data;
-                    delete antietcd_config.persist_filter;
-                    delete antietcd_config.cluster;
-                    delete antietcd_config.cluster_key;
-                }
-                if (config.use_perms)
-                {
-                    antietcd_config.client_cert_auth = true;
-                    antietcd_config.auth_filter = vitastor_auth_filter;
-                    antietcd_config.ca = config.client_ca;
-                    antietcd_config.osd_ca = config.osd_ca;
-                    antietcd_config.mon_ca = config.mon_ca;
-                    antietcd_config.admin_ca = config.admin_ca;
-                }
                 for (const key in config)
                 {
                     if (key.substr(0, 9) === 'antietcd_')
@@ -211,7 +169,7 @@ class AntiEtcdAdapter
                     await new Promise(ok => setTimeout(ok, timeout-(Date.now()-prev)));
                 }
                 prev = Date.now();
-                const res = await this.antietcd.api(path.replace(/^\/+/, '').replace(/\/+$/, '').replace(/\/+/g, '_'), body, { user_type: 'mon' });
+                const res = await this.antietcd.api(path.replace(/^\/+/, '').replace(/\/+$/, '').replace(/\/+/g, '_'), body);
                 if (res.error)
                 {
                     console.error('Failed to query antietcd '+path+' (retry '+retry+'/'+retries+'): '+res.error);

mon/etcd_adapter.js

@@ -1,9 +1,7 @@
 // Copyright (c) Vitaliy Filippov, 2019+
 // License: VNPL-1.1 (see README.md for details)
 
-const fs = require('fs');
 const http = require('http');
-const https = require('https');
 const WebSocket = require('ws');
 const { b64, local_ips } = require('./utils.js');
 
@@ -17,30 +15,11 @@ class EtcdAdapter
         this.ws = null;
         this.ws_alive = false;
         this.ws_keepalive_timer = null;
-        this.opts = {};
     }
 
     parse_config(config)
     {
         this.parse_etcd_addresses(config.etcd_address||config.etcd_url);
-        if (config.mon_etcd_client_cert || config.etcd_client_cert)
-        {
-            this.opts.cert = config.mon_etcd_client_cert || config.etcd_client_cert;
-            if (this.opts.cert.substr(0, 5) != '-----')
-                this.opts.cert = fs.readFileSync(this.opts.cert, { encoding: 'utf-8' });
-        }
-        if (config.mon_etcd_client_key || config.etcd_client_key)
-        {
-            this.opts.key = config.mon_etcd_client_key || config.etcd_client_key;
-            if (this.opts.key.substr(0, 5) != '-----')
-                this.opts.key = fs.readFileSync(this.opts.key, { encoding: 'utf-8' });
-        }
-        if (config.etcd_ca)
-        {
-            this.opts.ca = config.etcd_ca;
-            if (this.opts.ca.substr(0, 5) != '-----')
-                this.opts.ca = fs.readFileSync(this.opts.ca, { encoding: 'utf-8' });
-        }
     }
 
     parse_etcd_addresses(addrs)
@@ -60,7 +39,7 @@ class EtcdAdapter
         for (let url of addrs)
         {
             let scheme = 'http';
-            url = url.trim().replace(/^(https?):\/\//i, (m, m1) => { scheme = m1.toLowerCase(); return ''; });
+            url = url.trim().replace(/^(https?):\/\//, (m, m1) => { scheme = m1; return ''; });
             const slash = url.indexOf('/');
             const colon = url.indexOf(':');
             const is_local = is_local_ip[colon >= 0 ? url.substr(0, colon) : (slash >= 0 ? url.substr(0, slash) : url)];
@@ -151,7 +130,7 @@ class EtcdAdapter
                     }
                     ok(false);
                 }, this.mon.config.etcd_mon_timeout);
-                this.ws = new WebSocket(base+'/watch', this.opts);
+                this.ws = new WebSocket(base+'/watch');
                 this.ws_used_url = cur_addr;
                 const fail = () =>
                 {
@@ -293,7 +272,7 @@ class EtcdAdapter
             {
                 throw new Error(MON_STOPPED);
             }
-            const res = await POST(base+path, body, timeout, this.opts);
+            const res = await POST(base+path, body, timeout);
             if (this.mon.stopped)
             {
                 throw new Error(MON_STOPPED);
@@ -319,7 +298,7 @@ class EtcdAdapter
     }
 }
 
-function POST(url, body, timeout, opts)
+function POST(url, body, timeout)
 {
     return new Promise(ok =>
     {
@@ -331,10 +310,10 @@ function POST(url, body, timeout, opts)
             req = null;
             ok({ error: 'timeout' });
         }, timeout) : null;
-        let req = (url.substr(0, 5) == 'https' ? https : http).request(url, { method: 'POST', headers: {
+        let req = http.request(url, { method: 'POST', headers: {
             'Content-Type': 'application/json',
             'Content-Length': body_text.length,
-        }, ...(opts||{}) }, (res) =>
+        } }, (res) =>
         {
             if (!req)
             {

mon/etcd_schema.js

@@ -16,7 +16,6 @@ const etcd_allow = new RegExp('^'+[
     'config/pools',
     'config/osd/[1-9]\\d*',
     'config/pgs', // old name
-    'config/user/.*',
     'pg/config',
     'config/inode/[1-9]\\d*/[1-9]\\d*',
     'osd/state/[1-9]\\d*',
@@ -46,14 +45,7 @@ const etcd_tree = {
             config_path: "/etc/vitastor/vitastor.conf",
             etcd_prefix: "/vitastor",
             // etcd connection - configurable online
-            etcd_address: "http://10.0.115.10:2379/v3",
-            etcd_client_cert: "",
-            etcd_client_key: "",
-            osd_etcd_client_cert: "",
-            osd_etcd_client_key: "",
-            mon_etcd_client_cert: "",
-            mon_etcd_client_key: "",
-            etcd_ca: "",
+            etcd_address: "10.0.115.10:2379/v3",
             // mon
             etcd_mon_ttl: 5, // min: 1
             etcd_mon_timeout: 1000, // ms. min: 0
@@ -65,8 +57,6 @@ const etcd_tree = {
             placement_levels: { datacenter: 1, rack: 2, host: 3, osd: 4, ... },
             use_old_pg_combinator: false,
             osd_backfillfull_ratio: 0.99,
-            mon_metrics_path: '/prometheus',
-            mon_healthcheck_path: '/healthcheck',
             // client and osd
             tcp_header_buffer_size: 65536,
             use_sync_send_recv: false,
@@ -211,8 +201,6 @@ const etcd_tree = {
                 primary_affinity_tags?: 'nvme' | [ 'nvme', ... ],
                 // scrub interval
                 scrub_interval?: '30d',
-                // users allowed to create images in this pool
-                creator_group?: '',
             },
             ...
         }, */
@@ -229,21 +217,10 @@ const etcd_tree = {
                     parent_id?: <inode_t>,
                     readonly?: boolean,
                     deleted?: boolean,
-                    enc_key?: string,
-                    owner?: string,
-                    owner_group?: string,
-                    reader_group?: string,
                 }
             }
         }, */
         inode: {},
-        /* user: {
-            <username>: {
-                type: 'osd'|'mon'|'admin'|'client',
-                groups: string[],
-            },
-        }, */
-        user: {},
     },
     osd: {
         state: {

mon/http_server.js

@@ -16,7 +16,7 @@ async function create_http_server(cfg, handler)
         };
         if (cfg.mon_https_ca)
         {
-            tls.ca = await fsp.readFile(cfg.mon_https_ca);
+            tls.mon_https_ca = await fsp.readFile(cfg.mon_https_ca);
         }
         if (cfg.mon_https_client_auth)
         {

mon/lp_optimizer/lp_optimizer.js

@@ -10,19 +10,16 @@ const NO_OSD = 'Z';
 async function lp_solve(text)
 {
     const cp = child_process.spawn('lp_solve');
-    let stdout = '', stderr = '', finish_cb, finished = 0;
+    let stdout = '', stderr = '', finish_cb;
     cp.stdout.on('data', buf => stdout += buf.toString());
     cp.stderr.on('data', buf => stderr += buf.toString());
-    cp.stdout.on('end', () => finish_cb());
-    cp.stderr.on('end', () => finish_cb());
+    cp.on('exit', () => finish_cb && finish_cb());
     cp.stdin.write(text);
     cp.stdin.end();
-    await new Promise(ok => (finish_cb = () =>
+    if (cp.exitCode == null)
     {
-        finished++;
-        if (finished == 2)
-            ok();
-    }));
+        await new Promise(ok => finish_cb = ok);
+    }
     if (!stdout.trim())
     {
         return null;
@@ -112,10 +109,9 @@ function make_cyclic(pgs, parity_space)
 {
     if (parity_space > 1)
     {
-        for (const id in pgs)
+        for (const pg in pgs)
         {
-            const pg = pgs[id];
-            for (let i = 1; i < pg.length; i++)
+            for (let i = 1; i < pg.size; i++)
             {
                 const cyclic = [ ...pg.slice(i), ...pg.slice(0, i) ];
                 pgs['pg_'+cyclic.join('_')] = cyclic;

mon/mon.js

@@ -87,7 +87,7 @@ class Mon
             this.http = await create_http_server(this.config, (req, res) =>
             {
                 const u = new URL(req.url, 'http://'+(req.headers.host || 'localhost'));
-                if (u.pathname.replace(/\/+$/, '') == (this.config.mon_metrics_path||'/metrics'))
+                if (u.pathname.replace(/\/+$/, '') == (this.config.prometheus_path||'/metrics'))
                 {
                     if (!this.watcher_active)
                     {
@@ -100,19 +100,6 @@ class Mon
                         res.write(export_prometheus_metrics(this.state));
                     }
                 }
-                else if (u.pathname.replace(/\/+$/, '') == (this.config.mon_healthcheck_path||'/healthcheck'))
-                {
-                    if (!this.watcher_active)
-                    {
-                        res.writeHead(503);
-                        res.write('Monitor is in standby mode. Please retrieve metrics from master monitor instance\n');
-                    }
-                    else
-                    {
-                        res.setHeader('Content-Type', 'text/plain; version=0.0.4; charset=utf-8');
-                        res.write('Monitor is active');
-                    }
-                }
                 else
                 {
                     res.writeHead(404);
@@ -640,7 +627,7 @@ class Mon
                 if (this.state.pg.history[pool_id] &&
                     this.state.pg.history[pool_id][pg])
                 {
-                    pg_history[pg-1] = JSON.parse(JSON.stringify(this.state.pg.history[pool_id][pg]));
+                    pg_history[pg-1] = this.state.pg.history[pool_id][pg];
                 }
             }
             const real_prev_pgs = [];
@@ -732,7 +719,7 @@ class Mon
                 this.next_recheck_timer = null;
                 this.next_recheck_at = 0;
                 this.schedule_recheck();
-            }, (this.next_recheck_at-now)*1000);
+            }, now-this.next_recheck_at);
         }
     }
 

mon/osd_tree.js

@@ -87,7 +87,7 @@ function make_hier_tree(global_config, tree)
     tree[''] = { children: [] };
     for (const node_id in tree)
     {
-        if (node_id === '')
+        if (node_id === '' || !(tree[node_id].children||[]).length && (tree[node_id].size||0) <= 0)
         {
             continue;
         }

mon/package.json

@@ -1,6 +1,6 @@
 {
   "name": "vitastor-mon",
-  "version": "3.2.2",
+  "version": "2.4.3",
   "description": "Vitastor SDS monitor service",
   "main": "mon-main.js",
   "scripts": {
@@ -9,7 +9,7 @@
   "author": "Vitaliy Filippov",
   "license": "UNLICENSED",
   "dependencies": {
-    "antietcd": "^1.3.3",
+    "antietcd": "^1.1.3",
     "sprintf-js": "^1.1.2",
     "ws": "^7.2.5"
   },

mon/pg_gen.js

@@ -9,6 +9,7 @@ const LPOptimizer = require('./lp_optimizer/lp_optimizer.js');
 const { scale_pg_count } = require('./pg_utils.js');
 const { make_hier_tree, filter_osds_by_root_node,
     filter_osds_by_tags, filter_osds_by_block_layout, get_affinity_osds } = require('./osd_tree.js');
+const { select_murmur3 } = require('./lp_optimizer/murmur3.js');
 
 function pick_primary(pool_id, pg_num, pool_config, osd_set, up_osds, aff_osds)
 {
@@ -38,7 +39,7 @@ function pick_primary(pool_id, pg_num, pool_config, osd_set, up_osds, aff_osds)
     {
         return 0;
     }
-    return alive_set[pg_num % alive_set.length];
+    return alive_set[select_murmur3(alive_set.length, osd_num => pool_id+'/'+pg_num+'/'+osd_num)];
 }
 
 function recheck_primary(state, global_config, up_osds, osd_tree)
@@ -52,7 +53,6 @@ function recheck_primary(state, global_config, up_osds, osd_tree)
             continue;
         }
         const aff_osds = get_affinity_osds(pool_cfg, up_osds, osd_tree);
-        let paused = false;
         for (let pg_num = 1; pg_num <= pool_cfg.pg_count; pg_num++)
         {
             if (!state.pg.config.items[pool_id])
@@ -75,19 +75,6 @@ function recheck_primary(state, global_config, up_osds, osd_tree)
                     );
                     new_pg_config.items[pool_id][pg_num].primary = new_primary;
                 }
-                paused = paused || !!pg_cfg.pause;
-            }
-        }
-        if (paused)
-        {
-            if (!new_pg_config)
-            {
-                new_pg_config = JSON.parse(JSON.stringify(state.pg.config));
-            }
-            console.log(`Resuming paused pool ${pool_id}`);
-            for (const pg in new_pg_config.items[pool_id])
-            {
-                delete new_pg_config.items[pool_id][pg].pause;
             }
         }
     }
@@ -192,10 +179,10 @@ async function generate_pool_pgs(state, global_config, pool_id, osd_tree, levels
     const rules = use_rules ? get_pg_rules(pool_id, pool_cfg, global_config.placement_levels) : null;
     const folded = fold_failure_domains(Object.values(pool_tree), use_rules ? rules : [ [ [ pool_cfg.failure_domain ] ] ]);
     // FIXME: Remove/merge make_hier_tree() step somewhere, however it's needed to remove empty nodes
-    const folded_tree = make_hier_tree(global_config, folded.nodes.reduce((a, c) => { a[c.id] = c; return a; }, {}));
+    const folded_tree = make_hier_tree(global_config, folded.nodes);
     const old_pg_count = prev_pgs.length;
     const optimize_cfg = {
-        osd_weights: folded.nodes.reduce((a, c) => { if (/^\d+$/.exec(c.id) && c.size != null) { a[c.id] = c.size||0; } return a; }, {}),
+        osd_weights: folded.nodes.reduce((a, c) => { if (Number(c.id)) { a[c.id] = c.size; } return a; }, {}),
         combinator: use_rules
             // new algorithm:
             ? new RuleCombinator(folded_tree, rules, pool_cfg.max_osd_combinations)

mon/pg_utils.js

@@ -84,7 +84,7 @@ function scale_pg_history(prev_pg_history, prev_pgs, new_pgs)
         finish_pg_history(merged_history[1]);
         for (let i = 0; i < new_pg_count; i++)
         {
-            new_pg_history[i] = JSON.parse(JSON.stringify(merged_history[1]));
+            new_pg_history[i] = { ...merged_history[1] };
         }
     }
     // Mark history keys for removed PGs as removed
@@ -102,7 +102,7 @@ function scale_pg_count(prev_pgs, new_pg_count)
     {
         for (let i = prev_pgs.length; i < new_pg_count; i++)
         {
-            prev_pgs[i] = [ ...prev_pgs[i % prev_pgs.length] ];
+            prev_pgs[i] = prev_pgs[i % prev_pgs.length];
         }
     }
     else if (prev_pgs.length > new_pg_count)

mon/pool_config.js

@@ -3,9 +3,6 @@
 
 const { parse_level_indexes, parse_pg_dsl } = require('./lp_optimizer/dsl_pgs.js');
 
-const MIN_DATA_BLOCK_SIZE = 4096;
-const MAX_DATA_BLOCK_SIZE = 128*1024*1024;
-
 function validate_pool_cfg(pool_id, pool_cfg, placement_levels, warn)
 {
     pool_cfg.pg_size = Math.floor(pool_cfg.pg_size);
@@ -26,8 +23,7 @@ function validate_pool_cfg(pool_id, pool_cfg, placement_levels, warn)
             console.log('Pool '+pool_id+' has invalid coding scheme (one of "xor", "replicated", "ec" and "jerasure" required)');
         return false;
     }
-    // OSDs don't support pg_size > 64 for now
-    if (!pool_cfg.pg_size || pool_cfg.pg_size < 1 || pool_cfg.pg_size > 64 ||
+    if (!pool_cfg.pg_size || pool_cfg.pg_size < 1 || pool_cfg.pg_size > 256 ||
         pool_cfg.scheme !== 'replicated' && pool_cfg.pg_size < 3)
     {
         if (warn)
@@ -54,18 +50,6 @@ function validate_pool_cfg(pool_id, pool_cfg, placement_levels, warn)
             console.log('Pool '+pool_id+' has invalid parity_chunks (must be between 1 and pg_size-2)');
         return false;
     }
-    if (pool_cfg.block_size &&
-        (!Number(pool_cfg.block_size) || (pool_cfg.block_size & (pool_cfg.block_size-1)) ||
-        pool_cfg.block_size < MIN_DATA_BLOCK_SIZE || pool_cfg.block_size > MAX_DATA_BLOCK_SIZE ||
-        pool_cfg.scheme !== 'replicated' && pool_cfg.block_size*pool_cfg.pg_size > 0xFFFFFFFF))
-    {
-        if (warn)
-        {
-            console.log('Pool '+pool_id+' has invalid block_size (must be a power of two between '+
-                MIN_DATA_BLOCK_SIZE+' and '+MAX_DATA_BLOCK_SIZE+'; must not exceed 2^32-1 when multiplied by pg_size)');
-        }
-        return false;
-    }
     if (!pool_cfg.pg_count || pool_cfg.pg_count < 1)
     {
         if (warn)

mon/scripts/make-etcd

@@ -1,104 +1,50 @@
 #!/usr/bin/node
-// Simple Vitastor etcd / antietcd / TLS configurator
+// Simple systemd unit generator for etcd
 // Copyright (c) Vitaliy Filippov, 2019+
 // License: MIT
 
+// USAGE:
+// 1) Put the same etcd_address into /etc/vitastor/vitastor.conf on all monitor nodes
+// 2) Run ./make-etcd.js. It will create the etcd service on one of specified IPs
+
 const child_process = require('child_process');
 const fs = require('fs');
 const os = require('os');
-const path = require('path');
-const readline = require('readline');
 
-const help_text = `Initialize a Vitastor cluster (etcd, vitastor.conf and TLS certificates)
-(c) Vitaliy Filippov, 2026+ (MIT)
-
-USAGE:
-1) Create a minimal vitastor.conf with etcd_address, osd_network and (optionally) use_perms.
-   Non-encrypted: {"etcd_address":["http://10.0.0.10:2379","http://10.0.0.11:2379","http://10.0.0.12:2379"],"osd_network":"10.0.0.0/24"}
-   Encrypted: {"etcd_address":["https://10.0.0.10:2379","https://10.0.0.11:2379","https://10.0.0.12:2379"],"use_perms":true,"osd_network":"10.0.0.0/24"}
-   (Note https:// etcd URLs!)
-2) Run: ${process.argv[1]} [./vitastor.conf] [--antietcd-only]
-   You can run it on etcd/monitor nodes or on an external node.
-   It configures etcd, generates TLS certificates (on the first or external node), copies
-   them to other etcd/monitor nodes using root ssh, and updates vitastor.conf with TLS options.
-   You can also copy configuration and certificates manually.
-3) If you have OSD-only nodes, run:
-   ${process.argv[1]} --copy-to-osd-node NODE_NAME ./vitastor.conf
-   It copies vitastor.conf and required TLS certificates to that node.
-
-OPTIONS:
---antietcd-only
-    disable etcd (proxy or direct mode), use only antietcd
---gen-certs
-    force certificate generation even if it's not the first node
---no-certs
-    disable certificate generation
---copy yes|no|ask
-    copy vitastor.conf and TLS certificates for monitor&etcd to monitor nodes using scp
-    (default is ask)
---copy-to-osd-node NODE[,NODE2,...]
-    copy vitastor.conf and TLS certificates for OSDs to NODES using scp
-`;
+run().catch(e => { console.error(e); process.exit(1); });
 
 async function run()
 {
-    let config_path = '/etc/vitastor/vitastor.conf';
-    let config_dir = '/etc/vitastor';
-    let gen_certs = 'auto';
-    let antietcd_only = false;
-    let copy = 'ask';
-    let copy_to_osd = null;
-    for (let i = 2; i < process.argv.length; i++)
+    const config_path = process.argv[2] || '/etc/vitastor/vitastor.conf';
+    if (config_path == '-h' || config_path == '--help')
     {
-        const arg = process.argv[i];
-        if (arg == '-h' || arg == '--help')
-        {
-            console.log(help_text);
-            process.exit(0);
-        }
-        else if (arg == '--gen-certs')
-        {
-            gen_certs = true;
-        }
-        else if (arg == '--no-certs')
-        {
-            gen_certs = false;
-        }
-        else if (arg == '--antietcd-only')
-        {
-            antietcd_only = true;
-        }
-        else if (arg == '--copy-to-osd-node' && i < process.argv.length-1)
-        {
-            i++;
-            copy_to_osd = process.argv[i].split(/,/);
-        }
-        else if (arg == '--copy' && i < process.argv.length-1)
-        {
-            i++;
-            copy = process.argv[i];
-            if (copy !== 'ask' && copy !== 'yes' && copy !== 'no')
-            {
-                console.error('--copy should be "ask", "yes" or "no"');
-                process.exit(1);
-            }
-        }
-        else if (arg[0] == '-')
-        {
-            console.error('Unknown option: '+arg[0]);
-            process.exit(1);
-        }
-        else
-        {
-            config_path = arg;
-            config_dir = path.dirname(arg);
-        }
+        console.log(
+            'Initialize systemd etcd service for Vitastor\n'+
+            '(c) Vitaliy Filippov, 2019+ (MIT)\n'+
+            '\n'+
+            'USAGE:\n'+
+            '1) Put the same etcd_address into /etc/vitastor/vitastor.conf on all monitor nodes\n'+
+            '2) Run '+process.argv[1]+' [config_path]\n'
+        );
+        process.exit(0);
     }
     if (!fs.existsSync(config_path))
     {
         console.log(config_path+' is missing');
         process.exit(1);
     }
+    const in_docker = fs.existsSync("/etc/vitastor/etcd.conf") &&
+        fs.existsSync("/etc/vitastor/docker.conf");
+    if (!in_docker && fs.existsSync("/etc/systemd/system/vitastor-etcd.service"))
+    {
+        console.log("/etc/systemd/system/vitastor-etcd.service already exists");
+        process.exit(1);
+    }
+    if (!in_docker && fs.existsSync("/etc/systemd/system/etcd.service"))
+    {
+        console.log("/etc/systemd/system/etcd.service already exists");
+        process.exit(1);
+    }
     const config = JSON.parse(fs.readFileSync(config_path, { encoding: 'utf-8' }));
     if (!config.etcd_address)
     {
@@ -106,307 +52,30 @@ async function run()
         process.exit(1);
     }
     const etcds = (config.etcd_address instanceof Array ? config.etcd_address : (''+config.etcd_address).split(/,/))
-        .map(s => /^(https?):\/\/(\[[^\]]+\]|[^\[\]\:\/]+)(?::(\d+))?/.exec(s.toLowerCase()))
-        .filter(s => s)
-        .map(s => ({
-            scheme: s[1],
-            addr: s[2].indexOf(':') >= 0 && s[2][0] != '[' ? '['+s[2]+']' : s[2],
-            ip: s[2][0] == '[' ? s[2].substr(1, s[2].length-2) : s[2],
-            port: s[3],
-        }));
-    const tls = etcds.filter(e => e.scheme === 'https').length > 0;
-    const use_perms = tls && config.use_perms;
+        .map(s => (''+s).replace(/^https?:\/\/|(:\d+)?(\/.*)?$/g, '').replace(/^\[(.*)\]$/, '$1').toLowerCase());
     const num = select_local_etcd(etcds);
-    if (copy_to_osd)
-    {
-        copy_to_osd_nodes(copy_to_osd, config_dir, use_perms, antietcd_only);
-        process.exit(0);
-    }
-    if (tls)
-    {
-        const etcd_ca = config_dir+'/'+path.basename(config.etcd_ca || '/etc/vitastor/etcd_ca.crt');
-        if (gen_certs === true)
-        {
-            console.log('Certificate generation is requested explicitly, generating');
-        }
-        else if (gen_certs === false)
-        {
-            console.log('Certificate generation is disabled explicitly, skipping');
-        }
-        else if (num < 0)
-        {
-            gen_certs = true;
-            console.log('No matching IPs in etcd_address from '+config_path+', only generating certificates');
-        }
-        else if (config.etcd_ca && fs.existsSync(etcd_ca))
-        {
-            gen_certs = false;
-            console.log(etcd_ca+' already exists, assuming certificates are already generated');
-        }
-        else if (num === 0)
-        {
-            gen_certs = true;
-            console.log('This is monitor node 1, generating certificates');
-        }
-        else
-        {
-            console.log('This is monitor node '+(num+1)+', '+etcd_ca+' does not exist, please copy certificates to this node');
-            process.exit(1);
-        }
-        await write_auth_config(config, config_path, etcds, use_perms, antietcd_only);
-        if (gen_certs)
-        {
-            if (copy === 'ask')
-                copy = await ask_copy('Copy certificates and vitastor.conf to other nodes and start them (requires root ssh)? ');
-            copy = (copy === 'y' || copy === 'yes');
-            await make_certs(config_dir, copy, etcds, num, use_perms, antietcd_only);
-        }
-    }
-    else if (num <= 0)
-    {
-        if (copy === 'ask')
-            copy = await ask_copy('Copy vitastor.conf to other nodes and start them (requires root ssh)? ');
-        if (copy === 'y' || copy === 'yes')
-            await copy_nontls(config_dir, etcds, num);
-    }
     if (num < 0)
     {
         console.log('No matching IPs in etcd_address from '+config_path);
-        process.exit(tls && gen_certs ? 0 : 1);
+        process.exit(0);
     }
-    await configure_etcd(etcds, num, tls, use_perms);
-    process.exit(0);
-}
-
-async function ask_copy(question)
-{
-    const rl = readline.createInterface({
-        input: process.stdin,
-        output: process.stdout,
-        prompt: '> ',
-    });
-    let copy;
-    while (copy != 'y' && copy != 'n' && copy != 'yes' && copy != 'no')
-    {
-        if (copy)
-            console.log('Please type "yes" or "no"');
-        copy = await new Promise(ok => rl.question(question, ok));
-    }
-    return copy;
-}
-
-async function copy_to_osd_nodes(to, dir, use_perms, antietcd_only)
-{
-    const osd_to_copy = [ 'vitastor.conf' ];
-    if (!antietcd_only && !use_perms)
-        osd_to_copy.push('etcd_ca.crt');
-    else
-        osd_to_copy.push('antietcd_ca.crt');
-    if (use_perms)
-        osd_to_copy.push('osd.crt', 'osd.key', 'client_ca.crt');
-    console.warn('Copying configuration to OSD nodes '+to.join(', '));
-    for (const node of to)
-        await system("scp "+dir+"/"+osd_to_copy.join(" "+dir+"/")+" root@"+(node.indexOf(':') >= 0 ? "["+node+"]" : node)+":/etc/vitastor/");
-}
-
-async function make_certs(dir, copy, etcds, num, use_perms, antietcd_only)
-{
-    console.log(`-----
-Generating certificates in ${dir}
------
-`);
-    const to_copy = [ 'vitastor.conf' ];
-    const osd_to_copy = [ 'vitastor.conf' ];
-    if (!antietcd_only)
-    {
-        await make_ca("/O=Vitastor etcd CA", dir+"/etcd_ca");
-        await make_signed("/CN=Vitastor etcd", dir+"/etcd", dir+"/etcd_ca", etcds.map(e => "IP:"+e.ip).join(','));
-        to_copy.push('etcd_ca.crt', 'etcd.crt', 'etcd.key');
-        if (!use_perms)
-            osd_to_copy.push('etcd_ca.crt');
-    }
-    if (use_perms || antietcd_only)
-    {
-        await make_ca("/O=Vitastor Antietcd CA", dir+"/antietcd_ca");
-        await make_signed("/CN=Vitastor Antietcd", dir+"/antietcd", dir+"/antietcd_ca", etcds.map(e => "IP:"+e.ip).join(','));
-        to_copy.push('antietcd_ca.crt', 'antietcd.crt', 'antietcd.key');
-        osd_to_copy.push('antietcd_ca.crt');
-    }
-    if (use_perms)
-    {
-        await make_ca("/CN=Vitastor OSD", dir+"/osd");
-        await make_ca("/O=Vitastor Client CA", dir+"/client_ca");
-        await make_ca("/O=Vitastor Admin CA", dir+"/admin_ca");
-        await make_signed("/CN=admin", dir+"/admin", dir+"/admin_ca");
-        to_copy.push('osd.crt', 'osd.key', 'client_ca.crt', 'admin_ca.crt', 'admin.crt', 'admin.key');
-        osd_to_copy.push('osd.crt', 'osd.key', 'client_ca.crt', 'admin_ca.crt', 'admin.crt', 'admin.key');
-    }
-    console.log(`-----
-Certificates generated, commands to copy them:
-- Monitor+OSD node:
-  cd ${dir} && scp ${to_copy.join(' ')} root@NODE:/etc/vitastor/
-- Monitor node:
-  cd ${dir} && scp ${to_copy.filter(f => f != 'osd.key').join(' ')} root@NODE:/etc/vitastor/
-- OSD node:
-  cd ${dir} && scp ${osd_to_copy.join(' ')} root@NODE:/etc/vitastor/
-Then don't forget to run:
-chown vitastor:vitastor /etc/vitastor/*.key && /usr/lib/vitastor/mon/make-etcd
------
-`);
-    if (copy)
-    {
-        for (let i = 0; i < etcds.length; i++)
-        {
-            if (i == num)
-                continue;
-            const node = etcds[i];
-            await system("scp "+dir+"/"+to_copy.join(" "+dir+"/")+" root@"+(node.ip.indexOf(':') >= 0 ? "["+node.ip+"]" : node.ip)+
-                ":/etc/vitastor/ && ssh root@"+node.ip+" 'chown vitastor:vitastor /etc/vitastor/*.key && /usr/lib/vitastor/mon/make-etcd'");
-        }
-    }
-    else
-    {
-        console.warn('Certificates generated in '+dir+', please copy them to other nodes');
-    }
-}
-
-async function copy_nontls(dir, etcds, num)
-{
-    const to_copy = [ 'vitastor.conf' ];
-    for (let i = 0; i < etcds.length; i++)
-    {
-        if (i == num)
-            continue;
-        const node = etcds[i];
-        await system("scp "+dir+"/"+to_copy.join(" "+dir+"/")+" root@"+(node.ip.indexOf(':') >= 0 ? "["+node.ip+"]" : node.ip)+
-            ":/etc/vitastor/ && ssh root@"+node.ip+" '/usr/lib/vitastor/mon/make-etcd'");
-    }
-}
-
-async function write_auth_config(config, config_path, etcds, use_perms, antietcd_only)
-{
-    const auth = {};
-    if (use_perms)
-    {
-        auth["use_antietcd"] = true;
-        if (!antietcd_only)
-        {
-            auth["etcd_proxy"] = {
-                urls: etcds.map(e => (e.ip.indexOf(':') >= 0 ? '['+e.ip+']' : e.ip)+':2381'),
-                cert: "/etc/vitastor/antietcd.crt",
-                key: "/etc/vitastor/antietcd.key",
-                ca: "/etc/vitastor/etcd_ca.crt",
-            };
-        }
-        auth["antietcd_cert"] = "/etc/vitastor/antietcd.crt";
-        auth["antietcd_key"] = "/etc/vitastor/antietcd.key";
-        auth["etcd_ca"] = "/etc/vitastor/antietcd_ca.crt";
-        auth["osd_cert"] = "/etc/vitastor/osd.crt";
-        auth["osd_pkey"] = "/etc/vitastor/osd.key";
-        auth["osd_ca"] = "/etc/vitastor/osd.crt";
-        auth["client_ca"] = "/etc/vitastor/client_ca.crt";
-        auth["admin_ca"] = "/etc/vitastor/admin_ca.crt";
-        auth["cert"] = "/etc/vitastor/admin.crt";
-        auth["pkey"] = "/etc/vitastor/admin.key";
-    }
-    else
-    {
-        if (antietcd_only)
-        {
-            auth["use_antietcd"] = true;
-            auth["antietcd_cert"] = "/etc/vitastor/antietcd.crt";
-            auth["antietcd_key"] = "/etc/vitastor/antietcd.key";
-            auth["etcd_ca"] = "/etc/vitastor/antietcd_ca.crt";
-        }
-        else
-        {
-            auth["etcd_ca"] = "/etc/vitastor/etcd.crt";
-        }
-    }
-    for (const k in auth)
-    {
-        if ((k in config) && JSON.stringify(auth[k]) != JSON.stringify(config[k]))
-        {
-            // Auth options already overridden with non-default
-            console.log(k+" is already overridden in "+config_path+", skipping config update");
-            return;
-        }
-    }
-    for (const k in auth)
-    {
-        config[k] = auth[k];
-    }
-    console.log(`-----
-Updating ${config_path}
------
-`);
-    fs.writeFileSync(config_path, JSON.stringify(config, 0, 4));
-}
-
-async function configure_etcd(etcds, num, tls, use_perms)
-{
-    const in_docker = fs.existsSync("/etc/vitastor/etcd.conf") &&
-        fs.existsSync("/etc/vitastor/docker.conf");
-    if (!in_docker && fs.existsSync("/etc/systemd/system/vitastor-etcd.service") &&
-        fs.existsSync("/etc/vitastor/etcd.conf"))
-    {
-        console.log("/etc/systemd/system/vitastor-etcd.service and /etc/vitastor/etcd.conf already exists. Remove them to reinitialize the cluster");
-        process.exit(1);
-    }
-    if (!in_docker && fs.existsSync("/etc/systemd/system/etcd.service"))
-    {
-        console.log("/etc/systemd/system/etcd.service already exists");
-        process.exit(1);
-    }
-    const etcd_url = etcds[num].scheme + '://' + etcds[num].addr;
-    const options = {
-        name: 'etcd'+etcds[num].ip.replace(/[^0-9a-z_]/ig, '_'),
-        advertise_client_urls: etcd_url+':'+(use_perms ? 2381 : 2379),
-        listen_client_urls: etcd_url+':'+(use_perms ? 2381 : 2379),
-        initial_advertise_peer_urls: etcd_url+':2380',
-        listen_peer_urls: etcd_url+':2380',
-        initial_cluster_token: 'vitastor-etcd-1',
-        initial_cluster_state: 'new',
-        initial_cluster: etcds.map(e => `etcd${e.ip.replace(/[^0-9a-z_]/ig, '_')}=${e.scheme}://${e.addr}:2380`).join(','),
-        snapshot_count: 10000,
-        max_txn_ops: 100000,
-        max_request_bytes: 104857600,
-        auto_compaction_retention: 10,
-        auto_compaction_mode: 'revision',
-    };
-    if (tls)
-    {
-        options['cert_file'] = '/etc/vitastor/etcd.crt';
-        options['key_file'] = '/etc/vitastor/etcd.key';
-        if (use_perms)
-        {
-            options['client_cert_auth'] = '1';
-            options['trusted_ca_file'] = '/etc/vitastor/antietcd_ca.crt';
-        }
-        options['peer_cert_file'] = '/etc/vitastor/etcd.crt';
-        options['peer_key_file'] = '/etc/vitastor/etcd.key';
-        if (use_perms)
-        {
-            options['peer_client_cert_auth'] = '1';
-            options['peer_trusted_ca_file'] = '/etc/vitastor/etcd_ca.crt';
-        }
-    }
-    let etcd_conf = fs.existsSync("/etc/vitastor/etcd.conf")
-        ? fs.readFileSync("/etc/vitastor/etcd.conf", { encoding: 'utf-8' })
-        : "";
-    for (const k in options)
-    {
-        etcd_conf = replace_env(etcd_conf, 'ETCD_'+k.toUpperCase().replace(/-/, '_'), options[k]);
-    }
-    fs.writeFileSync("/etc/vitastor/etcd.conf", etcd_conf);
+    const etcd_url = 'http://' + (etcds[num].indexOf(':') >= 0 ? '['+etcds[num]+']' : etcds[num]);
+    const etcd_name = 'etcd'+etcds[num].replace(/[^0-9a-z_]/ig, '_');
+    const etcd_cluster = etcds.map(e => `etcd${e.replace(/[^0-9a-z_]/ig, '_')}=http://${e.indexOf(':') >= 0 ? '['+e+']' : e}:2380`).join(',');
     if (in_docker)
     {
+        let etcd_conf = fs.readFileSync("/etc/vitastor/etcd.conf", { encoding: 'utf-8' });
+        etcd_conf = replace_env(etcd_conf, 'ETCD_NAME', etcd_name);
+        etcd_conf = replace_env(etcd_conf, 'ETCD_IP', etcds[num]);
+        etcd_conf = replace_env(etcd_conf, 'ETCD_INITIAL_CLUSTER', etcd_cluster);
+        fs.writeFileSync("/etc/vitastor/etcd.conf", etcd_conf);
         console.log('etcd for Vitastor configured. Run `systemctl enable --now vitastor-etcd` to start etcd');
         process.exit(0);
     }
     await system(`mkdir -p /var/lib/etcd/vitastor`);
     fs.writeFileSync(
-        "/etc/systemd/system/vitastor-etcd.service", `[Unit]
+        "/etc/systemd/system/vitastor-etcd.service",
+`[Unit]
 Description=etcd for vitastor
 After=network-online.target local-fs.target time-sync.target
 Wants=network-online.target local-fs.target time-sync.target
@@ -414,8 +83,12 @@ Wants=network-online.target local-fs.target time-sync.target
 [Service]
 Restart=always
 Environment=GOGC=50
-EnvironmentFile=/etc/vitastor/etcd.conf
-ExecStart=etcd --data-dir /var/lib/etcd/vitastor
+ExecStart=etcd --name ${etcd_name} --data-dir /var/lib/etcd/vitastor \\
+    --snapshot-count 10000 --advertise-client-urls ${etcd_url}:2379 --listen-client-urls ${etcd_url}:2379 \\
+    --initial-advertise-peer-urls ${etcd_url}:2380 --listen-peer-urls ${etcd_url}:2380 \\
+    --initial-cluster-token vitastor-etcd-1 --initial-cluster ${etcd_cluster} \\
+    --initial-cluster-state new --max-txn-ops=100000 --max-request-bytes=104857600 \\
+    --auto-compaction-retention=10 --auto-compaction-mode=revision
 WorkingDirectory=/var/lib/etcd/vitastor
 ExecStartPre=+chown -R etcd /var/lib/etcd/vitastor
 User=etcd
@@ -429,77 +102,37 @@ RestartSec=10
 WantedBy=multi-user.target
 `);
     await system(`useradd etcd`);
-    await system(`chown vitastor:vitastor /etc/vitastor/*.key`);
-    if (options['key_file'])
-    {
-        await system(`chown etcd `+options['key_file']);
-    }
     await system(`systemctl daemon-reload`);
     // Disable distribution etcd unit and enable our one
     await system(`systemctl disable --now etcd`);
     await system(`systemctl enable --now vitastor-etcd`);
-    await system(`systemctl enable --now vitastor-mon`);
+    process.exit(0);
 }
 
 function replace_env(text, key, value)
 {
     let found = false;
     text = text.replace(new RegExp('^'+key+'\\s*=.*', 'm'), () => { found = true; return key+'='+value; });
-    if (found)
-        return text;
-    return (text != '' ? text.replace(/\s*$/, '\n') : '')+key+'='+value+'\n';
+    return found ? text : text.replace(/\s*$/, '\n')+key+'='+value+'\n';
 }
 
 function select_local_etcd(etcds)
 {
     const ifaces = os.networkInterfaces();
-    const local = {};
     for (const ifname in ifaces)
-    {
         for (const iface of ifaces[ifname])
-        {
-            const addr = iface.address;
-            if (iface.family == 'IPv6')
-                local[addr.toLowerCase()] = local['['+addr.toLowerCase()+']'] = true;
-            else
-                local[addr] = true;
-        }
-    }
-    for (let i = 0; i < etcds.length; i++)
-    {
-        if (local[etcds[i].addr])
-            return i;
-    }
+            for (let i = 0; i < etcds.length; i++)
+                if (etcds[i] == iface.address.toLowerCase())
+                    return i;
     return -1;
 }
 
 async function system(cmd)
 {
-    console.log('Running '+cmd);
-    process.stdin.pause();
     const cp = child_process.spawn(cmd, { shell: true, stdio: [ 0, 1, 2 ] });
     let finish_cb;
     cp.on('exit', () => finish_cb && finish_cb());
     if (cp.exitCode == null)
         await new Promise(ok => finish_cb = ok);
-    process.stdin.resume();
     return cp.exitCode;
 }
-
-async function make_ca(subj, filename)
-{
-    if (await system("openssl req -days 3650 -x509 -subj '"+subj+"' -addext basicConstraints=critical,CA:TRUE,pathlen:1"+
-        " -new -newkey rsa:4096 -nodes -keyout "+filename+".key -out "+filename+".crt"))
-        process.exit(1);
-}
-
-async function make_signed(subj, f, ca, san)
-{
-    if (await system(`openssl req -subj '${subj}' ${san ? "-addext 'subjectAltName="+san+"'" : ""} -nodes -new -keyout ${f}.key -out ${f}.csr`))
-        process.exit(1);
-    if (await system(`openssl x509 -req -days 3650 -copy_extensions copy -CA ${ca}.crt -CAkey ${ca}.key -CAcreateserial -in ${f}.csr -out ${f}.crt`))
-        process.exit(1);
-    fs.unlinkSync(f+".csr");
-}
-
-run().catch(e => { console.error(e); process.exit(1); });

mon/stats.js

@@ -37,7 +37,6 @@ function derive_osd_stats(st, prev, prev_diff)
         const n = c.count - BigInt(pr && pr.count||0);
         diff.recovery_stats[op] = { ...c, bps: n > 0 ? b*1000n/timediff : 0n, iops: n > 0 ? n*1000n/timediff : 0n };
     }
-    diff.inode_stats = {};
     for (const pool_id in st.inode_stats||{})
     {
         diff.inode_stats[pool_id] = {};

mon/vitastor_auth_filter.js

@@ -1,549 +0,0 @@
-// AntiEtcd authentication filter for Vitastor
-// (c) Vitaliy Filippov, 2026
-// License: Mozilla Public License 2.0 or Vitastor Network Public License 1.1
-
-// Permissions are based on:
-// 1. Users.
-//    Stored in /vitastor/config/user/<username>.
-//    Has 1 property:
-//    - groups, a list of group names the user is included in.
-// 2. Images.
-//    Stored in /vitastor/config/inode/<pool>/<inode>. Has the following properties:
-//    - owner (user name)
-//    - owner_group (group name)
-//    - reader_group
-// 3. Certificates.
-//    - osd_ca identifies OSDs.
-//    - admin_ca (optional) identifies administrators.
-//    - mon_ca (optional) identifies monitors.
-
-const { X509Certificate } = require('node:crypto');
-
-const static_perms = {
-    invalid: {
-        keys: {},
-        prefixes: {},
-    },
-    osd: {
-        keys: { '/pg/config': false },
-        prefixes: { '/config/': false, '/osd/': true, '/pg/state/': true, '/pg/history/': true, '/pgstats/': true },
-    },
-    mon: {
-        keys: { '/pg/config': true, '/stats': true, '/history/last_clean_pgs': true },
-        prefixes: {
-            '/config/': false, '/osd/': false, '/mon/': true, '/pg/history/': true,
-            '/pg/stats/': true, '/pgstats/': true, '/inode/stats/': true, '/pool/stats/': true,
-        },
-    },
-    admin: {
-        keys: { '/pg/config': true, '/stats': true, '/history/last_clean_pgs': true },
-        prefixes: {
-            '/config/': true, '/osd/': true, '/index/': true, '/pg/history/': true,
-            '/mon/': false, '/pg/': false, '/pgstats/': false, '/inode/stats/': false, '/pool/stats/': false,
-        },
-    },
-    client: {
-        keys: { '/config/global': false, '/config/node_placement': false, '/config/pools': false, '/pg/config': false },
-        prefixes: { '/osd/state/': false, '/pg/state/': false, '/index/maxid/': false },
-    },
-};
-
-const api_perms = {
-    osd: { lease_grant: true, lease_revoke: true, lease_keepalive: true, maintenance_status: true },
-    mon: { lease_grant: true, lease_revoke: true, lease_keepalive: true, maintenance_status: true },
-    admin: { maintenance_status: true },
-    client: { maintenance_status: true },
-};
-
-class VitastorAuthFilter
-{
-    constructor(antietcd)
-    {
-        this.cfg = antietcd.cfg;
-        this.antietcd = antietcd;
-        this.prefix = this.cfg.vitastor_prefix || '/vitastor';
-        this.prefix_parts = this.prefix.split('/');
-    }
-
-    async init()
-    {
-        if (!this.cfg.cert || !this.cfg.key || !this.cfg.ca || !this.cfg.osd_ca || !this.cfg.client_cert_auth)
-        {
-            throw new Error('Authenticated Vitastor setups require enabled client_cert_auth, cert, key'+
-                ' and separate ca (client CA), osd_ca and optionally admin_ca and mon_ca');
-        }
-        this.osd_ca = await this.antietcd.readPEM(this.cfg.osd_ca);
-        this.osd_ca_obj = new X509Certificate(this.osd_ca);
-        this.antietcd.tls.ca.push(this.osd_ca);
-        if (this.cfg.mon_ca)
-        {
-            this.mon_ca = await this.antietcd.readPEM(this.cfg.mon_ca);
-            this.mon_ca_obj = new X509Certificate(this.mon_ca);
-            this.antietcd.tls.ca.push(this.mon_ca);
-        }
-        if (this.cfg.admin_ca)
-        {
-            this.admin_ca = await this.antietcd.readPEM(this.cfg.admin_ca);
-            this.admin_ca_obj = new X509Certificate(this.admin_ca);
-            this.antietcd.tls.ca.push(this.admin_ca);
-        }
-    }
-
-    init_context(context, socket)
-    {
-        let cert = socket.getPeerX509Certificate();
-        if (cert.issuer == this.osd_ca_obj.subject && cert.verify(this.osd_ca_obj.publicKey))
-        {
-            context.user_type = 'osd';
-        }
-        else if (this.mon_ca_obj && cert.issuer == this.mon_ca_obj.subject && cert.verify(this.mon_ca_obj.publicKey))
-        {
-            context.user_type = 'mon';
-        }
-        else if (this.admin_ca_obj && cert.issuer == this.admin_ca_obj.subject && cert.verify(this.admin_ca_obj.publicKey))
-        {
-            context.user_type = 'admin';
-        }
-    }
-
-    _get(path, decode)
-    {
-        let cur = this.antietcd.etctree.state;
-        path = path instanceof Array ? path : path.split('/');
-        for (const p of path)
-        {
-            if (!cur.children)
-            {
-                return null;
-            }
-            cur = cur.children[p];
-            if (!cur)
-            {
-                return null;
-            }
-        }
-        if (decode)
-        {
-            return this._decode(path, cur.value);
-        }
-        return cur;
-    }
-
-    _decode(path, cur)
-    {
-        if (!cur)
-        {
-            return null;
-        }
-        if (cur)
-        {
-            try
-            {
-                cur = JSON.parse(cur);
-            }
-            catch (e)
-            {
-                console.warn('Invalid JSON in '+(path instanceof Array ? path.join('/') : path)+': '+e);
-            }
-        }
-        return cur;
-    }
-
-    // userInfo: { name: string, perms: static_perms[type], groups: { [string]: true } }
-    _check_compare(check, userInfo, checked)
-    {
-        let key = String(check.key);
-        if (key.substr(0, this.prefix.length) !== this.prefix)
-        {
-            return false;
-        }
-        key = key.substr(this.prefix.length);
-        if (key in userInfo.perms.keys)
-        {
-            return true;
-        }
-        for (const pfx in userInfo.perms.prefixes)
-        {
-            if (key.substr(0, pfx.length) == pfx)
-            {
-                return true;
-            }
-        }
-        if (userInfo.type == 'client')
-        {
-            // Image permissions
-            if (key.substr(0, 14) == '/config/inode/')
-            {
-                // Allowed to check that a key does not exist
-                if (check.target == 'VERSION' && check.version == 0)
-                {
-                    checked['C'+key] = true;
-                    return true;
-                }
-                else if (check.target == 'MOD')
-                {
-                    const data = this._get(check.key);
-                    if (!data || data.mod_revision != check.mod_revision)
-                    {
-                        // Break check to trigger CAS failure
-                        check.mod_revision = '18446744073709551615'; // UINT64_MAX
-                        return true;
-                    }
-                    const inode = this._decode(check.key, data.value);
-                    if (inode && (inode.owner_group && userInfo.groups[inode.owner_group] ||
-                        inode.owner === userInfo.name))
-                    {
-                        checked['M'+key] = true;
-                        return true;
-                    }
-                }
-                return false;
-            }
-            if (key.substr(0, 13) == '/index/image/')
-            {
-                // Allowed to check that a key does not exist
-                if (check.target == 'VERSION' && check.version == 0)
-                {
-                    checked['M'+key] = true;
-                    return true;
-                }
-                else if (check.target == 'MOD')
-                {
-                    let data = this._get(check.key);
-                    if (!data || data.mod_revision != check.mod_revision)
-                    {
-                        // Break check to trigger CAS failure
-                        check.mod_revision = '18446744073709551615'; // UINT64_MAX
-                        return true;
-                    }
-                    data = this._decode(check.key, data.value);
-                    if (data)
-                    {
-                        const inode = this._get([ ...this.prefix_parts, 'config', 'inode', data.pool_id, data.id ], true);
-                        if (inode && (inode.owner_group && userInfo.groups[inode.owner_group] ||
-                            inode.owner === userInfo.name))
-                        {
-                            checked['M'+key] = true;
-                            return true;
-                        }
-                    }
-                }
-                return false;
-            }
-            if (key.substr(0, 13) == '/index/maxid/')
-            {
-                const pool_id = key.substr(13);
-                const pool_cfg = this._get([ ...this.prefix_parts, 'config', 'pools' ], true);
-                if (!pool_cfg || !pool_cfg[pool_id] || !pool_cfg[pool_id].creator_group || !userInfo.groups[pool_cfg[pool_id].creator_group])
-                {
-                    return false;
-                }
-                if (check.target == 'VERSION' && check.version == 0)
-                {
-                    checked['I'+parseInt(key.substr(13))+'_0'] = true;
-                    return true;
-                }
-                else if (check.target == 'MOD')
-                {
-                    const data = this._get(check.key);
-                    if (!data || data.mod_revision != check.mod_revision)
-                    {
-                        // Break check to trigger CAS failure
-                        check.mod_revision = '18446744073709551615'; // UINT64_MAX
-                        return true;
-                    }
-                    checked['I'+parseInt(key.substr(13))+'_'+data.value] = true;
-                    return true;
-                }
-                return false;
-            }
-        }
-        return false;
-    }
-
-    _check_read(kv, userInfo)
-    {
-        let key = String(kv.key);
-        if (key.substr(0, this.prefix.length) !== this.prefix)
-        {
-            return false;
-        }
-        key = key.substr(this.prefix.length);
-        if (key in userInfo.perms.keys)
-        {
-            return true;
-        }
-        for (const pfx in userInfo.perms.prefixes)
-        {
-            if (key.substr(0, pfx.length) == pfx)
-            {
-                return true;
-            }
-        }
-        if (userInfo.type == 'client')
-        {
-            // Image permissions
-            if (key.substr(0, 14) == '/config/inode/')
-            {
-                const inode = this._decode(kv.key, kv.value);
-                if (inode && (inode.reader_group && userInfo.groups[inode.reader_group] ||
-                    inode.owner_group && userInfo.groups[inode.owner_group] ||
-                    inode.owner === userInfo.name))
-                {
-                    return true;
-                }
-                return false;
-            }
-            if (key.substr(0, 13) == '/index/image/')
-            {
-                const data = this._decode(kv.key, kv.value);
-                const inode = this._get([ ...this.prefix_parts, 'config', 'inode', data.pool_id, data.id ], true);
-                if (inode && (inode.reader_group && userInfo.groups[inode.reader_group] ||
-                    inode.owner_group && userInfo.groups[inode.owner_group] ||
-                    inode.owner === userInfo.name))
-                {
-                    return true;
-                }
-                return false;
-            }
-            if (key.substr(0, 13) == '/inode/stats/')
-            {
-                const [ pool_id, id ] = key.substr(13).split('/');
-                const inode = this._get([ ...this.prefix_parts, 'config', 'inode', pool_id, id ], true);
-                if (inode && (inode.reader_group && userInfo.groups[inode.reader_group] ||
-                    inode.owner_group && userInfo.groups[inode.owner_group] ||
-                    inode.owner === userInfo.name))
-                {
-                    return true;
-                }
-                return false;
-            }
-        }
-        return false;
-    }
-
-    _check_write(put, userInfo, checked)
-    {
-        let key = String(put.key);
-        if (key.substr(0, this.prefix.length) !== this.prefix)
-        {
-            return false;
-        }
-        key = key.substr(this.prefix.length);
-        if (userInfo.perms.keys[key])
-        {
-            return true;
-        }
-        for (const pfx in userInfo.perms.prefixes)
-        {
-            if (userInfo.perms.prefixes[pfx] && key.substr(0, pfx.length) == pfx)
-            {
-                return true;
-            }
-        }
-        if (checked && userInfo.type == 'client')
-        {
-            if (key.substr(0, 13) == '/index/maxid/' &&
-                checked['I'+parseInt(key.substr(13))+'_'+(put.value-1)])
-            {
-                // Allowed to increment maxid
-                return true;
-            }
-            if (checked['M'+key])
-            {
-                // Allowed to modify known images with CAS checks
-                return true;
-            }
-            if (key.substr(0, 14) == '/config/inode/' &&
-                checked['C'+key])
-            {
-                // Allowed to create an image with CAS checks and with read access
-                // to the parent image, if specified
-                const data = this._decode(put.key, put.value);
-                if (data.parent_id)
-                {
-                    const [ cur_pool_id ] = put.key.substr(14).split('/');
-                    const inode = this._get([ ...this.prefix_parts, 'config', 'inode', data.parent_pool || cur_pool_id, data.parent_id ], true);
-                    if (inode && (inode.reader_group && userInfo.groups[inode.reader_group] ||
-                        inode.owner_group && userInfo.groups[inode.owner_group] ||
-                        inode.owner === userInfo.name))
-                    {
-                        return true;
-                    }
-                }
-                return true;
-            }
-        }
-        return false;
-    }
-
-    _check_req(req, userInfo, checked)
-    {
-        let r;
-        if ((r = (req.request_range || req.requestRange)))
-        {
-            // All range queries are allowed, but responses are filtered - it's simpler
-        }
-        else if ((r = (req.request_put || req.requestPut)))
-        {
-            if (!this._check_write(r, userInfo, checked))
-                return false;
-        }
-        else if ((r = (req.request_delete_range || req.requestDeleteRange)))
-        {
-            if (!r.range_end || r.range_end === r.key)
-            {
-                if (!this._check_write({ key: r.key }, userInfo))
-                    return false;
-            }
-            else
-            {
-                // All keys in range must satisfy prefix
-                r.range_end = String(r.range_end);
-                if (r.key.length != r.range_end.length ||
-                    r.key[r.key.length-1] != '/' ||
-                    r.range_end[r.range_end.length-1] != '0')
-                {
-                    return false;
-                }
-                let key = r.key.substr(this.prefix.length);
-                let found = false;
-                for (const pfx in userInfo.perms.prefixes)
-                {
-                    if (userInfo.perms.prefixes[pfx] && key.substr(0, pfx.length) == pfx)
-                    {
-                        found = true;
-                        break;
-                    }
-                }
-                if (!found)
-                    return false;
-            }
-        }
-        return true;
-    }
-
-    _get_user(context)
-    {
-        if (context.user_type === 'osd' || context.user_type === 'mon' || context.user_type === 'admin')
-        {
-            return {
-                name: context.user_type,
-                type: context.user_type,
-                perms: static_perms[context.user_type],
-            };
-        }
-        if (!context.username)
-        {
-            return {};
-        }
-        let userInfo = this._get([ ...this.prefix_parts, 'config', 'user', context.username ], true);
-        if (!userInfo)
-        {
-            userInfo = {};
-        }
-        userInfo.perms = static_perms[userInfo.type] || static_perms['invalid'];
-        userInfo.name = context.username;
-        if (userInfo.groups instanceof Array)
-        {
-            userInfo.groups = userInfo.groups.reduce((a, c) => { a[c] = true; return a; }, {});
-        }
-        else
-        {
-            userInfo.groups = {};
-        }
-        return userInfo;
-    }
-
-    filter_api(context, api/*, data*/)
-    {
-        let type = 'client';
-        if (context.user_type === 'osd' || context.user_type === 'mon' || context.user_type === 'admin')
-        {
-            type = context.user_type;
-        }
-        return api_perms[type] && api_perms[type][api];
-    }
-
-    filter_txn(context, txn)
-    {
-        const userInfo = this._get_user(context);
-        if (!userInfo)
-        {
-            return null;
-        }
-        const checked = {};
-        if (txn.compare)
-        {
-            for (const check of txn.compare)
-            {
-                if (!this._check_compare(check, userInfo, checked))
-                    return null;
-            }
-        }
-        // Special transactions:
-        // 1. create image: create config/inode and index/image, increment index/maxid/<pool> (with CAS)
-        // 2. create snapshot: same as create image but also rename previous to @snap
-        if (txn.success)
-        {
-            for (const req of txn.success)
-            {
-                if (!this._check_req(req, userInfo, checked))
-                    return null;
-            }
-        }
-        if (txn.failure)
-        {
-            for (const req of txn.failure)
-            {
-                if (!this._check_req(req, userInfo, null))
-                    return null;
-            }
-        }
-        return txn;
-    }
-
-    filter_txn_response(context, txn, res)
-    {
-        if (!res.responses)
-        {
-            return;
-        }
-        const userInfo = this._get_user(context);
-        if (!userInfo)
-        {
-            for (const resp of res.responses)
-            {
-                if (resp.response_range && resp.response_range.kvs)
-                {
-                    resp.response_range.kvs = [];
-                }
-            }
-            return;
-        }
-        for (const resp of res.responses)
-        {
-            if (resp.response_range && resp.response_range.kvs)
-            {
-                resp.response_range.kvs = resp.response_range.kvs.filter(kv => this._check_read(kv, userInfo));
-            }
-        }
-    }
-
-    filter_watch_message(context, msg)
-    {
-        if (!msg.result || !msg.result.events)
-        {
-            return;
-        }
-        const userInfo = this._get_user(context);
-        if (!userInfo)
-        {
-            msg.result.events = [];
-            return;
-        }
-        msg.result.events = msg.result.events.filter(ev => this._check_read(ev.kv, userInfo));
-    }
-}
-
-module.exports = VitastorAuthFilter;

node-binding/package.json

@@ -1,6 +1,6 @@
 {
   "name": "vitastor",
-  "version": "3.2.2",
+  "version": "2.4.3",
   "description": "Low-level native bindings to Vitastor client library",
   "main": "index.js",
   "keywords": [