docs/config/layout-osd.en.md

@@ -118,13 +118,12 @@ Physical block size of the journal device. Must be a multiple of
 - Type: boolean
 - Default: false
 
-Do not issue fsyncs to the data device, i.e. do not force it to flush cache.
-Safe ONLY if your data device has write-through cache or if write-back
-cache is disabled. If you disable drive cache manually with `hdparm` or
-writing to `/sys/.../scsi_disk/cache_type` then make sure that you do it
-every time before starting Vitastor OSD (vitastor-disk does it automatically).
-See also [immediate_commit](layout-cluster.en.md#immediate_commit)
-for information about how to benefit from disabled cache.
+Do not issue fsyncs to the data device, i.e. do not flush its cache.
+Safe ONLY if your data device has write-through cache. If you disable
+the cache yourself using `hdparm` or `scsi_disk/cache_type` then make sure
+that the cache disable command is run every time before starting Vitastor
+OSD, for example, in the systemd unit. See also `immediate_commit` option
+for the instructions to disable cache and how to benefit from it.
 
 ## disable_meta_fsync
 
@@ -172,7 +171,8 @@ size, it actually has to write the whole 4 KB sector.
 
 Because of this it can actually be beneficial to use SSDs which work well
 with 512 byte sectors and use 512 byte disk_alignment, journal_block_size
-and meta_block_size. But at the moment, no such SSDs are known...
+and meta_block_size. But the only SSD that may fit into this category is
+Intel Optane (probably, not tested yet).
 
 Clients don't need to be aware of disk_alignment, so it's not required to
 put a modified value into etcd key /vitastor/config/global.

docs/config/layout-osd.ru.md

@@ -122,14 +122,13 @@ SSD-диске, иначе производительность пострада
 - Тип: булево (да/нет)
 - Значение по умолчанию: false
 
-Не отправлять fsync-и устройству данных, т.е. не заставлять его сбрасывать кэш.
+Не отправлять fsync-и устройству данных, т.е. не сбрасывать его кэш.
 Безопасно, ТОЛЬКО если ваше устройство данных имеет кэш со сквозной
-записью (write-through) или если кэш с отложенной записью (write-back) отключён.
-Если вы отключаете кэш вручную через `hdparm` или запись в `/sys/.../scsi_disk/cache_type`,
-то удостоверьтесь, что вы делаете это каждый раз перед запуском Vitastor OSD
-(vitastor-disk делает это автоматически). Смотрите также опцию
-[immediate_commit](layout-cluster.ru.md#immediate_commit) для информации о том,
-как извлечь выгоду из отключённого кэша.
+записью (write-through). Если вы отключаете кэш через `hdparm` или
+`scsi_disk/cache_type`, то удостоверьтесь, что команда отключения кэша
+выполняется перед каждым запуском Vitastor OSD, например, в systemd unit-е.
+Смотрите также опцию `immediate_commit` для инструкций по отключению кэша
+и о том, как из этого извлечь выгоду.
 
 ## disable_meta_fsync
 
@@ -180,8 +179,9 @@ SSD и HDD диски используют 4 КБ физические сект
 
 Поэтому, на самом деле, может быть выгодно найти SSD, хорошо работающие с
 меньшими, 512-байтными, блоками и использовать 512-байтные disk_alignment,
-journal_block_size и meta_block_size. Однако на данный момент такие SSD
-не известны...
+journal_block_size и meta_block_size. Однако единственные SSD, которые
+теоретически могут попасть в эту категорию - это Intel Optane (но и это
+пока не проверялось автором).
 
 Клиентам не обязательно знать про disk_alignment, так что помещать значение
 этого параметра в etcd в /vitastor/config/global не нужно.

docs/config/src/layout-osd.yml

@@ -110,22 +110,20 @@
   type: bool
   default: false
   info: |
-    Do not issue fsyncs to the data device, i.e. do not force it to flush cache.
-    Safe ONLY if your data device has write-through cache or if write-back
-    cache is disabled. If you disable drive cache manually with `hdparm` or
-    writing to `/sys/.../scsi_disk/cache_type` then make sure that you do it
-    every time before starting Vitastor OSD (vitastor-disk does it automatically).
-    See also [immediate_commit](layout-cluster.en.md#immediate_commit)
-    for information about how to benefit from disabled cache.
+    Do not issue fsyncs to the data device, i.e. do not flush its cache.
+    Safe ONLY if your data device has write-through cache. If you disable
+    the cache yourself using `hdparm` or `scsi_disk/cache_type` then make sure
+    that the cache disable command is run every time before starting Vitastor
+    OSD, for example, in the systemd unit. See also `immediate_commit` option
+    for the instructions to disable cache and how to benefit from it.
   info_ru: |
-    Не отправлять fsync-и устройству данных, т.е. не заставлять его сбрасывать кэш.
+    Не отправлять fsync-и устройству данных, т.е. не сбрасывать его кэш.
     Безопасно, ТОЛЬКО если ваше устройство данных имеет кэш со сквозной
-    записью (write-through) или если кэш с отложенной записью (write-back) отключён.
-    Если вы отключаете кэш вручную через `hdparm` или запись в `/sys/.../scsi_disk/cache_type`,
-    то удостоверьтесь, что вы делаете это каждый раз перед запуском Vitastor OSD
-    (vitastor-disk делает это автоматически). Смотрите также опцию
-    [immediate_commit](layout-cluster.ru.md#immediate_commit) для информации о том,
-    как извлечь выгоду из отключённого кэша.
+    записью (write-through). Если вы отключаете кэш через `hdparm` или
+    `scsi_disk/cache_type`, то удостоверьтесь, что команда отключения кэша
+    выполняется перед каждым запуском Vitastor OSD, например, в systemd unit-е.
+    Смотрите также опцию `immediate_commit` для инструкций по отключению кэша
+    и о том, как из этого извлечь выгоду.
 - name: disable_meta_fsync
   type: bool
   default: false
@@ -181,7 +179,8 @@
 
     Because of this it can actually be beneficial to use SSDs which work well
     with 512 byte sectors and use 512 byte disk_alignment, journal_block_size
-    and meta_block_size. But at the moment, no such SSDs are known...
+    and meta_block_size. But the only SSD that may fit into this category is
+    Intel Optane (probably, not tested yet).
 
     Clients don't need to be aware of disk_alignment, so it's not required to
     put a modified value into etcd key /vitastor/config/global.
@@ -199,8 +198,9 @@
 
     Поэтому, на самом деле, может быть выгодно найти SSD, хорошо работающие с
     меньшими, 512-байтными, блоками и использовать 512-байтные disk_alignment,
-    journal_block_size и meta_block_size. Однако на данный момент такие SSD
-    не известны...
+    journal_block_size и meta_block_size. Однако единственные SSD, которые
+    теоретически могут попасть в эту категорию - это Intel Optane (но и это
+    пока не проверялось автором).
 
     Клиентам не обязательно знать про disk_alignment, так что помещать значение
     этого параметра в etcd в /vitastor/config/global не нужно.

mon/mon.js

@@ -567,7 +567,6 @@ class Mon
 
     async apply_pool_pgs(results, up_osds, osd_tree, tree_hash)
     {
-        const etcd_request = { compare: [], success: [] };
         for (const pool_id in (this.state.pg.config||{}).items||{})
         {
             // We should stop all PGs when deleting a pool or changing its PG count
@@ -580,24 +579,9 @@ class Mon
                     return false;
                 }
             }
-            if (!this.state.config.pools[pool_id])
-            {
-                // Delete PG history and stats of the deleted pool
-                etcd_request.success.push({ requestDeleteRange: {
-                    key: b64(this.config.etcd_prefix+'/pg/history/'+pool_id+'/'),
-                    range_end: b64(this.config.etcd_prefix+'/pg/history/'+pool_id+'0'),
-                } });
-                etcd_request.success.push({ requestDeleteRange: {
-                    key: b64(this.config.etcd_prefix+'/pg/stats/'+pool_id+'/'),
-                    range_end: b64(this.config.etcd_prefix+'/pg/stats/'+pool_id+'0'),
-                } });
-                etcd_request.success.push({ requestDeleteRange: {
-                    key: b64(this.config.etcd_prefix+'/pgstats/'+pool_id+'/'),
-                    range_end: b64(this.config.etcd_prefix+'/pgstats/'+pool_id+'0'),
-                } });
-            }
         }
         const new_pg_config = JSON.parse(JSON.stringify(this.state.pg.config));
+        const etcd_request = { compare: [], success: [] };
         for (const pool_id in (new_pg_config||{}).items||{})
         {
             if (!this.state.config.pools[pool_id])