Some fixes

Author: socketpair

main.rst

@@ -63,7 +63,6 @@
    Смотрим по ``ceph -s`` какой менеджер активен и подключаемся туда на порт ???? (вписать).
 
 
-
 CephFS
 ------
 
@@ -104,9 +103,9 @@ Bluestore
 
 * Какие размеры БД и вал нужны + средства как посмотреть текущее
 * WAL находится в БД. БД находится в блюсторе. Если вынести БД то она вместе
-  с журналом выносится. Вроде БД так устроена что самое хот выносится в
-  начало. Часть БД может быть отдельно а часть в том же месте где основное
-  хранилище если БД слишком большая.
+  с журналом выносится. Вроде (нужен пруф) БД устроена так что самые горячие
+  данные хранятся в её начале. Если БД не вмещается под отведённое место (если
+  она выносная) то часть БД хранится отдельно, а часть в основном хранилище.
 * Нет возможности после создания БД встроенной вынести её отдельно. Аналогично
   с её WAL.
 
@@ -122,14 +121,14 @@ Bluestore
   в т.ч. так как не понятно, понял ли что диск rotational.
 
 * По исходникам смотрел -- он определяет что диск rotational и из этого делает
-  вывод SSD или нет. В том числе при старте осд оно смотрит не назначен ли класс
-  осд и ставит ssd/hdd на основании этого. А ещё применяет настройки разные в
-  зависимости от этого. Bcache (всегда?) ставит что non-rotational ДАЖЕ ЕСЛИ
-  РЕАЛЬНЫЙ КЕШ НЕ ПРИАТТАЧЕН к кеш-девайсу.
+  вывод SSD или нет. В том числе при старте OSD оно смотрит не назначен ли класс
+  OSD и ставит ssd/hdd на основании этого. А ещё применяет разные настройки в
+  зависимости от этого. Bcache (всегда?) ставит флаг что диск что non-rotational
+  ДАЖЕ ЕСЛИ РЕАЛЬНЫЙ КЕШ НЕ ПРИАТТАЧЕН к кеш-девайсу.
 
 Как работает
 ------------
-
+* Tiering vs bcache vs dm-cache + инструкции по дмкешу.
 * почему дедупликация крайне затруднена в архитектуре Ceph
 * в файлсторе всё полностью пишется в журнал. один врайт превращается в два сисколла врайт
   - один в журнал (с синком) и один в основное хранилище. Но основное хранилище фсинкается
@@ -237,10 +236,18 @@ Bluestore
 Процессоры и память
 -------------------
 
-* ECC - потому что сбой в памяти мастер-осд в актинг сете приведёт к повреждению данных
-  даже если это BlueStore со своим крк - данные могут быть испорчены до подсчёта крк и распространены
-  по слейвам.
-* говернор и паверсейв.
+* Для Ceph-нодов требуется (не рекомендуется) память с ECC. Сбой в памяти
+  мастер-OSD в acting set приведёт к необнаруживаемому повреждению данных
+  даже если это BlueStore со своим CRC32c. Данные могут повредиться до
+  подсчёта CRC32 и распространиться по slave-OSD.
+
+  Немного близкая тема и про клиентов. Если данные испорчены до подсчёта
+  CRC32 в рамках протокола мессенджера Ceph, то они будут повреждены и это
+  не обнаружится.
+
+* CPU Governor & powersave mode. Отличная статья в арче:
+  https://wiki.archlinux.org/index.php/CPU_frequency_scaling
+
 * CRC32 аппаратное в блюсторе (и в месенджере не с блюстором?)
 * гипертрединг нинужен. потому что это просто доп-набор регистров. В цефе по идее нет цпу-боунд задач
   есть крк32 но оно реализуется через спец команду в sse4.3 а такой блок емнип один на ядро.