mdbx: fix typos and punctuation

README-RU.md

@@ -14,28 +14,28 @@ and [by Yandex](https://translate.yandex.ru/translate?url=https%3A%2F%2Fgithub.c
 
 
 **Сейчас MDBX _активно перерабатывается_** и к середине 2018
-ожидается большое измените как API, так и формата базы данных.
+ожидается большое изменение как API, так и формата базы данных.
 К сожалению, обновление приведет к потере совместимости с
 предыдущими версиями.
 
-Цель этой революции в обеспечении более четкого надежного
+Цель этой революции - обеспечение более четкого надежного
-API и добавлении новых функции, а также в наделении базы данных
+API и добавление новых функции, а также наделение базы данных
 новыми свойствами.
 
 В настоящее время MDBX предназначена для Linux, а также
 поддерживает Windows (начиная с Windows Server 2008) в качестве
-дополнительно платформы. Поддержка других ОС может быть
+дополнительной платформы. Поддержка других ОС может быть
 обеспечена на коммерческой основе. Однако такие
 усовершенствования (т. е. pull-requests) могут быть приняты в
 мейнстрим только в том случае, если будет доступен
 соответствующий публичный и бесплатный сервис непрерывной
-интеграции (aka Countinious Integration).
+интеграции (aka Continuous Integration).
 
 ## Содержание
 
 - [Обзор](#Обзор)
   - [Сравнение с другими СУБД](#Сравнение-с-другими-СУБД)
-  - [История & Acknowledgements](#История)
+  - [История & Acknowledgments](#История)
 - [Основные свойства](#Основные-свойства)
 - [Сравнение производительности](#Сравнение-производительности)
   - [Интегральная производительность](#Интегральная-производительность)
@@ -62,8 +62,8 @@ _libmdbx_ позволяет множеству процессов совмес
 
 _libmdbx_ обеспечивает
 [serializability](https://en.wikipedia.org/wiki/Serializability)
-изменений и согласованность данных после аварий. При этом транзакции
+изменений и согласованность данных после аварий. При этом транзакции,
-изменяющие данные никак не мешают операциям чтения и выполняются строго
+изменяющие данные, никак не мешают операциям чтения и выполняются строго
 последовательно с использованием единственного
 [мьютекса](https://en.wikipedia.org/wiki/Mutual_exclusion).
 
@@ -101,7 +101,7 @@ Tables](https://github.com/leo-yuriev/libfpta), aka ["Позитивные
 Technologies](https://www.ptsecurity.ru).
 
 
-#### Acknowledgements
+#### Acknowledgments
 
 Howard Chu (Symas Corporation) - the author of LMDB,
 from which originated the MDBX in 2015.
@@ -113,7 +113,7 @@ which was used for begin development of LMDB.
 Основные свойства
 =================
 
-_libmdbx_ наследует все ключевые возможности и особенности от
+_libmdbx_ наследует все ключевые возможности и особенности
 своего прародителя [LMDB](https://en.wikipedia.org/wiki/Lightning_Memory-Mapped_Database),
 но с устранением ряда описываемых далее проблем и архитектурных недочетов.
 
@@ -193,7 +193,7 @@ github](https://github.com/pmwkaa/ioarena/tree/HL%2B%2B2015).
   1. Такое сравнение не совсем правомочно, его следует делать с движками
      ориентированными на хранение данных в памяти ([Tarantool](https://tarantool.io/), [Redis](https://redis.io/)).
 
-  2. Превосходство libmdbx становится еще более подавляющем, что мешает
+  2. Превосходство libmdbx становится еще более подавляющим, что мешает
      восприятию информации.
 
 ![Comparison #1: Integral Performance](https://raw.githubusercontent.com/wiki/leo-yuriev/libmdbx/img/perf-slide-1.png)
@@ -217,7 +217,7 @@ github](https://github.com/pmwkaa/ioarena/tree/HL%2B%2B2015).
 
  - Логарифмическая шкала справа и желтые интервальные отрезки
    соответствуют времени выполнения транзакций. При этом каждый отрезок
-   показывает минимальное и максимальное время затраченное на выполнение
+   показывает минимальное и максимальное время, затраченное на выполнение
    транзакций, а крестиком отмечено среднеквадратичное значение.
 
 Выполняется **10.000 транзакций в режиме синхронной фиксации данных** на
@@ -243,7 +243,7 @@ github](https://github.com/pmwkaa/ioarena/tree/HL%2B%2B2015).
 
  - Логарифмическая шкала справа и желтые интервальные отрезки
    соответствуют времени выполнения транзакций. При этом каждый отрезок
-   показывает минимальное и максимальное время затраченное на выполнение
+   показывает минимальное и максимальное время, затраченное на выполнение
    транзакций, а крестиком отмечено среднеквадратичное значение.
 
 Выполняется **100.000 транзакций в режиме отложенной фиксации данных**
@@ -274,7 +274,7 @@ _libmdbx_ при этом не ведет WAL, а передает весь ко
 
  - Логарифмическая шкала справа и желтые интервальные отрезки
    соответствуют времени выполнения транзакций. При этом каждый отрезок
-   показывает минимальное и максимальное время затраченное на выполнение
+   показывает минимальное и максимальное время, затраченное на выполнение
    транзакций, а крестиком отмечено среднеквадратичное значение.
 
 Выполняется **1.000.000 транзакций в режиме асинхронной фиксации
@@ -283,7 +283,7 @@ _libmdbx_ при этом не ведет WAL, а передает весь ко
 консистентны на момент завершения одной из транзакций, но допускается
 потеря изменений из значительного количества последних транзакций. Во
 всех движках при этом включался режим предполагающий минимальную
-нагрузку на диск по-записи, и соответственно минимальную гарантию
+нагрузку на диск по записи, и соответственно минимальную гарантию
 сохранности данных. В _libmdbx_ при этом используется режим асинхронной
 записи измененных страниц на диск посредством ядра ОС и системного
 вызова [msync(MS_ASYNC)](https://linux.die.net/man/2/msync).
@@ -348,7 +348,7 @@ _libmdbx_ при этом не ведет WAL, а передает весь ко
    > _libmdbx_ фиксация транзакции также требует от 2 IOPS. Однако, в БД с
    > журналом кол-во IOPS будет меняться в зависимости от файловой системы,
    > но не от кол-ва записей или их объема. Тогда как в _libmdbx_ кол-во
-   > будет расти логарифмически от кол-во записей/строк в БД (по высоте
+   > будет расти логарифмически от кол-ва записей/строк в БД (по высоте
    > b+tree).
 
 3. [COW](https://ru.wikipedia.org/wiki/%D0%9A%D0%BE%D0%BF%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5_%D0%BF%D1%80%D0%B8_%D0%B7%D0%B0%D0%BF%D0%B8%D1%81%D0%B8)
@@ -364,7 +364,7 @@ _libmdbx_ при этом не ведет WAL, а передает весь ко
    > значительного копирования данных в памяти и массы других затратных операций.
    > Поэтому обусловленное этим недостатком падение производительности становится
    > заметным только при отказе от фиксации изменений на диске.
-   > Соответственно, корректнее сказать что _libmdbx_ позволяет
+   > Соответственно, корректнее сказать, что _libmdbx_ позволяет
    > получить персистентность ценой минимального падения производительности.
    > Если же нет необходимости оперативно сохранять данные, то логичнее
    > использовать `std::map`.
@@ -457,7 +457,7 @@ _libmdbx_ при этом не ведет WAL, а передает весь ко
 
 Однако, при аварийном отключении питания или сбое в ядре ОС, на диске
 может быть сохранена только часть измененных страниц БД. При этом с большой
-вероятностью может оказаться так, что будут сохранены мета-страницы со
+вероятностью может оказаться, что будут сохранены мета-страницы со
 ссылками на страницы с новыми версиями данных, но не сами новые данные.
 В этом случае БД будет безвозвратна разрушена, даже если до аварии
 производилась полная синхронизация данных (посредством
@@ -471,11 +471,11 @@ _libmdbx_ при этом не ведет WAL, а передает весь ко
   с переносом изменений после фиксации данных.
 
 * При завершении транзакций, в зависимости от состояния
-  синхронности данных между диском и оперативной память,
+  синхронности данных между диском и оперативной памятью,
   _libmdbx_ помечает точки фиксации либо как сильные (strong),
   либо как слабые (weak). Так например, в режиме
   `WRITEMAP+MAPSYNC` завершаемые транзакции помечаются как
-  слабые, а при явной синхронизации данных как сильные.
+  слабые, а при явной синхронизации данных - как сильные.
 
 * В _libmdbx_ поддерживается не две, а три отдельные мета-страницы.
   Это позволяет выполнять фиксацию транзакций с формированием как
@@ -489,20 +489,20 @@ _libmdbx_ при этом не ведет WAL, а передает весь ко
   сильной фиксации. Этим обеспечивается гарантия сохранности БД.
 
 Такая гарантия надежности не дается бесплатно. Для
-сохранности данных, страницы формирующие крайний снимок с
+сохранности данных, страницы, формирующие крайний снимок с
 сильной фиксацией, не должны повторно использоваться
 (перезаписываться) до формирования следующей сильной точки
 фиксации. Таким образом, крайняя точка фиксации создает
 описанный выше эффект "долгого чтения". Разница же здесь в том,
 что при исчерпании свободных страниц ситуация будет
 автоматически исправлена, посредством записи изменений на диск
-и формированием новой сильной точки фиксации.
+и формирования новой сильной точки фиксации.
 
 Таким образом, в режиме безопасной асинхронной фиксации _libmdbx_ будет
 всегда использовать новые страницы до исчерпания места в БД или до явного
 формирования сильной точки фиксации посредством `mdbx_env_sync()`.
-При этом суммарный трафик записи на диск будет примерно такой-же,
+При этом суммарный трафик записи на диск будет примерно такой же,
-как если бы отдельно фиксировалась каждая транзакций.
+как если бы отдельно фиксировалась каждая транзакция.
 
 В текущей версии _libmdbx_ вам предоставляется выбор между безопасным
 режимом (по умолчанию) асинхронной фиксации, и режимом `UTTERLY_NOSYNC` когда
@@ -535,7 +535,7 @@ _libmdbx_ при этом не ведет WAL, а передает весь ко
 
 	Посредством `mdbx_env_set_oomfunc()` может быть установлен
 	внешний обработчик (callback), который будет вызван при
-	исчерпания свободных страниц из-за долгой операцией чтения.
+	исчерпании свободных страниц из-за долгой операцией чтения.
 	Обработчику будет передан PID и pthread_id виновника.
 	В свою очередь обработчик может предпринять одно из действий:
 
@@ -545,7 +545,7 @@ _libmdbx_ при этом не ведет WAL, а передает весь ко
 	* отменить или перезапустить проблемную операцию чтения, если
 	  операция выполняется одним из потоков текущего процесса;
 
-	* подождать некоторое время, в расчете что проблемная операция
+	* подождать некоторое время, в расчете на то, что проблемная операция
 	  чтения будет штатно завершена;
 
 	* прервать текущую операцию изменения данных с возвратом кода
@@ -612,7 +612,7 @@ _libmdbx_ при этом не ведет WAL, а передает весь ко
 19. Возможность посредством `mdbx_is_dirty()` определить находятся ли
 некоторый ключ или данные в "грязной" странице БД. Таким образом,
 избегая лишнего копирования данных перед выполнением модифицирующих
-операций (значения в размещенные "грязных" страницах могут быть
+операций (значения, размещенные в "грязных" страницах, могут быть
 перезаписаны при изменениях, иначе они будут неизменны).
 
 20. Корректное обновление текущей записи, в том числе сортированного
@@ -632,7 +632,7 @@ _libmdbx_ при этом не ведет WAL, а передает весь ко
   >
   >  - обращение к уже освобожденной памяти;
   >  - попытки повторного освобождения памяти;
-  >  - memory corruption and segfaults.
+  >  - повреждение памяти и ошибки сегментации.
 
 22. Дополнительный код ошибки `MDBX_EMULTIVAL`, который возвращается из
 `mdbx_put()` и `mdbx_replace()` при попытке выполнить неоднозначное
@@ -666,7 +666,7 @@ _libmdbx_ при этом не ведет WAL, а передает весь ко
 цикле обновления данных и записи на диск. Фактически _libmdbx_ выполняет
 постоянную компактификацию данных, но не затрачивая на это
 дополнительных ресурсов, а только освобождая их. При освобождении места
-в БД и установки соответствующих параметров геометрии базы данных, также будет
+в БД и установке соответствующих параметров геометрии базы данных, также будет
 уменьшаться размер файла на диске, в том числе в **Windows**.
 
 --------------------------------------------------------------------------------

README.md

@@ -16,7 +16,7 @@ libmdbx
    2. Support for [raw block devices](https://en.wikipedia.org/wiki/Raw_device);
    3. Separate place (HDD) for large data items;
    4. Using "[Roaring bitmaps](http://roaringbitmap.org/about/)" inside garbage collector;
-   5. Non-sequental reclaiming, like PostgreSQL's [Vacuum](https://www.postgresql.org/docs/9.1/static/sql-vacuum.html);
+   5. Non-sequential reclaiming, like PostgreSQL's [Vacuum](https://www.postgresql.org/docs/9.1/static/sql-vacuum.html);
    6. [Asynchronous lazy data flushing](https://sites.fas.harvard.edu/~cs265/papers/kathuria-2008.pdf) to disk(s);
    7. etc...
 
@@ -33,7 +33,7 @@ Integration service will be available.
 
 - [Overview](#overview)
   - [Comparison with other DBs](#comparison-with-other-dbs)
-  - [History & Acknowledgements](#history)
+  - [History & Acknowledgments](#history)
 - [Main features](#main-features)
 - [Performance comparison](#performance-comparison)
   - [Integral performance](#integral-performance)
@@ -73,7 +73,7 @@ Because  _libmdbx_ is currently overhauled, I think it's better to just link
 
 ### History
 
-_libmdbx_ design is based on [Lightning Memory-Mapped Database](https://en.wikipedia.org/wiki/Lightning_Memory-Mapped_Database).
+The _libmdbx_ design is based on [Lightning Memory-Mapped Database](https://en.wikipedia.org/wiki/Lightning_Memory-Mapped_Database).
 Initial development was going in [ReOpenLDAP](https://github.com/leo-yuriev/ReOpenLDAP) project, about a year later it
 received separate development effort and in autumn 2015 was isolated to separate project, which was
 [presented at Highload++ 2015 conference](http://www.highload.ru/2015/abstracts/1831.html).
@@ -81,7 +81,7 @@ received separate development effort and in autumn 2015 was isolated to separate
 Since early 2017 _libmdbx_ is used in [Fast Positive Tables](https://github.com/leo-yuriev/libfpta),
 by [Positive Technologies](https://www.ptsecurity.com).
 
-#### Acknowledgements
+#### Acknowledgments
 
 Howard Chu (Symas Corporation) - the author of LMDB,
 from which originated the MDBX in 2015.
@@ -277,7 +277,7 @@ scanning data directory.
 #### Long-time read transactions problem
 
 Garbage collection problem exists in all databases one way or another (e.g. VACUUM in PostgreSQL).
-But in _libmbdx_ and LMDB it's even more important because of high performance and deliberate
+But in _libmdbx_ and LMDB it's even more important because of high performance and deliberate
 simplification of internals with emphasis on performance.
 
 * Altering data during long read operation may exhaust available space on persistent storage.
@@ -313,7 +313,7 @@ _libmdbx_ addresses the problem, details below. Illustrations to this problem ca
 In `WRITEMAP+MAPSYNC` mode dirty pages are written to persistent storage by kernel. This means that in case of application
 crash OS kernel will write all dirty data to disk and nothing will be lost. But in case of hardware malfunction or OS kernel
 fatal error only some dirty data might be synced to disk, and there is high probability that pages with metadata saved,
-will point to non-saved, hence non-existent, data pages. In such situation DB is completely corrupted and can't be
+will point to non-saved, hence non-existent, data pages. In such situation, DB is completely corrupted and can't be
 repaired even if there was full sync before the crash via `mdbx_env_sync().
 
 _libmdbx_ addresses this by fully reimplementing write path of data:
@@ -352,7 +352,7 @@ Improvements over LMDB
 1. `LIFO RECLAIM` mode:
 
 	The newest pages are picked for reuse instead of the oldest.
-	This allows to minimize reclaim loop and make it execution time independent from total page count.
+	This allows to minimize reclaim loop and make it execution time independent of total page count.
 
 	This results in OS kernel cache mechanisms working with maximum efficiency.
 	In case of using disk controllers or storages with
@@ -364,7 +364,7 @@ Improvements over LMDB
 	`mdbx_env_set_oomfunc()` allows to set a callback, which will be called
 	in the event of memory exhausting during long-time read transaction.
 	Callback will be invoked with PID and pthread_id of offending thread as parameters.
-	Callback can do any of this things to remedy the problem:
+	Callback can do any of these things to remedy the problem:
 
 	* wait for read transaction to finish normally;
 
@@ -408,7 +408,7 @@ Improvements over LMDB
 15. Ability to close DB in "dirty" state (without data flush and creation of steady synchronization point)
     via `mdbx_env_close_ex()`.
 
-16. Ability to get addition info, including number of the oldest snapshot of DB, which is used by one of the readers.
+16. Ability to get additional info, including number of the oldest snapshot of DB, which is used by one of the readers.
     Implemented via `mdbx_env_info()`.
 
 17. `mdbx_del()` doesn't ignore additional argument (specifier) `data`
@@ -417,7 +417,7 @@ Improvements over LMDB
 
 18. Ability to open dbi-table with simultaneous setup of comparators for keys and values, via `mdbx_dbi_open_ex()`.
 
-19. Ability to find out if key or value are in dirty page. This may be useful to make a decision to avoid
+19. Ability to find out if key or value is in dirty page. This may be useful to make a decision to avoid
     excessive CoW before updates. Implemented via `mdbx_is_dirty()`.
 
 20. Correct update of current record in `MDBX_CURRENT` mode of `mdbx_cursor_put()`, including sorted duplicated.
@@ -448,12 +448,12 @@ Improvements over LMDB
 27. Advanced dynamic control over DB size, including ability to choose page size via `mdbx_env_set_geometry()`,
     including on Windows.
 
-28. Three meta-pages instead two, this allows to guarantee consistently update weak sync-points without risking to
+28. Three meta-pages instead of two, this allows to guarantee consistently update weak sync-points without risking to
     corrupt last steady sync-point.
 
-29. Automatic reclaim of freed pages to specific reserved space in the end of database file. This lowers amount of pages,
+29. Automatic reclaim of freed pages to specific reserved space at the end of database file. This lowers amount of pages,
     loaded to memory, used in update/flush loop. In fact _libmdbx_ constantly performs compactification of data,
-    but doesn't use addition resources for that. Space reclaim of DB and setup of database geometry parameters also decreases
+    but doesn't use additional resources for that. Space reclaim of DB and setup of database geometry parameters also decreases
     size of the database on disk, including on Windows.
 
 --------------------------------------------------------------------------------

TODO.md

@@ -70,7 +70,7 @@
 - [x] Привести в порядок volatile.
 - [x] контроль meta.mapsize.
 - [x] переработка формата: заголовки страниц, meta, clk...
-- [x] зачистка Doxygen и бесполезных коментариев.
+- [x] зачистка Doxygen и бесполезных комментариев.
 - [x] Добавить поле типа контрольной суммы.
 - [x] Добавить поле/флаг размера pgno_t.
 - [x] Поменять сигнатуры.