@ Карта сайта News Автора!

Bog BOS: hardware:  SSD

Последнее изменение файла: 2023.09.25
Скопировано с www.bog.pp.ru: 2024.03.29

Bog BOS: hardware: SSD

SSD накопитель представляет собой NAND флэш память в корпусе форм фактора 2.5" или 1.8" с интерфейсом SATA. Позволяет использование в качестве "почти обычного" жёсткого диска. Для ускорения операций может использоваться оперативная память под кеш и параллельный доступ к нескольким микросхемам флэш.

Предварительно необходимо ознакомиться с материалами о флэш.

  • Архитектура SSD
  • Адаптация к архитектуре SSD
  • Intel SSD X25
  • Samsung SSD 840 PRO
  • Серия Samsung PM893/PM897
  • Intel DC S3500 и другие
  • SATA Express, U.2, U.3, M.2 (NGFF), NVM Express, OCuLink
  • Серия Intel DC P3700 и другие
  • Серия Intel DC P4800X (Optane, 3D XPoint)
  • KIOXIA CM6-V
  • Архитектура SSD

    Контроллер SSD обеспечивает равномерное число стираний физических блоков независимо от шаблона записи для чего поддерживается таблица преобразования логических адресов в физические. Таблица преобразования также хранится в страницах флэша. Если есть свободные физические блоки, то контроллер записывает в них, а предыдущие физические блоки освобождаются. Скоростные SSD резервируют много места (от 7% до 25%) для гарантии наличия свободных физических блоков. Если свободных физических блоков нет (например, устройство тестировалось с помощью badblocks ;), то контроллеру приходится считывать старое содержимое блока в буфер, изменять содержимое буфера, стирать блок и записывать буфер обратно (write amplification). На неудачных SSD коэффициент "умножения записи" может достигать 20-40. Если запись приходится на границу двух блоков, количество операций удваивается. Для ускорения записи используется инвалидация прежнего содержимо страницы и алгоритмы сборки мусора (ищутся блоки, содержащие мало полезных данных, остатки полезных данных переписываются в свежий блок, а этот блок стирается, производится при возможности в фоновом режиме). Это также позволяет обеспечить равномерное использование блоков (количество стираний). Чтобы не задерживать контроллер при объёмной записи, "запачканные" блоки не стираются сразу, а только помечаются как неиспользуемые. Реальная очистка и "возвращение в строй" осуществляются при сборке мусора (выбираются блоки, содержащие наибольшее число неиспользуемых страниц, данные с них сливаются вместе, а блоки стираются и добавляются в список свободных). Эффект падения производительности при длительной нагрузке на запись. Со временем фрагментация усиливается и скорость случайной записи на SSD падает (X25-E 64GB - 25%, X25-M G1 160GB - 35%, X25-M G2 160GB - 0%, OCZ Summit 256GB - 70%, предыдущее поколение - в разы). Существуют контроллеры, размер логической страницы которых равен размеру блока стирания, а не записи - требуется меньшая производительность процессора контроллера и меньший размер таблиц, обеспечивается большая скорость последовательного чтения и записи, но получается очень маленькая скорость произвольной посекторной записи (80 KБ/сек!), подходят для цифровых фотоаппаратов.

    Контроллер имитирует поведение обычного жёсткого диска (Flash Translation Layer G2, FTL, Flash Abstraction Layer), т.е. блочного устройства с независимыми секторами размером 512 байт, обеспечивая интерфейс ATA (SATA). Однако поведение SSD с их блоками записи в 4КБ и блоками стирания в 512КБ плохо согласуется с привычными алгоритмами работы с дисковыми устройствами. Например, "неправильное" выравнивание раздела замедляет скорость записи в 3 раза.

    Команда ATA8 TRIM (SCSI ACS-2 PUNCH, SCSI DISCARD) позволяет ОС сообщить устройству о более неиспользуемых блоках данных, что позволяет контроллеру SSD значительно ускорить запись и перезапись данных, а также сборку мусора и избежать замедления записи при заполнении устройства. В SATA 3.0 и ранее команда TRIM не может быть поставлена в очередь, при выдаче команды контроллер диска останавливает приём команд, выполняет все команды из очереди, затем команду TRIM, возобновляет приём команд - не выдавайте TRIM часто! Исправлено в SATA 3.1. Аналогичные команды SCSI UNMAP (умеет вставать в очередь) и CF ERASE. Не помогает при изменении файла. Как быть с STP (SAS туннель) и RAID контроллерами? LSI MEGARAID не поддерживает. Поддержка появилась в виде заплаток для блочного уровня в ядре 2.6.28 (discard requests), идея оказалась неудачной (точнее говоря, команда TRIM в конечной версии стандарта не может быть поставлена в очередь) и всё переделывается, libata для 2.6.30 (нет?), EXT4 (2.6.33, "mount -o discard"), btrfs (2.6.33, "mount -o ssd,discard"). Версия hdparm 9.17 (июль 2009) имеет экспериментальную поддержку "ручного запуска" команды TRIM ("hdparm --please-destroy-my-drive --trim-sector-ranges адрес:1") и скрипт wiper.sh (ищет свободные блоки в файловой системе ext2/3/4 и посылает информацию о них в устройство командами TRIM), а также сообщается о наличии поддержки TRIM в устройстве

    hdparm -I /dev/sda | grep TRIM
               *    Data Set Management TRIM supported (limit 4 blocks)
               *    Deterministic read ZEROs after TRIM 
    

    Узнать о поддержке discard (TRIM, PUNCH, UNMAP) блочными устройствами можно с помощью "lsblk -D".

    Утилита fstrim (указывается активная точка монтирования) ищет неиспользуемые блоки и посылает устройству (через весь стек блочных устройств) сообщение об этом. Опции (размеры в KiB, MiB, GiB, TiB, PiB, KB, MB, GB, PB:

    При создании файловых систем (mkfs.ext4 -E discard), swap (discard), логических томов (issue_discards в /etc/lvm/lvm.conf), dm-crypt (discard в /etc/crypttab), mdraid (CentOS 6, ядро 3.7) также обеспечивается возможность TRIM.

    Использованный ресурс записи: "smartctl -l ssd /dev/sdX".

    Адаптация к архитектуре SSD

    Выравнивание начала каждого раздела на границу блока стирания: либо изобразить устройство с 56 секторами на дорожку и 224 головками("fdisk -H 224 -S 56" для 128KB блоков стирания), либо перейти к адресации по секторам (fdisk -u, но количество дорожек и головок всё равно изменить в режиме эксперта), либо отказаться от деления устройства на разделы. Чтобы первый раздел тоже был выровнен необходимо перейти в режим "эксперта". Для выравнивания необходимо точно знать размеры страницы записи и блока стирания.

    Выравнивание содержимого LVM

    pvcreate --metadatasize 250k /dev/раздел # выравнивание на границу 256KB
    pvs /dev/раздел -o+pe_start # проверка
    

    Выравнивание файловой системы (размер блока файловой системы - 4KB, размер блока стирания - 256KB)

    mke2fs -t ext4 -E stripe-width=64 /dev/имя-логического-тома
    

    Журнал автоматически выравнивается на границу 128KB, начиная с e2fsprogs 1.41.4.

    Нужен ли журнал или его можно отключить? Например, отключение журнала уменьшает запись на 12% при сборке ядра (ext4).

    Можно ли использовать noatime (chattr +A)? Например, noatime уменьшает запись на 12% при сборке ядра с использованием журнала и на 2% без использования журнала. relatime занимает промежуточное положение.

    Отключить планировщик ввода/вывода (elevator=noop)?

    В случае перманентной деградации устройство можно привести в чувство (сбросить загаженную таблицу отображения адресов) командой "ATA SECURITY ERASE" (только для "обычного" SATA контроллера!):

    hdparm -I /dev/имя-устройства # убедиться, что устройство "Security: not frozen"
    # если устройство "frozen", то попробовать передёрнуть кабель данных или кабель питания и данных
    hdparm --user-master u --security-set-pass временный-пароль /dev/имя-устройства # установить пароль
    # без очистки устройство будет заблокировано при следующем включении!
    hdparm -I /dev/имя-устройства # убедиться, что пароль задействован
    hdparm --user-master u --security-erase[-enhanced] временный-пароль /dev/имя-устройства # очистить устройство
    hdparm -I /dev/имя-устройства # убедиться, что пароль удалён
    

    Более простой (и менее эффективный) способ очистки для устройств с очисткой мусора - записать все блоки последовательно.

    Желательно оставлять 20% свободного места (т.е. таких страниц, в которые никогда не было записи после очистки) для облегчения работы алгоритма сборки мусора (Intel X25-E имеет 25% резервных блоков).

    SSD может писать во флеш и при чтении, например Kingstom SA400 (вариант Phison)

    173 MaxAvgErase_Ct          ------   100   100   000    -    77 (Average 38)
    233 Flash_Writes_GiB        -O--CK   100   100   000    -    9649
    241 Lifetime_Writes_GiB     -O--CK   100   100   000    -    985
    242 Lifetime_Reads_GiB      -O--CK   100   100   000    -    889
    244 Average_Erase_Count     ------   100   100   000    -    38
    245 Max_Erase_Count         ------   100   100   000    -    77
    246 Total_Erase_Count       ------   100   100   000    -    599040
    246 Total_Erase_Count       ------   100   100   000    -    599040
    
    0x01  0x018  6      2067766243  ---  Logical Sectors Written
    0x01  0x028  6      1864439361  ---  Logical Sectors Read
    
    после badblocks -sv
    
    173 MaxAvgErase_Ct          ------   100   100   000    -    86 (Average 39)
    233 Flash_Writes_GiB        -O--CK   100   100   000    -    9983
    241 Lifetime_Writes_GiB     -O--CK   100   100   000    -    985
    242 Lifetime_Reads_GiB      -O--CK   100   100   000    -    2655
    244 Average_Erase_Count     ------   100   100   000    -    39
    245 Max_Erase_Count         ------   100   100   000    -    86
    246 Total_Erase_Count       ------   100   100   000    -    620000
    246 Total_Erase_Count       ------   100   100   000    -    620000
    
    0x01  0x018  6      2067766243  ---  Logical Sectors Written
    0x01  0x028  6      5569274469  ---  Logical Sectors Read
    

    При этом устройство делает паузы при чтении на несколько секунд. Несильно загаженное устройство лечится:

    s=0; while [ $s -lt 937703088 ] ; do echo $s:8; s=$[$s+8]; done | hdparm  --trim-sector-ranges-stdin --please-destroy-my-drive /dev/sdb
    badblocks -b 4096 -c 1024 -t 0  -svw /dev/sdb 
    

    Intel SSD X25

    Intel X25-E, SSD, 2.5", 5V, SATA-II (SATA 2.6 с NCQ и SMART, ATA/ATAPI-7), 50 нм, SLC - SSDSA2SH064G1GC. Объём (в десятичных гигабайтах, немножко занимается под обслуживание) - 32 или 64 GB. Известен также как Kingston SNE125-S2/64GB. Обещана возможность записать 1 или 2 ПБ. На устройстве резервируется 25% блоков.

    bonnie++ 1.03       ------Sequential Output------ --Sequential Input- --Random-
                        -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
    Machine        Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP  /sec %CP
    HPDL365G5     59500M           125907  13  47616   6           126507  10  4571  10 # контроллер P400i умеет только SATA-1
    HPDL365G5     59500M            63221   6  42727   5           125256  10  5283  12 # отключено кеширование в контроллере
    HPDL365G5     59500M           131417  13  55793   7           127701   9  5190  12 # включено кеширование SSD
    HPDL365G5     59500M           133391  13  51901   6           127396   9  4057   9 # включено кеширование SSD и контроллера
    Intel SR2625  59500M           304880  29  89721   7           288803  15 +++++ +++ # 48GB памяти
    Intel SR2625 100000M           574696  75 208508  27           534533  29 +++++ +++ # RAID-0 из 4 устройств, 48GB памяти
    
    numademo 50g memset # при наличии 48GB памяти, swap на Intel X25-E
    memory with no policy memset              Avg 75.83 MB/s
    numademo 34g memset # при наличии 32GB памяти, swap на RAID-1 из SAS 10000 rpm
    memory with no policy memset              Avg 4.09 MB/s
    

    Intel X25-M (второе поколение, G2), SSD, 2.5", 5V, SATA-II (SATA 2.6 с NCQ и SMART, ATA/ATAPI-7), MLC, 34 нм, SSDSA2MH080G2xx (серебристые). Объём (в десятичных гигабайтах, немножко занимается под обслуживание) - 80GB, 160GB (10 каналов, 32MB SRAM) и 320GB (всё ещё ожидается). Кеш данных - SRAM 256KB. Первая прошивка оказалась с дефектом (блокировка при попытке защиты паролем). Вторая версия прошивки (HA02, с реализацией команды TRIM) - тоже. Известен также как Kingston SNM125-S2B/80GB. Обещана возможность записывать 20Gb в день в течении 5 лет (в реальности, зависит от свободного места: при полностью заполненном диске, можно суммарно записать 14,5 ТБ (29 TБ) данных для 80 ГБ (160 ГБ) модели; при наличии 10% свободного места на диске, можно суммарно записать 34 ТБ (68 TБ), а при 20% уже можно суммарно записать 52 ТБ (104 TБ) данных). На устройстве аппаратно резервируется 6.9% блоков. После длительного периода (1 час) записи на максимальной нагрузке скорость падает до 10MB в секунду.

    bonnie++ 1.03       ------Sequential Output------ --Sequential Input- --Random-
                        -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
    Machine        Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP  /sec %CP
    HPDL365G5     74500M            58453  12  43944   6           135129   9  4476   9 # включено кеширование SSD и контроллера
    Intel SR2625  74500M            67055   8  55261   6           287102  15 +++++ +++
    Intel SR2625 100000M           309171  39 174966  15           453858  16 +++++ +++ # RAID-0 из 6 устройств
    Intel SR2625 100000M           349611  50 196895  26           654527  44 15193  40
      pvcreate -M2 --dataalignment 1024 /dev/sd{abcd}
      lvcreate --extents 100%FREE --stripes 4 --name globaltemp --stripesize 1024
      mkfs.ext4 -O ^has_journal -v -m 0 -b 4096 -E stride=256,stripe-width=1024
      mount -o nodiratime,data=writeback,nobh,nobarrier,stripe=1024,delalloc,commit=60,\
               max_batch_time=30000,min_batch_time=1000
    Intel SR2625 100000M            56432  27  40092   6            95776   8  6252  16 # по NFS
    

    Обновление прошивки 2.6 от 30 ноября 2009 (2CV102HD для M и 045C8850 для E, в виде загрузочного ISO) действует только для "обычных" SATA контроллеров в режиме AHCI или Legacy (предпочтительно).

    Intel утверждает, что коэффициент "умножения записи" на типичной нагрузке - не более 1.1 (для SSD предыдущего поколения - 10), а разброс числа стираний между блоками не превышает 10% и лишь 4% блоков имеют большее число стираний (для SSD предыдущего поколения - 5). Intel SSD Toolbox 1.2.0 для Microsoft Windows XP/Vista/7 включает Optimizer (выдаёт TRIM для блоков удалённых файлов), средства доступа к SMART:

    Samsung SSD 840 PRO

    Samsung SSD 840 PRO 512GB (MZ-7PD512BW, 64x64Gb), обзор, SATA 6Gbps, формат 2.5" (SFF), толщина 7мм, прошивка DXM05B0Q (в DXM02B0Q была ошибка безопасного стирания - устройство умирало совсем), MLC 21нм, 8 каналов Toggle DDR 2.0 (400 Mbps), потребление - от 0.3 Вт до 3.5 Вт от 5 В, поддержка TRIM (использовать обязательно, иначе скорость падает до 30 МБ/сек), буфер 512 МБ LPDDR2-1066 (защиты от потери питания нет), запас всего 7% (имеется ПО для настройки). Около 10000 IOPS в однопоточном чтении (75000 IOPS при глубине 32), 30000 IOPS в однопоточной записи (90000 IOPS при глубине 32). В эксперименте выдержал запись 600 TB. Тестирование под серверной нагрузкой (скорость случайной записи упала до 8000 IOPS через 6 часов).

    Объяснение показателей SMART:

    Обнаружились проблемы при подключении к Intel C600 SCU (SAS1) - под тяжёлой нагрузкой (моделируется "badblocks -b 4096 -c 1024", несколько дней) у диска сносит крышу (начинает рапортовать о своём объёме в 600 PB и т.п.), приходится перезагружаться (SSD Intel DC S3500 проходит без проблем). Подключение через LSI MegaRAID 9266-8i выявило отсутствие TRIM у оного и невозможность работы без TRIM.

    Серия Samsung PM893/PM897

    Серия Samsung PM893 поставляется в формате SFF (2.5") с интерфейсом SATA-3.3 6Gbps, толщина 7мм, ресурс записи - 1.3 DWPD, Samsung V6 (128 Layer) TLC V-NAND, защита от потери данных при отключении питания с помощью конденсатора (PLP), потребление - до 3.2 Вт, имеются версии на 240GB, 480GB, 960GB, 1.92TB, 3.84TB и 7.68TB, обещанные характеристики (методика неизвестна): последовательное чтение/запись - до 530/560 MB/s, случайное чтение/запись - до 98k/31k IOPS.

    Серия Samsung PM897 поставляется в формате SFF (2.5") с интерфейсом SATA-3.3 6Gbps, толщина 7мм, прошивка JXTE004Q, ресурс записи - 3 DWPD, Samsung V6 (128 Layer) TLC V-NAND, защита от потери данных при отключении питания с помощью конденсатора (PLP), потребление - до 3.4 Вт, имеются версии на 480GB, 960GB (MZ7L3960HBLT), 1.92TB (MZ7L31T9HBNA-00A07) и 3.84TB, обещанные характеристики (методика неизвестна): последовательное чтение/запись - до 470/550 MB/s, случайное чтение/запись - до 97k/32k IOPS.

    Samsung стесняется выпуска этих устройств (на сайте только поиском можно найти двустраничный brief) и обзоров не обнаружено. (кстати, на сайте Samsung поиском находится двустраничный brief).

    Объяснение показателей SMART:

    Intel DC S3500 и другие

    Intel DC S3500 800 GB (SSDSC2BB800G401), типоразмер SFF 2,5", толщина 7.5 мм, SATA-3, MLC, ресурс записи не менее 140 TB по стандарту JESD218 (изменено на 450 ТБ? 0.3 записи всего объёма в день), поддерживает команду TRIM, защита от потери данных при отключении питания с помощью конденсатора, с самотестированием и мониторингом SMART, возможность питания только от шины 12 В, устойчивость производительности - 90%, полная задержка записи - типичная 65 мкс, не более 2 мс для 99.9% при QD=1, не более 10мс для 99.9% при QD=32, 5 Вт, гарантия 5 лет. Имеются версии на 80, 120, 160, 240, 300, 480, 600 и 800 GB (впоследствии расширены моделями на 1200GB и 1600GB с другим контроллером), а также в формате 1.8" глубиной 5 мм (маленькие модели - медленные). При разработке Intel сделала упор на обеспечение стабильности производительности при непрерывной большой нагрузке. Содержит 8-канальный контроллер PC29AS21CA0 и 1ГБ DDR3-1600 SDRAM (хранит линейную таблицу трансляции адресов), ECC?. Модель на 240ГБ содержит 52ГБ резерва, 480ГБ - 48ГБ резерва. Без TRIM работает плохо. Стабильность производительности позволяет собирать их в RAID.

    Независимое тестирование по методике SNIA Solid State Storage Performance Test Specification (SSS PTS) и JESD218A (JESD219A): 75000 IOPS при чтении блоками 4К очередь 16, 11000 IOPS при записи блоками 4К очередь 2 (резервирование места не помогает, средняя задержка - 2.8 мс при очереди 32).

    Был взят на замену несправившемуся Samsung SSD 840 PRO (временные файлы рассчётной фермы). При увеличении (изменении характера?) нагрузки появились проблемы с NFS. При этом индикатор истираемости предсказывает смерть SSD менее чем за год (гарантируется 450ТБ записи). Не надо загружать очередь выше 32 - это всё же SATA!

    Объяснение показателей SMART:

    Intel DC S3510 - замена контроллера на всей линейке (15200 IOPS при записи блоками 4К), переход на 16nm 128Gbit MLC NAND.

    Intel DC S3520 (от 150ГБ до 1600ГБ) - переход на 3D MLC 16nm (?), чуть меньше линейная скорость, 17000 IOPS при записи блоками 4К. Ресурс записи - 1 запись всего объёма в день, полная задержка записи - типичная 42 мкс.

    Серия Intel DC S3700 (от 100 до 800 ГБ, например, SSDSC2BA800G301) использует флеш MLC-HET (High Endurance Technology) с большим размером ячеек и более длительным циклом стирания, 200ГБ резерва для модели 800ГБ, что позволило увеличить лимит истирания до 14.6 ПБ и скорость записи до 35000 IOPS при записи блоками 4К очередь 2, средняя задержка - 1 мс при очереди 32.

    Серия Intel DC S3610 (от 200 до 1600 ГБ, например, SSDSC2BX800G401) использует флеш MLC-HET (High Endurance Technology) обещает 84000 IOPS при чтении блоками 4К и 27000 IOPS при записи блоками 4К очередь 32, 3 перезаписи в день (DWPD) - 10.7 ПБ (JESD218), типоразмер SFF 2,5", толщина 7.5 мм, SATA-3, MLC, UBER - 1 сектор на 10^17 бит, поддерживает команду TRIM, защита от потери данных при отключении питания с помощью конденсатора, с самотестированием и мониторингом SMART, возможность питания только от шины 5В или 5В и 12В, устойчивость производительности - 90%, полная задержка записи - типичная 65 мкс, не более 0.5 мс для 99.9% при QD=1, не более 10мс для 99.9% при QD=32, время хранения данных без питания - 3 месяца при 40°C 12 Вт, гарантия 5 лет, температурный интервал: 0 - 70°C.

    Серия Intel DC S3710 (от 200 до 1200 ГБ, например, SSDSC2BA800G401) использует флеш MLC-HET (High Endurance Technology) обещает 85000 IOPS при чтении блоками 4К и 45000 IOPS при записи блоками 4К очередь 32, 10 перезаписей в день (DWPD) - 24 ПТ (JESD218, JESD219), типоразмер SFF 2,5", толщина 7.5 мм, SATA-3, MLC, UBER - 1 сектор на 10^17 бит, поддерживает команду TRIM, защита от потери данных при отключении питания с помощью конденсатора, с самотестированием и мониторингом SMART, возможность питания только от шины 5В или 5В и 12В, устойчивость производительности - 90%, полная задержка записи - типичная 65 мкс, не более 0.2 мс для 99.9% при QD=1, не более 5мс для 99.9% при QD=32, время хранения данных без питания - 3 месяца при 40°C 12 Вт, гарантия 5 лет, температурный интервал: 0 - 70°C.

    Серия Intel DC S3100: TLC, ресурс - 580 TBW (для модули в 1 ТБ), 3900 IOPS при записи блоками 4К очередь 32, скорость линейной записи - 114 МБ/сек (явно прибедняются или нет?!).

    Серия Intel DC S4500: 3D TLC второго поколения, 30000 IOPS при записи блоками 4К (21000 для модели 480ГБ), SFF. От 240 ГБ до 7680 ГБ (вес и прочее модели 7680 ГБ подлежит определению). Задержка произвольной записи - 52 мкс (стабильность 90% для модели 480ГБ, прочих от 72% до 90%). Защита от отключения питания есть. Последовательная запись - 330 МБ/сек для модели 480 ГБ. Ресурс записи - 1 запись всего объёма в день по JEDEC при 5-летнем сроке (900 TB для модели 480ГБ). Качество обслуживания записи 99.9% при глубине очереди 32 - 7.46 мс для модели 480ГБ, при глубине 1 - 0.36 мс.

    Серия Intel D3-S4510, 3D TLC, SFF или M.2. 36000 IOPS при записи блоками 4К для модели 960ГБ. От 240 ГБ до 3840 ГБ (например, SSDSC2KB960G801). Последовательная запись - 510 МБ/сек для модели 480 ГБ и 960 ГБ. Задержка произвольной записи - 37 мкс. Защита от отключения питания есть. Ресурс записи - 2 записи всего объёма в день по JEDEC при 5-летнем сроке (3.4PB ТБ для модели 960ГБ).

    Серия Intel DC S4600: 3D TLC второго поколения, 60000 IOPS при записи блоками 4К для модели 480 ГБ (65000 для модели 960ГБ), SFF. От 240 ГБ до 1920 ГБ (например, SSDSC2KG480G701). Задержка произвольной записи - 37 мкс (стабильность 92% для модели 480ГБ, прочих от 82% до 92%). Защита от отключения питания есть. Последовательная запись - 480 МБ/сек для модели 480 ГБ (490 МБ/сек для модели 960 ГБ). Ресурс записи - 3 записи всего объёма в день по JEDEC при 5-летнем сроке (2950 ТБ для модели 480ГБ). Качество обслуживания записи 99.9% при глубине очереди 32 - 1.17 мс для модели 480ГБ, при глубине 1 - 0.2 мс.

    Серия Intel D3-S4610: 3D TLC 64 слоя, SFF. 44500 IOPS при записи блоками 4К для модели 480 ГБ (51000 для модели 960ГБ), при этом тесты показывают увеличение скорости записи относительно S4600 (видимо в пределах ёмкости кеширования, плохой тест). От 240 ГБ до 3840 ГБ (например, SSDSC2KG960G801). Задержка произвольной записи - 37 мкс. Защита от отключения питания есть. Потребление уменьшено относительно S4600. Последовательная запись - 510 МБ/сек для модели 480 ГБ и 960 ГБ. Ресурс записи - 3 записи всего объёма в день по JEDEC при 5-летнем сроке (2950 ТБ для модели 480ГБ).

    Серия Intel D3-S4620:

    Обзоры

    Прощай Intel! Здравствуй Solidigm (подразделение Intel куплено SK Hynix)!

    SATA Express, U.2, U.3, M.2 (NGFF), NVM Express, OCuLink

    Mini-PCI - форм-фактор для подключения маленьких плат с интерфейсом PCI.

    Mini-PCIe - форм-фактор для подключения маленьких плат с интерфейсом PCI Express и USB 2.0. Было выпущено небольшое количество моделей SSD (AHCI или нестандартный протокол, не NVMe!).

    mSATA - форм-фактор для подключения маленьких плат с интерфейсом SATA 3.0 и питанием. Разъём физически совместим с Mini-PCIe (но не работает).

    SATA Express (Serial ATA Express, SATAe, SATA 3.2, 2013) - физический интерфейс, совмещающий SATA и PCI Express. Разъём физически совместим с кабелем SATA 3.0 (2 порта), но дополнительно имеет 2 линии PCIe 2.0 (1ГБ/сек) или PCIe 3.0, питания нет, толщина 7 мм. Реализован в Intel Z97/H97 (2014) и C610.

    На логическом уровне SATAe совместим с AHCI (через SATA порт), AHCI (через PCIe, AHCI контроллер на устройстве) и NVM Express (через PCIe, NVMe контроллер на устройстве).

    M.2 (NGFF, Next Generation Form Factor) - миниатюрная реализация интерфейсов, предусмотренных SATA Express (2 или 4 линии PCI Express 3.0 и 1 порт SATA 3.0), дополненных USB 2.0 или 3.0, I2C, PCM, SDIO, DP, UART, Future Memory Interface и питание (?) для устройств хранения (и не только) в виде внутренней платы. Всего 67 контактов (ножевой разъём); до 60 циклов вставки; ширина устройства - 12, 16, 22 и 30 мм (25 мм для PCIe 5.0); длина - 16, 26, 30, 38, 42, 60, 80 и 110 мм. Типичные устройства имеют ширину 22 мм. Детали толщиной до 1.5 мм монтируются на 1 (3 варианта) или 2 стороны (5 вариантов). Изготовитель может безнаказанно опустить реализацию интерфейса в хосте или устройстве (задаётся прорезями-ключами, возможно несколькими: M-Key - 4 линии PCIe, B-Key - SATA, A-Key, E-Key; наличие ключа не гарантирует наличия поддержки интерфейса, например, M-Key может иметь только 2 линии PCIe). Для совместимости необходимо учитывать все параметры.

    Разъём SFF-8639 (aka U.2, 68 контактов, поддерживает горячую замену) обеспечивает в сумме до 6 высокоскоростных линий (1 SATA, 2 SAS, 4 PCIe 3.0 - 4ГБ/сек, линии синхронизации и сброса PCIe, SMBus) для сочетания с SFF-8482 (SAS 6Gbps), SFF-8630 (SAS Multilink, только механический стандарт, интерфейс не расписан, только расположение групп CS1, CS2, CS3 и нумерация контактов), SFF-8680 (SAS 12Gbps, интерфейс не расписан, только расположение групп CS1, CS2 и CS3). Сам SFF-8639 стандартизирует механическую часть и нумерацию контактов - E1-E25 для PCIe (а где официальное описание интерфейсов? EIA-966? Enterprise SSD Form Factor (SSD_Form_Factor_Version1_a.pdf)?). Имеются версии SFF-8637 (12 Gbps на линию) и SFF-8638 (24 Gbps на линию). Линия синхронизации обязательна (в SATAe опциональна). Форм-фактор 2.5" - 15x70x100.45 мм, до 25 Вт.

    Модификация SFF-TA-1001 для разъёма SFF-8639 (aka U.3, 68 контактов) - физически совпадает с U.2, но линии PCIe передвинуты для совмещения с линиями SAS. Варианты подключения: NVMe 1x4 и 2x2 и 1x2 и 1x1, SATA, SAS x1 и x2 и 4. Облегчает создание универсальных (SAS/SATA/NVMe) объединительных плат - единый кабель для сигналов SAS и NVMe (PCIe), совмещённые линии для SAS и PCIe в разъёме (кстати, импеданс PCIe - 85 Ом, а SAS - 100 Ом). Хост-адаптер определяет тип устройства с помощью UBM (Universal Backplane Management, SFF-TA-1005) через 3 ранее не использовавшиеся линии SFF-8639 (P10 PRSNT#, P4 IfDet#, E6 IfDet2#). Для опознания количества используемых портов SAS и PCIe (1, 2 или 4) используются 2 ранее не использовавшиеся линии SFF-8639 (S15, E25). UBM также позволяет идентифицировать слот устройства (например, для замены) и демонстрировать состояние устройства, управлять питанием, осуществлять сброс устройства, управлять тактовым сигналом (clock, внешний или встроенный в сигнал). Накопитель U.3 можно подключить к объединительной плате U.2, но накопитель U.2 нельзя подключить к объединительной плате U.3.

    OCuLink (SFF-8611, PCIe 3.0 x4, 42 контакта, SGPIO?) - разъём для прямого подключения кабелем 1 SSD. Имеются варианты прямого и углового соединения. Имеется вариант для x8 (бывает ли в природе?).

    Первоначально M.2 позволяли подключать SSD по протоколу AHCI через PCIe (современные SATA SSD не имеют реализации протокола AHCI).

    NVM Express (NVMe, Non-Volatile Memory Host Controller Interface Specification) - логический интерфейс доступа к SSD (1.0 в 2011, 1.1 в 2012). В отличие от AHCI c её 1 очередью в 32 команды NVMe может иметь до 64K очередей в 64К команд, вдвое меньшие задержки (не нужно 4 чтения регистров по 2000 циклов каждое), 2048 MSI-X прерываний (параллельная обработка), не нужна блокировка синхронизации для выдачи команды. Для достижения 1 миллиона IOPS требуется 10 ядер в режиме AHCI и 3.5 ядра Intel в режиме NVMe (3.3 GHz, RHEL 6). NVMe SSD реализуются в формате PCIe карт расширения или SFF дисков с разъёмом SFF-8639 (4 линии PCIe) или M.2 или SATA Express. Обновление и переключение прошивки без остановки работы (несколько слотов).

    NVMe 1.4: журнал событий (Persistent Event Log), многомаршрутный доступ к пространству имён (Asymmetric Namespace Access), использование памяти хоста под буфер (Host Memory Buffer).

    NVMe 2.0: стандарт разбит на разделы с базовой спецификацей NVMe, спецификацией наборов команд - NVM, ZNS (Zone Name Space) и KV (Key Value) - спецификации транспорта (PCIe, Fibre Channel, RDMA и TCP) и спецификацию интерфейса управления. Теперь НЖМД тоже могут иметь интерфейс NVMe.

    Драйвера имеются для MS Windows 7, RHEL 6.5, Linux ядра 3.3 (nvme, multiqueue в 3.13), Oracle Solaris 11.2, UEFI 2.3.1. Модуль nvme имеет параметры:

    Базовые понятия:

    Пакет nvme-cli (/usr/share/doc/nvme-cli-1.8.1, отдельная документация для man по каждой команде) содержит утилиту nvme ("nvme команда устройство параметры") с командами

    Сборка версии 0.9: make.

    Дополнения для LightNVM lnvm (LightNVM), memblaze, wdc, huawei, netapp, toshiba (KIOXIA на него не отзывается), micron, seagate и Intel (intel).

    Расширения Intel (1.8.1):

    Расширения wdc (nvme wdc id-ctrl /dev/nvme0n1):

    Интересные данные в log:

    Интересные данные в intel smart-log-add:

    Серия Intel DC P3700 и другие

    Серия Intel DC P3700 (17 полных записей в день (65ПБ) по JESD218/JESD219, 175K iops на запись 4KB при очереди 4x32 на весь объём), поставляется в форматах PCIe (AIC, add-in-card, HHHL, до +55°C) и SFF-8639 (до +30°C, горячая замена, 15 мм), имеют объём от 400 до 2000GB (резерв - 25%), достигают 450K iops на чтение, PCIe 3 x4, NVMe 1.0 (трансляция команд SCSI, включая UNMAP), процессор 400 МГц и 18 каналов и DDR3-1600 (1.25ГБ для модели 800ГБ, 2.5ГБ для модели 2000ГБ), типичная задержка 20 мкс, UBER - 1 сектор на 10^17 бит, питание по 3.3 и 12В, до 25Вт (можно программно задать ограничение в 10Вт и 20Вт, по умолчанию 20Вт?), устойчивость производительности - 90%, полная задержка записи - типичная 20 мкс, не более 0.09 мс для 99.9% при QD=1, не более 11мс для 99% при QD=128, защита от потери питания (конденсатор с самотестированием), гарантированная устойчивость скорости и задержек, время хранения данных без питания - 3 месяца при 40°C, встроенный датчик температуры (NVMe Health Log) и датчик температуры по SMBUS, поддержка T10 DIF (512+8 или 4096+8) и переменный размер сектора (512, 520, 528, 4096, 4104, 4160, 4224), индикаторы активности и здоровья, гарантия 5 лет. Обзоры:

    Серия Intel DC P3600 - SSDPEDME020T401 (3 полных записи в день (11ПБ) по JESD218/JESD219, 56K iops на запись 4KB при очереди 4x32 на весь объём, в 1.5 раза дешевле) поставляется в форматах PCIe (AIC, add-in-card, HHHL, до +55°C) и SFF-8639 (до +30°C, горячая замена, 15 мм), имеют объём от 400 до 2000GB (резерв - 12%), достигают 450K iops на чтение, PCIe 3 x4, NVMe 1.0 (трансляция команд SCSI, включая UNMAP), задержка 20 мкс, UBER - 1 сектор на 10^17 бит, питание по 3.3 и 12В, до 25Вт (можно программно задать ограничение в 10Вт и 20Вт, по умолчанию 25Вт "nvme id-ctrl /dev/nvme0n1 -H": "ps 0 : mp:25.00W operational"), устойчивость производительности - 90%, полная задержка записи - типичная 20 мкс, не более 0.09 мс для 99.9% при QD=1, не более 11мс для 99% при QD=128, защита от потери питания (конденсатор с самотестированием), гарантированная устойчивость скорости и задержек, время хранения данных без питания - 3 месяца при 40°C, встроенный датчик температуры (NVMe Health Log) и датчик температуры по SMBUS, поддержка T10 DIF (512+8 или 4096+8) и переменный размер сектора (512, 520, 528, 4096, 4104, 4160, 4224), индикаторы активности и здоровья, гарантия 5 лет.

    lspci
    83:00.0 Non-Volatile memory controller: Intel Corporation PCIe Data Center SSD (rev 01) (prog-if 02 [NVM Express])
            Subsystem: Intel Corporation DC P3600 SSD [Add-in Card]
            Capabilities: [40] Power Management version 3
            Capabilities: [50] MSI-X: Enable+ Count=32 Masked-
            Capabilities: [60] Express (v2) Endpoint, MSI 00
                    LnkCap: Port #0, Speed 8GT/s, Width x4, ASPM L0s L1, Exit Latency L0s <4us, L1 <4us
                    LnkSta: Speed 8GT/s, Width x4, TrErr- Train- SlotClk- DLActive- BWMgmt- ABWMgmt-
                    LnkCtl2: Target Link Speed: 8GT/s, EnterCompliance- SpeedDis-
            Capabilities: [150 v1] Virtual Channel
            Capabilities: [180 v1] Power Budgeting
    
            Kernel driver in use: nvme
    
    lsblk
    nvme0n1                    259:0    0   1.8T  0 disk 
    
    Файлы в /dev (разделы будут nvme0n1p1, n1 - это пространство имён 1)
    crw------- 1 root root 245, 0 Oct 26 12:54 /dev/nvme0
    brw-rw---- 1 root disk 259, 0 Oct 26 12:54 /dev/nvme0n1 
    
    badblocks -sv -b 4096 -c 1024 /dev/nvme0n1 1
    
    Device:         rrqm/s   wrqm/s     r/s     w/s    rMB/s    wMB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
    nvme0n1           0.00     0.00 21708.00    0.00  2713.50     0.00   256.00    16.40    0.76    0.76    0.00   0.04  94.90 
    
    отсутствует в /dev/disk
    
    имеется /sys/block/nvme0n1 (/sys/block/nvme0n1/queue/:
      hw_sector_size и logical_block_size равно 512
      max_hw_sectors_kb 128
      max_sectors_kb 128
      nr_requests 1023
      read_ahead_kb 128
      rq_affinity 1
      scheduler none
    
    blockdev --getra /dev/nvme0n1
    256
    

    После установки устройства в настройках BIOS (2013 год!) появились пункты

    Intel SSD Data Center Tools - утилита командной строки для NVMe и SATA (пакет isdct - /etc/isdct, /usr/bin/isdct, /usr/lib/isdct/ (64 бит!). Например: "isdct show -intelssd" (сообщает, что имеется обновление прошивки) или "isdct show -all -smart" или "isdct show -sensor". Можно обновить прошивку и порулить размером сектора, обработкой ошибок, интерфейсом, мощностью, кешированием, объёмом.

    Серия Intel DC P3500 (0.3 полных записи в день, резерв - 7%, 35K iops на запись 4KB) обещается вдвое дешевле P3700, линейная скорость - 2700/1800 МБ/сек, потребляемая мощность - 25 Вт.

    Серия Intel DC P3520: PCIe 3.0 x4 (AIC и SFF (15 мм) с U.2 (SFF-8639)), 450ГБ и 1200ГБ и 2000ГБ (полный объём 2304ГБ), на базе 3D MLC (32 слоя, первый эксперимент, 32GB на микросхему), 1 полная запись в день, вдвое дешевле P3600, 18-канальный контроллер, до 2.5GB ОП Micron DDR3-1866 (2ГБ с учётом затрат на ECC), 375K/26K iops на чтение/запись 4KB, линейная скорость - 1700/1350 МБ/сек, потребляемая мощность - 12 Вт, конденсаторы для защиты от пропадания питания с самотестированием, T10 DIF, UBER - 10^-17, обзор.

    Серия Intel DC P3320: PCIe 3.0 x4 (AIC и SFF с U.2 (SFF-8639)), 450ГБ и 1200ГБ и 2000ГБ, на базе 3D NAND (?TLC), 365K/22K iops на чтение/запись 4KB, 0.3 полных записи в день, линейная скорость - 1600/1400 МБ/сек, потребляемая мощность - ? Вт.

    Серия Intel SSD 750 (219 TB (70GB в день), пиковые 290K IOPS на запись 4KB, реальные 22K IOPS на запись 4KB при очереди 32), втрое дешевле DC P3700, поставляется в форматах PCIe (HHHL, до +55°C) и SFF-8639 (до +30°C, горячая замена, 15 мм), имеют объём 400 или 1200GB (резерв - 18.8%), достигают 440K iops на чтение, PCIe 3 x4, NVMe 1.0 (трансляция команд SCSI, включая UNMAP), процессор 400 МГц и 18 каналов и DDR3-1600, типичная задержка 20 мкс, UBER - 1 сектор на 10^16 бит, питание по 3.3 и 12В, до 25Вт (можно программно задать ограничение в 10Вт и 20Вт, по умолчанию 20Вт?), обещаний по устойчивости производительности и качеству обслуживания не даётся, обещается защита от потери питания, но конденсатор отсутствует, время хранения данных без питания - 3 месяца при 40°C, встроенный датчик температуры (NVMe Health Log), но датчик температуры по SMBUS недоступен, индикаторы активности и здоровья, гарантия 5 лет. Обзоры:

    Прощай Intel! Здравствуй Solidigm (подразделение Intel куплено SK Hynix)!

    Серия SSD Solidigm D7-P5810 использует 144-слойную память 3D NAND в режиме SLC обеспечивают 50 DWPD (73 PB всего), имеют объём 800 и 1600 ГБ, выпускаются в формате U.2 (15 мм), интерфейс PCIe 4.0 x4, до 865K/495K iops на чтение/запись 4KB, линейная скорость - до 6400/4000 МБ/сек, потребляемая мощность - 12 Вт, конденсаторы для защиты от пропадания питания с самотестированием, T10 DIF, UBER - 10^-17.

    Серия Intel DC P4800X (Optane, 3D XPoint)

    Серия Intel DC P4800X (обзор на anandtech) имеет контроллер на 7 каналов, поставляется в форм-факторе платы PCIe HHHL или U.2 SFF (2.5") толщиной 15mm, интерфейс PCIe 3.0 x4 NVMe, объёмы 375 GB (SSDPED1K375G[A01] и SSDPE21K375G[A01]) или 750 GB (SSDPED1K750GA01[A01] и SSDPE21K750GA01[A01]) или 1.5TB (SSDPED1K015T[A01] и SSDPE21K015T[A01]). Отсутствует память для кеширование и конденсаторы для сохранения её содержимого при пропадании питания. Обещается:

    lspci
    84:00.0 Non-Volatile memory controller: Intel Corporation Optane DC P4800X Series SSD (prog-if 02 [NVM Express])
            Subsystem: Intel Corporation DC P4800X Series [Add-in Card]
                    DevCap: MaxPayload 256 bytes, PhantFunc 0, Latency L0s <4us, L1 <4us
            Capabilities: [40] Power Management version 3
            Capabilities: [50] MSI-X: Enable+ Count=32 Masked-
            Capabilities: [60] Express (v2) Endpoint, MSI 00
                    LnkCap: Port #0, Speed 8GT/s, Width x4, ASPM L0s, Exit Latency L0s <4us, L1 unlimited
                    LnkSta: Speed 8GT/s, Width x4, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-
                    LnkCtl2: Target Link Speed: 8GT/s, EnterCompliance- SpeedDis-
            Capabilities: [150 v1] Virtual Channel
            Capabilities: [180 v1] Power Budgeting
    
            Kernel driver in use: nvme
            Kernel modules: nvme
    

    Серия Intel DC D4800X - в формфакторе U.2 SFF (2.5") толщиной 15mm, интерфейс PCIe 3.0 2x2 NVMe (2 порта x2), объёмы 375 GB или 750GB или 1.5TB.

    Серия Intel DC P4801X - в формфакторе M.2, интерфейс PCIe 3.0 x4 NVMe, объёмы 100GB или 200GB или 375 GB.

    Intel ликвидирует направление Optane и 3D XPoint, Micron вышла из проекта ранее.

    Серия KIOXIA CM6-V и другие

    Серия KIOXIA CM6-V расчитана на нагрузку 3 DWPD (методика не указана, гарантия 5 лет), поставляются в объёмах 12.8 TB (KCM61VUL12T8), 6.4 TB (KCM61VUL6T40), 3.2 TB (KCM61VUL3T20), 1.6TB (KCM61VUL1T60) и 800 GB (KCM61VUL800G). Изготавливаются на базе 96-уровнего BiCS 3D TLC и 18-канального контроллера, 8GB DRAM. Имеются варианты с шифрованием и безопасной очисткой (SIE, SED, SED FIPS). Поставляется в формате U.3 (SFF-TA-1001, SFF/2.5", 15 мм толщиной) под PCIe 4.0 (1x4 или 2x2) и NVME 1.4. Обещается работоспособность при отказе 2 микросхем флеша, защита от внезапного отключения питания (PLP, конденсатор с самотестированием) и сквозная защита данных (end-to-end). Возможен выбор из 6 режимов потребления (12 В) вплоть до 21 Вт (в реальности устройство предлагает до 27.5 Вт), в ожидании - от 5 Вт. Обещается производительность последовательных операций до 6900/4200 MB/s, случайных - до 1400/350 kIOPS (при QD=256/32), задержки 90/10 мкс при QD=1 (11/99 kIOPS). Из интересного о контроллере (nvme id-ctrl -H /dev/nvme8):

    Из интересного о свойствах пространств имён:

    Серия CD6-V рассчитан только на режим PCIe 1x4 и использует 16-канальный контроллер.

    Серии CM6-R и CD6-R расчитаны на нагрузку 1 DWPD.

    Серии PM6-V (3DWPD) и PM6-M (10DWPD) - вариант для SAS 24G. PM6-V (3DWPD) KPM61VUG6T40: 6.4TB, 595/290 KIOPS. PM6-M (10DWPD) KPM61MUG1T60: 1.6TB, 595/452 KIOPS.

    Серии HK6-V и HK6-M - вариант для SATA.

    Серия FL6 (XL-FLASH, SLC) расчитана на нагрузку 60 DWPD и меньшую задержку (29/8 мкс).

    Обзоры:

    Тестирование многопоточного восстановления файлов (bacula)

    Тестирование многопоточного восстановления файлов (bacula) на ext4

    Тестирование многопоточного копирования файлов из одной файловой системы на базе 8 SSD, подключённой через коммутатор PCIe 3.1 x8б в другую такую же:

    Копирование с файловой системы из 8 SSD без чередования в другую такую же (16 потоков) - 3600 MB/s.

    Копирование с файловой системы из 8 SSD в файловую систему из 1 SSD (16 потоков) - 3006-3019 MB/s (запись 20K IOPS).

    Копирование с файловой системы из 1 SSD в файловую систему из 8 SSD (16 потоков) - 3134-3265 MB/s (чтение 37K IOPS).

    Копирование с файловой системы из 1 SSD в файловую систему из 1 SSD внутри коммутатора (16 потоков) - 2992-3024 MB/s (чтение 36 Kiops, запись 19 Kiops).

    Копирование с файловой системы из 1 SSD в файловую систему из 1 SSD между коммутаторами (16 потоков) - 2993-3035 MB/s (чтение 36 Kiops, запись 19 Kiops).

    Копирование с файловой системы из 1 SSD в файловую систему из 1 SSD внутри коммутатора (16 потоков), одновременно с копированием с третьей файловой системы из 1 SSD в четвертую файловую систему из 1 SSD внутри того же коммутатора - 2x2400 MB/s (чтение 2 x 28 Kiops, запись 2 x 15 Kiops).

    Копирование с файловой системы из 1 SSD в файловую систему из 1 SSD внутри коммутатора (16 потоков), одновременно с копированием с третьей файловой системы из 1 SSD в четвертую файловую систему из 1 SSD внутри того же коммутатора, одновременно с копированием с пятой файловой системы из 1 SSD в шестую файловую систему из 1 SSD внутри того же коммутатора - 3x1600 MB/s (чтение 3 x 20 Kiops, запись 3 x 12 Kiops) при 0% idle.

    Одновременный badblock с 3 SSD внутри коммутатора достигает 3x2200 MB/s.

    Увеличил stripe с 64k до 1024k

    Тестирование многопоточного чтения файлов из файловой системы на базе 4 SSD, подключённых напрямую к ЦП, условия:

    потоковB/scgroups 16GBcgroups 64GBnocachedm_mq_nr_hw_queues=4max_sectors_kb=4096memoptimizernomerges=2kswapd_threads=2
    641077703398879093080248268012945112246690281077005974410724334269109785099821026026022610651385274
    481085060062279152963648208583725113444418371085976930510897233727110822710151033130067610729385861
    401103362064178517472888200518783114873555431088399306910926390888111628917021044522510210838147854
    361100822196777221254438156240120115988353741101394708311015036854112298714051044847524110881611347
    321111678185275535695238018901683116652491741114069546311190874435113396582691050769187511038987603
    28112902638287508151497?118536834291122488824711260592028115111490911070763972211148811924
    24114755462387391191198?116707909071147142350711373756854116029085781077671913011269356933
    20112248525607178042030?112097364661117201012011267784716113447594961063092322511016544235
    16108291295076633334811?1059244000610771327117108045019141053022071110213896087?
    1294204698055908127845?92299467239449732567954515366692770385179068465303?
    1086640423785454408132?84373392238639941434864085371385216054978131123007?
    874812891764857298519?72006833147545914885755061330274620122257205724084?
    661133664214081786139?58224177166142515118615399267260448975235950868514?
    553472414843669119140?5089228975?535364473852817716025189684569?
    44516367973????450847011645056549694453895409?
    33531078686?????34721615273487673205?
    22451575186?????24151654462433320964?
    1?????????

    Ограничение памяти с помощью cgroups делалось так (pagecache держится на уровне 16GB (17.5GB), но used растёт (44GB); 100% CPU при 64-32)

    cgcreate -g memory:backup
    echo 16G > /sys/fs/cgroup/memory/backup/memory.kmem.limit_in_bytes
    echo 16G > /sys/fs/cgroup/memory/backup/memory.limit_in_bytes
    
    echo номер-процесса-головного-bash > /sys/fs/cgroup/memory/backup/tasks 
    

    nocache добавляет POSIX_FADV_DONTNEED в close. pagecache остаётся в пределах 67ГБ (и 45 ГБ в used), каждый SSD под нагрузкой - 17244.10 r/s, 633.30 w/s, avgqu-sz 22.77, await 2.17 мс, загрузка ЦП падает - user 2%, system 44%, (вместо 50%) irq+softirq 2%, umount идёт вечность (8% от времени теста) - 173 секунды. Пропускная способность увеличивается при большом количестве потоков и уменьшается при малом. Сборка стандартная: unzip nocache-master.zip; cd nocache-master; make; make install (/usr/local/lib/nocache.so, /usr/local/bin/{nocache,cachede,cachestats}, /usr/local/share/man/man1/{nocache.1,cachestats.1,cachedel.1}). Количество дескрипторов NOCACHE_MAX_FDS=1Mi по умолчанию, если надо больше, то надо поменять и пересобрать Использование: nocache ключи-nocache программа ключи-программы. Ключи nocache:

    Увеличение /sys/module/dm_mod/parameters/dm_mq_nr_hw_queues с 1 до 4 не приносит пользы, глубина очереди уменьшается (11.75), уменьшается время ожидания (1.22).

    Почему-то /sys/block/nvme8n1/queue/max_hw_sectors_kb=4096, а max_sectors_kb=1280 (изменяемо) при mdts=32M, увеличение до 4096 не показало преимущества:

    cat /sys/block/dm-2/queue/max_sectors_kb
    1280
    cat /sys/block/nvme8n1/queue/max_sectors_kb
    1280
    echo 4096 > /sys/block/dm-2/queue/max_sectors_kb
    echo 4096 > /sys/block/nvme8n1/queue/max_sectors_kb
    echo 4096 > /sys/block/nvme9n1/queue/max_sectors_kb
    echo 4096 > /sys/block/nvme22n1/queue/max_sectors_kb
    echo 4096 > /sys/block/nvme23n1/queue/max_sectors_kb 
    

    memoptimizer запускается в фоне и периодически подстраивает /proc/sys/vm/watermark_scale_factor под текущую нагрузку и запускает дефрагментатор pagecache при необходимости и ограничивает память занимаемую неудачными dentry (статически при запуске, пишет 15 (1.5% от размера ОП) в /proc/sys/fs/negative-dentry-limit). Пропускная способность увеличивается при большом количестве потоков и уменьшается при малом. Оформлен как сервис systemd. /proc/sys/vm/watermark_scale_factor (в 1/10000 от (high watermark - low watermark); по умолчанию - 10) используется kswapd для определения количество освобождаемых страниц pagecache при каждом проходе. Также имеется /proc/sys/vm/watermark_boost_factor (в 1/10000 от high watermark; по умолчанию - 15000), который определяет количество освобождаемых страниц pagecache при каждом вызове дефрагментатора. Параметры (/etc/sysconfig/memoptimizer, /etc/default/memoptimizer):

    Отключение слияния не принесло пользы, делалось так (было 0):

    echo 2 > /sys/block/dm-2/queue/nomerges
    echo 2 > /sys/block/nvme8n1/queue/nomerges
    echo 2 > /sys/block/nvme9n1/queue/nomerges
    echo 2 > /sys/block/nvme22n1/queue/nomerges
    echo 2 > /sys/block/nvme23n1/queue/nomerges 
    

    Увеличение количества потоков kswapd на узел NUMA (2 в /proc/sys/vm/kswapd_threads) не принесло пользы. Вместе с memoptimizer тоже не принесло пользы. Очень слегка увеличивается нагрузка на ЦП.

    Отключил HT

    потоковB/s без HTHTHT + rq_affinity=2HT + zone_reclaim_modeHT + dm/ra=512HT + dm/ra=128HT + dm/ra=2048HT ra=256/1024HT ra=64/256
    64107887154991077703398810612307440107683703771122839690912180894616106447514611062259329211710119344
    48108566159721085060062210682300343108429124061134949524912386602130107195477971063237761811900361609
    40110345024561103362064110792470433110069913781160904556412345184162108768893231057819032612164263370
    36111476904951100822196710840791140110575682571176567809612049145356110334433101061530219212364262345
    32112375000681111678185210969242028111149969691195657607411806236260111189074621070519543512044341987
    28113081534681129026382811112418149112327398741202496196311481559867113509443771080715244111683701611
    24114028817831147554623811159791705113845760301182860152111144121529113508609641076508701411549542127
    201106533114711224852560110781627791105962178811460571574??1046713636211034394069
    161067703466310829129507?1062570349410609587646??980082718810076959565
    1294963513389420469805??9495482969??87178992258790727334
    1085748817388664042378??8551468891??79592485237957846651
    875353912157481289176??7304403109??6909730794?
    661599102906113366421??5892570539??5643694553?
    553806532965347241484??5155557620????
    445327357614516367973??4368172467????
    335196884393531078686???????
    224619331352451575186???????
    1?????????

    Без HT утилизация ЦП возрастает: 3.5% us, 69% sy, 2% прерывания. Пропускная способность не меняется. При полной загрузке ЦП другими задачами включение HT даёт увеличение пропускной способности на 17% (получено в другой серии тестов).

    Переход на опросы вместо прерываний (адаптивный, poll_queues требуется устанавливать при загрузке), однако каждое устройство NVME имеет 32 (по числу ядер с учётом HT) очереди, отдельное прерывание на каждую привязано к ядру и их немного (/proc/interrupts, 200 в секунду на ядро на устройство; 4800/сек на все устройства на ядро), так что стало хуже

    echo 4 > /sys/module/nvme/parameters/poll_queues # 0
    echo 1 > /sys/block/nvme8n1/queue/io_poll
    -bash: echo: write error: Invalid argument
    
    добавил nvme.poll_queues=32 в /etc/default/grub и "grub2-mkconfig -o /etc/grub2-efi.cfg"
    reboot
    
    echo 1 > /sys/block/nvme8n1/queue/io_poll
    echo 1 > /sys/block/nvme9n1/queue/io_poll
    echo 1 > /sys/block/nvme22n1/queue/io_poll
    echo 1 > /sys/block/nvme23n1/queue/io_poll
    echo 0 > /sys/block/nvme8n1/queue/io_poll_delay # было -1
    echo 0 > /sys/block/nvme9n1/queue/io_poll_delay
    echo 0 > /sys/block/nvme22n1/queue/io_poll_delay
    echo 0 > /sys/block/nvme23n1/queue/io_poll_delay
    

    Отключение сбора статистики (0 в /sys/block/nvme{8,9,22,23}n1/queue/iostats) ничего не даёт (слишком мало IOPS).

    Смена режима привязки потоков к ядрам ухудшает пропускную способность.

    cat /sys/block/dm-3/queue/rq_affinity
    0
    cat /sys/block/nvme{8,9,22,23}n1/queue/rq_affinity
    1
    1
    1
    1
    echo 2 > /sys/block/dm-3/queue/rq_affinity
    echo 2 > /sys/block/nvme8n1/queue/rq_affinity
    echo 2 > /sys/block/nvme9n1/queue/rq_affinity
    echo 2 > /sys/block/nvme22n1/queue/rq_affinity
    echo 2 > /sys/block/nvme23n1/queue/rq_affinity
    

    Увеличение локальности данных за счёт кеширования (1 в /proc/sys/vm/zone_reclaim_mode вместо 0) не приносит пользы.

    Уменьшение агрессивности предварительного чтения для LV с 8192 до 2048 не даёт улучшений нигде.

    Уменьшение агрессивности предварительного чтения для LV с 8192 до 512 (4-кратное от предварительного чтения устройств) приводит к увеличению IOPS до 25K на устройство (100K всего), уменьшению очереди и времени ожидания, график пропускной способности превращается почти в ровную линию (12 GB/s) при количестве потоков более 24, средняя пропускная способность увеличивается. При малом количестве потоков пропускная способность уменьшается.

    Уменьшение агрессивности предварительного чтения для LV с 8192 до 128 (равное ra устройства) приводит к увеличению IOPS до 45K на устройство, уменьшению очереди и времени ожидания. график пропускной способности ещё уплощается чуть выше прежнего при количестве потоков более 32, средняя пропускная способность увеличивается ещё при более 32 потоков. При количестве потоков менее 28 пропускная способность уменьшается.

    Отключение /sys/block/dm-3/bdi/read_ahead_kb (8192) для LV приводит к разбиению запросов на чтение по 4КиБ, уменьшению нагрузки ЦП (20% sy, 5% hi), увеличению IOPS до 220K на устройство и катастрофическому уменьшению пропускной способности.

    Увеличение предварительного чтения для устройств до 256 и установка 1024 (4-кратное) для LV ухудшает пропускную способность везде.

    Уменьшение предварительного чтения для устройств до 64 и 256 (4-кратное) для LV увеличивает IOPS до 32K. Очередь и время ожидания почти 0. Пропускная способность увеличивается при количестве потоков более 24, при меньшем количестве потоков пропускная способность уменьшается.

    Отключение предварительного чтения для устройств приводит к загрузке ЦП в 100% и значительному уменьшению пропускной способности.

    Увеличить MPS (MaxPayload, DevCap: MaxPayload 512 bytes, DevCtl: MaxPayload 256 bytes) с помощью pci=pcie_bus_perf не удалось. В настройках BIOS ничего подходящего не нашёл. По слухам, накладные расходы при пакетах 256 байт равны 6%. Это лучше чем 12% при стандартном размере пакете (128), но хуже чем могло бы быть (3.4% при родном размере пакета в 512 байт).

    Регулярный (в начале и раз в 10 минут) прогрев высокопараллельным find (findhot_all.sh, 0 в /proc/sys/vm/vfs_cache_pressure вместо 100, 70K IOPS) только мешает.

    Продолжаем, всё полезное вместе: HT + 512 в /sys/block/dm-5/bdi/read_ahead_kb + nocache + memoptimizer - ускорение при количестве потоков более 24 и замедление при количестве потоков менее 20.

    потоковHTвместекоммутатор на 4блок 512ext4ext4+inlineext4+inline+cacheext4+inline+bigalloc+fast_commitmdadm stripe
    64107770339881167674062964793160031056938235710542246914? 116545123591174450852910409373933
    4810850600622118916465546556375766109949769681088402196811663001147117396814701169553550510799799622
    4011033620641122927019726567242693110861913321099738952611714033641118929521441183861626810896867513
    3611008221967125004207616630310010111872544711110627975911795852892119722437941212672242510963561615
    3211116781852122673250196683894481113453177171120664798111736240778120494845281203426037311081463016
    2811290263828121951277516757664714113856257811125829516811697180002120053795421201975290611288458310
    2411475546238118843442246796586502113053147561111662372811685711386118227318201202332675911388039705
    201122485256011292544020677703624010904297657107477603531164666175311672726440?11045338822
    161082912950710284357942666710829110348611321100931619871132774044311208793451?10444170837
    1294204698059088093489636072137092633019449040176412100968288059984757791?9475823880
    108664042378829296006160720410328537514516826689855795092085919280755037?8499306558
    87481289176707601712256086906017271640774715984870382137524897915901827?7333303410
    66113366421571241573850081164685945793344588597084769085079646406255849?5979495436
    5534724148449507556534559320971521139730051475566886102819114??5279913012
    4451636797341713945184000526631440966807143629838105155504007??4464359082
    3353107868632398996013246558586342998593334331049374035945486??3475052196
    224515751862417779080???????
    1?????????

    Подключение 4 SSD через коммутатор PCIe 3 x8 (24688682029056) - ровная линия 6800 MiB/s (7.13 GB/s = 89% PCIe 3.0 x4) при 64-24 потоках.

    Подключение 8 SSD через коммутатор PCIe 3 x8 (50060687515648) - ровная линия 6800 MiB/s (7.13 GB/s = 89% PCIe 3.0 x4) при 64-40 потоках, слишком длинный хвост на одном из каталогов (cads, 35 минут CPU) - получается неинформативно.

    Отформатировал 4 SSD обратно под 512 байт вместо 4096, файлы легли как-то по-другому, 24714205741056 байт (на 1134592 байт меньше, чем в прошлый раз). Потеря 1%.

    Отформатировал SSD обратно под 4096 байт в блоке и собрал LV по-прежнему: "lvcreate --name fast --extents 100%FREE --stripes 4 --stripesize 1m --type striped test8left"; ra auto = 8 MiB; optimal_io_size = 4194304; minimum_io_size = 1048576. Собрал ext4: "mkfs.ext4 -E [stride=256,stripe_width=1024,]lazy_itable_init=0,lazy_journal_init=0 [-G 128 -J size=2048] -L test4fast -v -O 64bit,dir_index,dir_nlink,extent,ext_attr,filetype,flex_bg,has_journal,huge_file,large_file,meta_bg,sparse_super /dev/test8left/fast"; параметры stride=256,stripe_width=1024 устанавливаются автоматически; монтирование: [stripe=1024,]nodiratime,relatime,journal_checksum[,journal_async_commit,data=writeback],delalloc,nobarrier,noauto. Попробовал залить файлы с medium на fast в 24 потока tar_copy_all.sh ("tar -C /test4medium/$1 -H posix -cf - . | tar -C /test4fast/$1 -xf -"; по-прежнему 20% idle; поначалу 3-4GB/sec вместо 5-6 для XFS, а потом падала до катастрофических 150 MB/sec (один из - kworker/u66:1+f - залипал на 100% CPU). Убрал "-G 128 -J size=2048" ("mkfs.ext4 -E lazy_itable_init=0,lazy_journal_init=0 -L test4fast -v -O 64bit,dir_index,dir_nlink,extent,ext_attr,filetype,flex_bg,has_journal,huge_file,large_file,meta_bg,sparse_super /dev/test8left/fast") и "journal_async_commit,data=writeback" ("nodiratime,relatime,journal_checksum,delalloc,nobarrier,noauto"), использовал nocache при копировании, скорость почти равномерно держалась на 2.5 GB/s (50% idle, 38% sy, 1% us, 1% hi), но в самом конце повторилась история с kworker/u65:2+f. Занятый объём - 24707263184896 (на 7GB - 0.02% - меньше, чем XFS).

    Поставил e2fsprogs-1.46.5 в /usr/local (опции mkfs по умолчанию: dir_index,ext_attr,filetype,large_file,resize_inode,sparse_super; blocksize = 4096, inode_size = 256, опции mkfs.ext4 по умолчанию: 64bit,dir_nlink,extent,extra_isize,flex_bg,has_journal,huge_file,metadata_csum; опции монтирования по умолчанию: acl,user_xattr). Собрал ext4: "/usr/local/sbin/mkfs.ext4 -E lazy_itable_init=0,lazy_journal_init=0 -G 128 -i 262144 -I 1024 -L test4fast -m 0 -v -O inline_data,metadata_csum_seed,sparse_super2". Предоставлено на 100ГБ меньше места, чем XFS. Занятый объём - 24569870823424 (свободного места ровно столько сколько было при XFS). Монтирование: stripe=1024,nodiratime,relatime,journal_checksum,delalloc,nobarrier,dioread_nolock,noauto. Скорость заполнения почти половину объёма равномерно держалась на 3.8 GB/s (60% sy, 1% us, 1% hi), затем упала - в среднем 1.6 GBps, с провалами до 100 MB/s, при этом разные kworker/u6*:*+f загружают ядро на 100% каждый. Для справки: XFS обеспечивает среднюю скорость записи 5.75 GBps. nodiscard ничего не изменил. Ограничение dirty_background_bytes и dirty_bytes ничего не меняет. Отключение журнала (^has_journal) значительно увеличивает скорость записи - почти 2/3 равномерно держалась на 5.2GB/s затем упала (временами до 900MB/s) в среднем 1.97GB/s. Включение fast_commit и при монтировании commit=60,max_batch_time=30000,min_batch_time=10000 не улучшают ситуацию. Короткий отдых не приводит в чувство (kworker некоторое время грузит ЦП на 100% и даже добавляет 20ГБ в cache "из воздуха"). 3 в drop_caches не приводит в чувство. Монтировать с nodelalloc не надо. Монтирование с nombcache ничего не даёт.

    При первом проходе tar_null загрузка ЦП - 90% (relatime?).

    inline ускоряет на малых потоках на 7-15%.

    nocache даёт чудесную горизонтальную линию на 12.5GB/s и хвост для несоразмерно длинного каталога (cads). Замедляет при небольшом количестве потоков.

    Увеличение inode_readahead_blks до 64 немного уменьшает пропускную способность.

    Сборка с bigalloc,fast_commit - скорость наполнения равномерно держится на 3.82 GBps пока не закончилось место (60-75% sy), при этом разные kworker/u6*:*+f загружают ядро на 100% каждый, было израсходовано на 4% (900GB) больше места и не поместилось 0.3% файлов (возможно, что самых больших, но не менее 180GB - 0.7%).

    Переход от LVM к mdadm (статистика mdadm завышенная; /sys/block/md127/queue/iostats=0?)

    mdadm --create /dev/md/test4left --verbose --raid-devices=4 --level=stripe --chunk 1024K --name=test4fast /dev/nvme{8,9,22,23}n1
    mkfs.xfs -f -L fast -m finobt=1 -d su=1m,sw=4 -l su=256k,lazy-count=1 /dev/md/test4left
    

    Попробовал RAID-5 с помощью mdadm

    mdadm --create /dev/md/test4fast --verbose --raid-devices=4 --level=raid5 --chunk 1024K --name=test4fast /dev/nvme{8,9,22,23}n1
    mdadm: layout defaults to left-symmetric
    mdadm: automatically enabling write-intent bitmap on large array
    

    Скорость синхронизации по умолчанию равна 200 МБ/сек, попробуем увеличить

    echo 3000000 > /sys/block/md127/md/sync_speed_max
    

    Упираемся в 100% ЦП на скорости 619 MB/сек! А где же обещанное в dmesg счастье (37683 MB/s для raid-6)? Пробовал /sys/block/md127/md/sync_force_parallel, 16384 в /sys/block/md127/md/stripe_cache_size (было 256), "blockdev --setra 65536 /dev/md127" (было 12288), отключение /sys/block/md127/md/safe_mode_delay, 16384 в /sys/block/md127/md/stripe_cache_size (было 256). Немного помогает 4 в /sys/block/md127/md/group_thread_cnt - увеличивает скорость до 1300 MB/s, но маленькими кусочками (150k IOPS на устройство), увеличение group_thread_cnt разбивает запросы ещё меньше (12 KB, 200k IOPS) и скорость не увеличивается.

    mkfs.xfs -f -L fast -m finobt=1 -d su=1m,sw=3 -l su=256k,lazy-count=1 /dev/md/test4fast 
    

    Файловая система получилась на четверть меньше, т.е. сравнивать результаты напрямую нельзя, скорость наполнения равномерно держится на 1.5 - 1.9GB/s,

    потоковHTmdadm raid5mdadm raid5 resyncmdadm raid6 resynclvm raid5????
    64107770339889557700554960014340987122557269045223070????
    481085060062299982076551008707245191551827039395765509????
    4011033620641101028774041013058201192276961889518319597????
    3611008221967101748581431017799109293219007809469665817????
    3211116781852102251586651023554267893141107899593739027????
    2811290263828103019695901028842589693763095689745739572????
    2411475546238104091485161048660626494662428579670626264????
    2011224852560102022183921024953518394579291319664834453????
    1610829129507965782886896598752599382985330?????
    129420469805905561812489882491128518060717?????
    108664042378826167800181678361637769460909?????
    874812891767209297339?7028473783?????
    661133664215984612982?5936716754?????
    553472414845247868964?5179325438?????
    445163679734392369536?4349553703?????
    335310786863445659723?3406289924?????
    224515751862406675471?2394484016?????
    1?????????

    Попробовал вариант без bitmap (16374657409024 байт; скорость наполнения равномерно держится на 1.9 - 2.1GB/s)

    mdadm --create /dev/md/test4fast --bitmap=none --verbose --raid-devices=4 --level=raid5 --chunk 1024K --name=test4fast --consistency-policy=resync /dev/nvme{8,9,22,23}n1
    mkfs.xfs -f -L fast -m finobt=1 -d su=1m,sw=3 -l su=256k,lazy-count=1 /dev/md/test4fast
    echo 3000000 > /sys/block/md127/md/sync_speed_max
    echo 4 > /sys/block/md127/md/group_thread_cnt
    echo 1 > /sys/block/md127/queue/iostats # статистика чтения всё равно завышена
    дождаться завершения синхронизации
    

    Массив с маленьким stripe ведёт себя неустойчиво - скорость наполнения равномерно держится на 2.2-2.3GB/s, потом падает до 1.2GB/s

    mdadm --create /dev/md/test4fast --bitmap=none --verbose --raid-devices=4 --level=raid5 --chunk 64K --name=test4fast --consistency-policy=resync /dev/nvme{8,9,22,23}n1
    mkfs.xfs -f -L fast -m finobt=1 -d su=64k,sw=3 -l su=16k,lazy-count=1 /dev/md/test4fast
    echo 3000000 > /sys/block/md127/md/sync_speed_max
    echo 4 > /sys/block/md127/md/group_thread_cnt
    echo 1 > /sys/block/md127/queue/iostats # статистика чтения всё равно завышена
    echo $[16*1024] > /sys/block/md127/md/stripe_cache_size # никакого толка
    дождаться завершения синхронизации
    

    Вариант с внешним и внутренним журналом исследовать не стал.

    Массив raid6 без bitmap (12427501346816 байт; скорость наполнения равномерно держится на 1.5-1.8GB/s (средняя 1.58, 22% sy, 1.2% hi)

    mdadm --create /dev/md/test4fast --bitmap=none --verbose --raid-devices=4 --level=raid6 --chunk 1024K --name=test4fast --consistency-policy=resync /dev/nvme{8,9,22,23}n1
    mkfs.xfs -f -L fast -m finobt=1 -d su=1m,sw=3 -l su=256k,lazy-count=1 /dev/md/test4fast
    echo 3000000 > /sys/block/md127/md/sync_speed_max
    echo 12 > /sys/block/md127/md/group_thread_cnt # для raid6 полезно больше 4 - 1.6GB/s (больше, чем для raid5), 5% hi, 170k/120k IOPS
    echo 1 > /sys/block/md127/queue/iostats # статистика чтения всё равно завышена
    # echo $[16*1024] > /sys/block/md127/md/stripe_cache_size - упала скорость синхронизации
    дождаться завершения синхронизации
    

    Попробовал RAID-5 с помощью LVM (lvmraid(7); получается много блочных устройств, посмотреть : "lvs -a")

    mdadm --zero-superblock /dev/nvme{8,9,22,23}n1
    pvcreate  /dev/nvme{8,9,22,23}n1
    vgextend test8left /dev/nvme{8,9,22,23}n1
    lvcreate --name fast --extents 100%FREE --stripes 3 --stripesize 1m --type raid5 --maxrecoveryrate 8G test8left /dev/nvme{8,9,22,23}n1
    
    lrwxrwxrwx 1 root root       8 апр  3 15:27 test8left-fast -> ../dm-13
    lrwxrwxrwx 1 root root       7 апр  3 15:27 test8left-fast_rimage_0 -> ../dm-6
    lrwxrwxrwx 1 root root       7 апр  3 15:27 test8left-fast_rimage_1 -> ../dm-8
    lrwxrwxrwx 1 root root       8 апр  3 15:27 test8left-fast_rimage_2 -> ../dm-10
    lrwxrwxrwx 1 root root       8 апр  3 15:27 test8left-fast_rimage_3 -> ../dm-12
    lrwxrwxrwx 1 root root       7 апр  3 15:27 test8left-fast_rmeta_0 -> ../dm-5
    lrwxrwxrwx 1 root root       7 апр  3 15:27 test8left-fast_rmeta_1 -> ../dm-7
    lrwxrwxrwx 1 root root       7 апр  3 15:27 test8left-fast_rmeta_2 -> ../dm-9
    lrwxrwxrwx 1 root root       8 апр  3 15:27 test8left-fast_rmeta_3 -> ../dm-11
    
    дождаться завершения синхронизации
    mkfs.xfs -f -L fast -m finobt=1 -d su=1m,sw=3 -l su=256k,lazy-count=1 /dev/test8left/fast
    

    Синхронизируется неспешно - 400/100 МБ/сек с каждого устройства - 1.1GB/s (1 поток mdX_raid5 90%). Чувствуется недоделанность - как поменять max rate, как узнать текущий rate, приостановить? Скорость наполнения равномерно держится на 750MB/s.

    LVM отказался делать raid6 из 4 томов. Не очень-то и хотелось! Всё равно RAID-6 ненастоящий - не умеет при проверке определять какой том предоставил неверные данные и чинить.

    Ссылки

    @ Карта сайта News Автора!

    Bog BOS: hardware:  SSD



    Copyright © 1996-2024 Sergey E. Bogomolov; www.bog.pp.ru