WIP Architecture in english

docs/intro/architecture.en.md

@@ -80,71 +80,67 @@ All other client-side components are based on the client library:
 - **vitastor-disk** — утилита для разметки дисков под Vitastor OSD. С её помощью можно
   создавать, удалять, менять размеры или перемещать разделы OSD.
 
-## Overall read/write process
+## Общий процесс записи и чтения
 
-- Vitastor stores virtual disks, also named "images" or "inodes".
+- В Vitastor хранятся виртуальные диски, также называемые "образы" или "иноды".
-- Each image is stored in some pool. Pool specifies storage parameters such as redundancy
+- Каждый образ хранится в определённом пуле. Пул определяет параметры хранения образов в нём,
-  scheme (replication or EC — erasure codes, i.e. error correction codes), failure domain
+  такие, как схему избыточности (репликация или EC — коды коррекции ошибок), домен отказа
-  and restrictions on OSD selection for image data placement. See [Pool configuration](../config/pool.en.md) for details.
+  и ограничения по выбору OSD для размещения данных образов. См. [Конфигурация пулов](../config/pool.ru.md).
-- Each image is split into objects/blocks of fixed size, equal to [block_size](../config/layout-cluster.en.md#block_size)
+- Каждый образ разбивается на объекты фиксированного размера, равного [block_size](../config/layout-cluster.ru.md#block_size)
-  (128 KB by default), multiplied by data part count for EC or 1 for replicas. That is,
+  (по умолчанию 128 КБ), умноженному на число частей данных для EC или на 1 для реплик.
-  if a pool uses EC 4+2 coding scheme (4 data parts + 2 parity parts), then, with the
+  То есть, например, если в пуле используется схема кодирования 4+2 (4 части данных + 2 чётности),
-  default block_size, images are split into 512 KB objects.
+  то при стандартном block_size образы разбиваются на части по 512 КБ.
-- Client read/write requests are split into parts at object boundaries.
+- Клиентские запросы чтения/записи разделяются на части, соответствующие этим объектам.
-- Each object is mapped to a PG number it belongs to, by simply taking a remainder of
+- Для каждого объекта определяется номер PG, которой он принадлежит, путём простого взятия
-  division of its offset by PG count of the image's pool.
+  остатка от деления ID образа и смещения на число PG в пуле, которому принадлежит образ.
-- Client reads primary OSD for all PGs from etcd. Primary OSD for each PG is assigned
+- Клиент читает информацию о первичном OSD всех PG из etcd. Первичный OSD каждой PG назначается
-  by the monitor during cluster operation, along with the full PG OSD set.
+  монитором в процессе работы кластера, вместе с текущим целевым набором OSD этой PG.
-- If not already connected, client connects to primary OSDs of all PGs involved in a
+- Клиент соединяется (если ещё не соединён) с первичными OSD всех PG, объекты которых участвуют
-  read/write request and sends parts of the request to them.
+  в запросе и одновременно отправляет им запросы чтения/записи частей.
-- If a primary OSD is unavailable, client retries connection attempts indefinitely
+- Если какие-то из первичных OSD недоступны, клиент повторяет попытки соединения бесконечно до
-  either until it becomes available or until the monitor assigns another OSD as primary
+  тех пор, пока они не станут доступны или пока PG не будут назначены другие первичные OSD.
-  for that PG.
+- Клиент также повторяет запросы, если первичные OSD отвечают кодом ошибки EPIPE, означающим,
-- Client also retries requests if the primary OSD replies with error code EPIPE, meaning
+  что запрос не может быть обработан в данный момент. Это происходит, если PG либо не активна
-  that the PG is inactive at this OSD at the moment - for example, when the primary OSD
+  вообще, либо не активна на данном OSD в данный момент (например, если в этот момент меняется
-  is switched, or if the primary OSD itself loses connection to replicas during request
+  её первичный OSD) или если в процессе обработки запроса сам первичный OSD теряет подключение
-  handling.
+  к репликам.
-- Primary OSD determines where the parts of the object are stored. By default, all objects
+- Первичный OSD определяет, на каких OSD находятся части объекта. По умолчанию все объекты
-  are assumed to be stored at the target OSD set of a PG, but some of them may be present
+  считаются находящимися на текущем целевом наборе OSD соответствующей PG, но какие-то могут
-  at a different OSD set if they are degraded or moved, or if the data rebalancing process
+  находиться на других OSD, если эти объекты деградированы или перемещены, или идёт процесс
-  is active. OSDs doesn't do any network requests, if calculates locations of all objects
+  ребаланса. Запросы для проверки по сети не отправляются, информация о местоположении всех
-  during PG activation and stores it in memory.
+  объектов рассчитывается первичным OSD при активации PG и хранится в памяти.
-- Primary OSD handles the request locally when it can - for example, when it's a read
+- Первичный OSD соединяется (если ещё не соединён) с вторичными OSD, на которых располагаются
-  from a replicated pool or when it's a read from a EC pool involving only one data part
+  части объекта, и отправляет им запросы чтения/записи, а также читает/пишет из/в своё локальное
-  stored on the OSD's local disk.
+  хранилище, если сам входит в набор.
-- When a request requires reads or writes to additional OSDs, primary OSD uses already
+- После завершения всех вторичных операций чтения/записи первичный OSD отправляет ответ клиенту.
-  established connections to secondary OSDs of the PG to execute these requests. This happens
-  in parallel to local disk operations. All such connections are guaranteed to be already
-  established when the PG is active, and if any of them is dropped, PG is restarted and
-  all current read/write operations to it fail with EPIPE error and are retried by clients.
-- After completing all secondary read/write requests, primary OSD sends the response to
-  the client.
 
-### Nuances of request handling
+### Особенности обработки запросов
 
-- If a pool uses erasure codes and some of the OSDs are unavailable, primary OSDs recover
+- Если в пуле используются коды коррекции ошибок и при этом часть OSD недоступна, первичный
-  data from the remaining parts during read.
+  OSD при чтении восстанавливает данные из оставшихся частей.
-- Each object has a version number. During write, primary OSD first determines the current
+- Каждый объект имеет номер версии. При записи объекта первичный OSD сначала читает из номер
-  version of the object. As primary OSD usually stores the object or its part itself, most
+  версии объекта. Так как первичный OSD обычно сам хранит копию или часть объекта, номер
-  of the time version is read from the memory of the OSD itself. However, if primary OSD
+  версии обычно читается из памяти самого OSD. Однако, если ни одна часть обновляемого объекта
-  doesn't contain parts of the object, it requests the version number from a secondary OSD
+  не находится на первичном OSD, для получения номера версии он обращается к одному из вторичных
-  which has that part. Such request still doesn't involve reading from the disk though,
+  OSD, на которых копия объекта есть. Обращения к диску при этом всё равно не происходит,
-  because object metadata, including version number, is always stored in OSD memory.
+  так как метаданные объектов, включая номер версии, все OSD хранят в памяти.
-- If a pool uses erasure codes, partial writes of an object require reading other parts of
+- Если в пуле используются коды коррекции ошибок, перед частичной записью объекта для вычисления
-  it from secondary OSDs or from the local disk of the primary OSD itself. This is called
+  чётности зачастую требуется чтение частей объекта с вторичных OSD или с локального диска
-  "read-modify-write" process.
+  самого первичного OSD.
-- If a pool uses erasure codes, two-phase write process is used to get rid of the Write Hole
+- Также, если в пуле используются коды коррекции ошибок, для закрытия Write Hole применяется
-  problem: first a new version of object parts is written to all secondary OSDs without
+  двухфазный алгоритм записи: сначала на все вторичные OSD записывается новая версия частей
-  removing the previous version, and then, after receiving successful write confirmations
+  объекта, но при этом старая версия не удаляется, а потом, после получения подтверждения
-  from all OSDs, new version is committed and the old one is allowed to be removed.
+  успешной записи от всех вторичных OSD, новая версия фиксируется и разрешается удаление старой.
-- In a pool doesn't use immediate_commit mode, then write requests sent by clients aren't
+- Если в кластере не включён режим immediate_commit, то запросы записи, отправляемые клиентами,
-  treated as committed to physical media instantly. Clients have to send separate type of
+  не считаются зафиксированными на физических накопителях сразу. Для фиксации данных клиенты
-  requests (SYNC) to commit changes, and before it isn't sent, new versions of data are
+  должны отдельно отправлять запросы SYNC (отдельный от чтения и записи вид запроса),
-  allowed to be lost if some OSDs die. Thus, when immediate_commit is disabled, clients
+  а пока такой запрос не отправлен, считается, что записанные данные могут исчезнуть,
-  store copies of all write requests in memory and repeat them from there when the
+  если соответствующий OSD упадёт. Поэтому, когда режим immediate_commit отключён, все
-  connection to primary OSD is lost. This in-memory copy is removed after a successful
+  запросы записи клиенты копируют в памяти и при потере соединения и повторном соединении
-  SYNC, and to prevent excessive memory usage, clients also do an automatic SYNC
+  с OSD повторяют из памяти. Скопированные в память данные удаляются при успешном fsync,
-  every [client_dirty_limit](../config/network.en.md#client_dirty_limit) written bytes.
+  а чтобы хранение этих данных не приводило к чрезмерному потреблению памяти, клиенты
+  автоматически выполняют fsync каждые [client_dirty_limit](../config/network.ru.md#client_dirty_limit)
+  записанных байт.
 
 ## Similarities to Ceph
 

docs/intro/architecture.ru.md

@@ -114,22 +114,16 @@
   находиться на других OSD, если эти объекты деградированы или перемещены, или идёт процесс
   ребаланса. Запросы для проверки по сети не отправляются, информация о местоположении всех
   объектов рассчитывается первичным OSD при активации PG и хранится в памяти.
-- Когда это возможно, первичный OSD обрабатывает запрос локально. Например, так происходит
+- Первичный OSD соединяется (если ещё не соединён) с вторичными OSD, на которых располагаются
-  при чтениях объектов из пулов с репликацией или при чтении из EC пула, затрагивающего
+  части объекта, и отправляет им запросы чтения/записи, а также читает/пишет из/в своё локальное
-  только часть, хранимую на диске самого первичного OSD.
+  хранилище, если сам входит в набор.
-- Когда запрос требует записи или чтения с вторичных OSD, первичный OSD использует заранее
-  установленные соединения с ними для выполнения этих запросов. Это происходит параллельно
-  локальным операциям чтения/записи с диска самого OSD. Так как соединения к вторичным OSD PG
-  устанавливаются при её запуске, то они уже гарантированно установлены, когда PG активна,
-  и если любое из этих соединений отключается, PG перезапускается, а все текущие запросы чтения
-  и записи в неё завершаются с ошибкой EPIPE, после чего повторяются клиентами.
 - После завершения всех вторичных операций чтения/записи первичный OSD отправляет ответ клиенту.
 
 ### Особенности обработки запросов
 
 - Если в пуле используются коды коррекции ошибок и при этом часть OSD недоступна, первичный
   OSD при чтении восстанавливает данные из оставшихся частей.
-- Каждый объект имеет номер версии. При записи объекта первичный OSD сначала получает номер
+- Каждый объект имеет номер версии. При записи объекта первичный OSD сначала читает из номер
   версии объекта. Так как первичный OSD обычно сам хранит копию или часть объекта, номер
   версии обычно читается из памяти самого OSD. Однако, если ни одна часть обновляемого объекта
   не находится на первичном OSD, для получения номера версии он обращается к одному из вторичных
@@ -137,20 +131,20 @@
   так как метаданные объектов, включая номер версии, все OSD хранят в памяти.
 - Если в пуле используются коды коррекции ошибок, перед частичной записью объекта для вычисления
   чётности зачастую требуется чтение частей объекта с вторичных OSD или с локального диска
-  самого первичного OSD. Это называется процессом "чтение-модификация-запись" (read-modify-write).
+  самого первичного OSD.
-- Если в пуле используются коды коррекции ошибок, для закрытия Write Hole применяется
+- Также, если в пуле используются коды коррекции ошибок, для закрытия Write Hole применяется
   двухфазный алгоритм записи: сначала на все вторичные OSD записывается новая версия частей
   объекта, но при этом старая версия не удаляется, а потом, после получения подтверждения
   успешной записи от всех вторичных OSD, новая версия фиксируется и разрешается удаление старой.
-- Если в пуле не включён режим immediate_commit, то запросы записи, отправляемые клиентами,
+- Если в кластере не включён режим immediate_commit, то запросы записи, отправляемые клиентами,
   не считаются зафиксированными на физических накопителях сразу. Для фиксации данных клиенты
   должны отдельно отправлять запросы SYNC (отдельный от чтения и записи вид запроса),
   а пока такой запрос не отправлен, считается, что записанные данные могут исчезнуть,
   если соответствующий OSD упадёт. Поэтому, когда режим immediate_commit отключён, все
   запросы записи клиенты копируют в памяти и при потере соединения и повторном соединении
-  с OSD повторяют из памяти. Скопированные в память данные удаляются при успешном SYNC,
+  с OSD повторяют из памяти. Скопированные в память данные удаляются при успешном fsync,
   а чтобы хранение этих данных не приводило к чрезмерному потреблению памяти, клиенты
-  автоматически выполняют SYNC каждые [client_dirty_limit](../config/network.ru.md#client_dirty_limit)
+  автоматически выполняют fsync каждые [client_dirty_limit](../config/network.ru.md#client_dirty_limit)
   записанных байт.
 
 ## Схожесть с Ceph

src/disk_tool/disk_tool_resize.cpp

@@ -123,14 +123,6 @@ int disk_tool_t::resize_parse_params()
         ? parse_size(options["new_journal_offset"]) : dsk.journal_offset;
     new_journal_len = options.find("new_journal_len") != options.end()
         ? parse_size(options["new_journal_len"]) : dsk.journal_len;
-    if (new_data_len+new_data_offset > dsk.data_device_size)
-        new_data_len = dsk.data_device_size-new_data_offset;
-    if (new_meta_device == dsk.data_device && new_data_offset < new_meta_offset &&
-        new_data_len+new_data_offset > new_meta_offset)
-        new_data_len = new_meta_offset-new_data_offset;
-    if (new_journal_device == dsk.data_device && new_data_offset < new_journal_offset &&
-        new_data_len+new_data_offset > new_journal_offset)
-        new_data_len = new_journal_offset-new_data_offset;
     if (new_meta_device == dsk.meta_device &&
         new_journal_device == dsk.journal_device &&
         new_data_offset == dsk.data_offset &&
@@ -228,10 +220,10 @@ int disk_tool_t::resize_remap_blocks()
     }
     for (uint64_t i = 0; i < free_last; i++)
     {
-        if (data_alloc->get(total_blocks-i-1))
+        if (data_alloc->get(total_blocks-i))
-            data_remap[total_blocks-i-1] = 0;
+            data_remap[total_blocks-i] = 0;
         else
-            data_alloc->set(total_blocks-i-1, true);
+            data_alloc->set(total_blocks-i, true);
     }
     for (auto & p: data_remap)
     {
@@ -490,7 +482,7 @@ int disk_tool_t::resize_rewrite_meta()
                 block_num = remap_it->second;
             if (block_num < free_first || block_num >= total_blocks-free_last)
             {
-                fprintf(stderr, "BUG: remapped block %lu not in range %lu..%lu\n", block_num, free_first, total_blocks-free_last);
+                fprintf(stderr, "BUG: remapped block not in range\n");
                 exit(1);
             }
             block_num += data_idx_diff;