diff --git a/src/gc-get.c b/src/gc-get.c
index a32f2755..b33ba209 100644
--- a/src/gc-get.c
+++ b/src/gc-get.c
@@ -610,7 +610,7 @@ __hot static pgno_t relist_get_single(MDBX_txn *txn) {
    * диском будет более кучным, а у страниц ближе к концу БД будет больше шансов
    * попасть под авто-компактификацию. Частично эта тактика уже реализована, но
    * для её эффективности требуется явно приоритезировать выделение страниц:
-   *   - поддерживать для relist, для ближних и для дальних страниц;
+   *   - поддерживать два relist, для ближних и для дальних страниц;
    *   - использовать страницы из дальнего списка, если первый пуст,
    *     а второй слишком большой, либо при пустой GC.
    *
@@ -618,11 +618,11 @@ __hot static pgno_t relist_get_single(MDBX_txn *txn) {
    * регионы будут линейными, что принципиально ускоряет запись на HDD.
    * Одновременно, в среднем это не повлияет на чтение, точнее говоря, если
    * порядок чтения не совпадает с порядком изменения (иначе говоря, если
-   * чтение не коррклирует с обновлениями и/или вставками) то не повлияет, иначе
+   * чтение не коррелирует с обновлениями и/или вставками) то не повлияет, иначе
    * может ускорить. Однако, последовательности в среднем достаточно редки.
    * Поэтому для эффективности требуется аккумулировать и поддерживать в ОЗУ
    * огромные списки страниц, а затем сохранять их обратно в БД. Текущий формат
-   * БД (без битовых карт) для этого крайне не удачен. Поэтому эта тактика не
+   * БД (без сжатых битовых карт) для этого крайне не удачен. Поэтому эта тактика не
    * имеет шансов быть успешной без смены формата БД (Mithril).
    *
    * 3. Стараться экономить последовательности страниц. Это позволяет избегать
@@ -631,7 +631,7 @@ __hot static pgno_t relist_get_single(MDBX_txn *txn) {
    * информации от приложения библиотека не может знать насколько
    * востребованными будут последовательности в ближайшей перспективе, а
    * экономия последовательностей "на всякий случай" не только затратна
-   * сама-по-себе, но и работает во вред.
+   * сама-по-себе, но и работает во вред (добавляет хаоса).
    *
    * Поэтому:
    *  - в TODO добавляется разделение relist на «ближние» и «дальние» страницы,