|
Bog BOS: hardware: SSD |
Последнее изменение файла: 2024.10.02
Скопировано с www.bog.pp.ru: 2024.11.23
SSD накопитель представляет собой NAND флэш память в корпусе форм фактора 2.5" или 1.8" с интерфейсом SATA. Позволяет использование в качестве "почти обычного" жёсткого диска. Для ускорения операций может использоваться оперативная память под кеш и параллельный доступ к нескольким микросхемам флэш.
Предварительно необходимо ознакомиться с материалами о флэш.
Контроллер 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".
Выравнивание начала каждого раздела на границу блока стирания: либо изобразить устройство с 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 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 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 часов).
Обнаружились проблемы при подключении к Intel C600 SCU (SAS1) - под тяжёлой нагрузкой (моделируется "badblocks -b 4096 -c 1024", несколько дней) у диска сносит крышу (начинает рапортовать о своём объёме в 600 PB и т.п.), приходится перезагружаться (SSD Intel DC S3500 проходит без проблем). Подключение через LSI MegaRAID 9266-8i выявило отсутствие TRIM у оного и невозможность работы без TRIM.
Серия 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 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)!
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 команда устройство параметры") с командами
Smart Log for NVME device:nvme0n1 namespace-id:ffffffff critical_warning : 0 temperature : 13 C available_spare : 100% available_spare_threshold : 10% percentage_used : 0% data_units_read : 4,065,976 data_units_written : 0 host_read_commands : 16,503,661 host_write_commands : 0 controller_busy_time : 0 power_cycles : 2 power_on_hours : 6 unsafe_shutdowns : 0 media_errors : 0 num_err_log_entries : 0 Warning Temperature Time : 0 Critical Composite Temperature Time : 0 Temperature Sensor 1 : 0 C Temperature Sensor 2 : 0 C Temperature Sensor 3 : 0 C Temperature Sensor 4 : 0 C Temperature Sensor 5 : 0 C Temperature Sensor 6 : 0 C Temperature Sensor 7 : 0 C Temperature Sensor 8 : 0 C или Thermal Management T1 Trans Count : 0 Thermal Management T2 Trans Count : 0 Thermal Management T1 Total Time : 0 Thermal Management T2 Total Time : 0
Additional Smart Log for NVME device:nvme0n1 namespace-id:ffffffff key normalized raw program_fail_count : 100% 0 erase_fail_count : 100% 0 wear_leveling : 100% min: 0, max: 1, avg: 0 end_to_end_error_detection_count: 100% 0 crc_error_count : 100% 0 timed_workload_media_wear : 100% 0.000% timed_workload_host_reads : 100% 100% timed_workload_timer : 100% 380 min thermal_throttle_status : 100% 0%, cnt: 0 retry_buffer_overflow_count : 100% 0 pll_lock_loss_count : 100% 0 nand_bytes_written : 100% sectors: 685 host_bytes_written : 100% sectors: 0
Сборка версии 0.9: make.
Дополнения для LightNVM lnvm (LightNVM), memblaze, wdc, huawei, netapp, toshiba (KIOXIA на него не отзывается), micron, seagate и Intel (intel).
Расширения Intel (1.8.1):
Intel Temperature Statistics -------------------------------- Current temperature : 12 Last critical overtemp flag : 0 Life critical overtemp flag : 0 Highest temperature : 28 Lowest temperature : 12 Max operating temperature : 85 Min operating temperature : 0 Estimated offset : 0
Расширения wdc (nvme wdc id-ctrl /dev/nvme0n1):
Интересные данные в log:
Интересные данные в intel smart-log-add:
Серия 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)!
Серия Intel SSD D7-P5620 на базе 144-layer (96?) 3D TLC NAND: U.2 (15 мм), до 12.8TB (6.4TB - SSDPF2KE064T1), PCIe 4.0 x4, NVMe 1.4, NVMe-MI 1.1, "up to" 390000 IOPS, 7100/4200 MB/сек, 3 DWPD (гарантия 5 лет), защита от пропадания питания с самотестированием (PLI), потребляемая мощность - 18 Вт, UBER - 10^-17.
Серия 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. Из интересного о контроллере (nvme id-ctrl -H /dev/nvme0):
Из интересного о свойствах пространств имён (id-ns -H /dev/nvme0n1):
LBA Format 0 : Metadata Size: 0 bytes - Data Size: 512 bytes - Relative Performance: 0x2 Good (in use) LBA Format 1 : Metadata Size: 8 bytes - Data Size: 512 bytes - Relative Performance: 0x2 Good LBA Format 2 : Metadata Size: 0 bytes - Data Size: 4096 bytes - Relative Performance: 0x2 Good LBA Format 3 : Metadata Size: 8 bytes - Data Size: 4096 bytes - Relative Performance: 0x2 Good LBA Format 4 : Metadata Size: 64 bytes - Data Size: 4096 bytes - Relative Performance: 0x2 Good
Серия 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 расчитана на нагрузку 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):
Из интересного о свойствах пространств имён:
LBA Format 0 : Metadata Size: 0 bytes - Data Size: 512 bytes - Relative Performance: 0 Best (in use) LBA Format 1 : Metadata Size: 8 bytes - Data Size: 512 bytes - Relative Performance: 0 Best LBA Format 2 : Metadata Size: 0 bytes - Data Size: 1 bytes - Relative Performance: 0 Best LBA Format 3 : Metadata Size: 0 bytes - Data Size: 4096 bytes - Relative Performance: 0 Best LBA Format 4 : Metadata Size: 8 bytes - Data Size: 4096 bytes - Relative Performance: 0 Best LBA Format 5 : Metadata Size: 64 bytes - Data Size: 4096 bytes - Relative Performance: 0 Best
Серия 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, подключённых напрямую к ЦП, условия:
nvme list-ns /dev/nvme8 [ 0]:0x1 nvme id-ns /dev/nvme8 - -namespace-id=0x1 nlbaf : 5 # 6 штук форматов = количество поддерживаемых комбинаций размера данных LBA и размера метаданных - 1 flbas : 0 # использованный вариант lbaf 0 : ms:0 lbads:9 rp:0 (in use) # ms - размер метаданных, lbads - 2^9 - размер блока lbaf 1 : ms:8 lbads:9 rp:0 lbaf 2 : ms:0 lbads:0 rp:0 lbaf 3 : ms:0 lbads:12 rp:0 lbaf 4 : ms:8 lbads:12 rp:0 lbaf 5 : ms:64 lbads:12 rp:0 nvme format --lbaf=3 /dev/nvme8n1 cat /sys/block/nvme8n1/queue/hw_sector_size 4096 на всякий случай перезагрузиться и только потом собрать LVM
umount /test4fast mount /test4fast cd /test4fast time echo */*|xargs --max-args=1 --max-procs=$par ~/bin/tar_null.sh где ~/bin/tar_null.sh (fullblock, noblock и увеличение размера блока ухудшают результат): tar -C $1 -H posix -cf - . 2>/dev/null | dd bs=10240k of=/dev/null iflag=direct status=none
| потоков | B/s | cgroups 16GB | cgroups 64GB | nocache | dm_mq_nr_hw_queues=4 | max_sectors_kb=4096 | memoptimizer | nomerges=2 | kswapd_threads=2 |
| 64 | 10777033988 | 7909308024 | 8268012945 | 11224669028 | 10770059744 | 10724334269 | 10978509982 | 10260260226 | 10651385274 |
| 48 | 10850600622 | 7915296364 | 8208583725 | 11344441837 | 10859769305 | 10897233727 | 11082271015 | 10331300676 | 10729385861 |
| 40 | 11033620641 | 7851747288 | 8200518783 | 11487355543 | 10883993069 | 10926390888 | 11162891702 | 10445225102 | 10838147854 |
| 36 | 11008221967 | 7722125443 | 8156240120 | 11598835374 | 11013947083 | 11015036854 | 11229871405 | 10448475241 | 10881611347 |
| 32 | 11116781852 | 7553569523 | 8018901683 | 11665249174 | 11140695463 | 11190874435 | 11339658269 | 10507691875 | 11038987603 |
| 28 | 11290263828 | 7508151497 | ? | 11853683429 | 11224888247 | 11260592028 | 11511149091 | 10707639722 | 11148811924 |
| 24 | 11475546238 | 7391191198 | ? | 11670790907 | 11471423507 | 11373756854 | 11602908578 | 10776719130 | 11269356933 |
| 20 | 11224852560 | 7178042030 | ? | 11209736466 | 11172010120 | 11267784716 | 11344759496 | 10630923225 | 11016544235 |
| 16 | 10829129507 | 6633334811 | ? | 10592440006 | 10771327117 | 10804501914 | 10530220711 | 10213896087 | ? |
| 12 | 9420469805 | 5908127845 | ? | 9229946723 | 9449732567 | 9545153666 | 9277038517 | 9068465303 | ? |
| 10 | 8664042378 | 5454408132 | ? | 8437339223 | 8639941434 | 8640853713 | 8521605497 | 8131123007 | ? |
| 8 | 7481289176 | 4857298519 | ? | 7200683314 | 7545914885 | 7550613302 | 7462012225 | 7205724084 | ? |
| 6 | 6113366421 | 4081786139 | ? | 5822417716 | 6142515118 | 6153992672 | 6044897523 | 5950868514 | ? |
| 5 | 5347241484 | 3669119140 | ? | 5089228975 | ? | 5353644738 | 5281771602 | 5189684569 | ? |
| 4 | 4516367973 | ? | ? | ? | ? | 4508470116 | 4505654969 | 4453895409 | ? |
| 3 | 3531078686 | ? | ? | ? | ? | ? | 3472161527 | 3487673205 | ? |
| 2 | 2451575186 | ? | ? | ? | ? | ? | 2415165446 | 2433320964 | ? |
| 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 без HT | HT | HT + rq_affinity=2 | HT + zone_reclaim_mode | HT + dm/ra=512 | HT + dm/ra=128 | HT + dm/ra=2048 | HT ra=256/1024 | HT ra=64/256 |
| 64 | 10788715499 | 10777033988 | 10612307440 | 10768370377 | 11228396909 | 12180894616 | 10644751461 | 10622593292 | 11710119344 |
| 48 | 10856615972 | 10850600622 | 10682300343 | 10842912406 | 11349495249 | 12386602130 | 10719547797 | 10632377618 | 11900361609 |
| 40 | 11034502456 | 11033620641 | 10792470433 | 11006991378 | 11609045564 | 12345184162 | 10876889323 | 10578190326 | 12164263370 |
| 36 | 11147690495 | 11008221967 | 10840791140 | 11057568257 | 11765678096 | 12049145356 | 11033443310 | 10615302192 | 12364262345 |
| 32 | 11237500068 | 11116781852 | 10969242028 | 11114996969 | 11956576074 | 11806236260 | 11118907462 | 10705195435 | 12044341987 |
| 28 | 11308153468 | 11290263828 | 11112418149 | 11232739874 | 12024961963 | 11481559867 | 11350944377 | 10807152441 | 11683701611 |
| 24 | 11402881783 | 11475546238 | 11159791705 | 11384576030 | 11828601521 | 11144121529 | 11350860964 | 10765087014 | 11549542127 |
| 20 | 11065331147 | 11224852560 | 11078162779 | 11059621788 | 11460571574 | ? | ? | 10467136362 | 11034394069 |
| 16 | 10677034663 | 10829129507 | ? | 10625703494 | 10609587646 | ? | ? | 9800827188 | 10076959565 |
| 12 | 9496351338 | 9420469805 | ? | ? | 9495482969 | ? | ? | 8717899225 | 8790727334 |
| 10 | 8574881738 | 8664042378 | ? | ? | 8551468891 | ? | ? | 7959248523 | 7957846651 |
| 8 | 7535391215 | 7481289176 | ? | ? | 7304403109 | ? | ? | 6909730794 | ? |
| 6 | 6159910290 | 6113366421 | ? | ? | 5892570539 | ? | ? | 5643694553 | ? |
| 5 | 5380653296 | 5347241484 | ? | ? | 5155557620 | ? | ? | ? | ? |
| 4 | 4532735761 | 4516367973 | ? | ? | 4368172467 | ? | ? | ? | ? |
| 3 | 3519688439 | 3531078686 | ? | ? | ? | ? | ? | ? | ? |
| 2 | 2461933135 | 2451575186 | ? | ? | ? | ? | ? | ? | ? |
| 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 | блок 512 | ext4 | ext4+inline | ext4+inline+cache | ext4+inline+bigalloc+fast_commit | mdadm stripe |
| 64 | 10777033988 | 11676740629 | 6479316003 | 10569382357 | 10542246914 | ? | 11654512359 | 11744508529 | 10409373933 |
| 48 | 10850600622 | 11891646554 | 6556375766 | 10994976968 | 10884021968 | 11663001147 | 11739681470 | 11695535505 | 10799799622 |
| 40 | 11033620641 | 12292701972 | 6567242693 | 11086191332 | 10997389526 | 11714033641 | 11892952144 | 11838616268 | 10896867513 |
| 36 | 11008221967 | 12500420761 | 6630310010 | 11187254471 | 11106279759 | 11795852892 | 11972243794 | 12126722425 | 10963561615 |
| 32 | 11116781852 | 12267325019 | 6683894481 | 11345317717 | 11206647981 | 11736240778 | 12049484528 | 12034260373 | 11081463016 |
| 28 | 11290263828 | 12195127751 | 6757664714 | 11385625781 | 11258295168 | 11697180002 | 12005379542 | 12019752906 | 11288458310 |
| 24 | 11475546238 | 11884344224 | 6796586502 | 11305314756 | 11116623728 | 11685711386 | 11822731820 | 12023326759 | 11388039705 |
| 20 | 11224852560 | 11292544020 | 6777036240 | 10904297657 | 10747760353 | 11646661753 | 11672726440 | ? | 11045338822 |
| 16 | 10829129507 | 10284357942 | 6667108291 | 10348611321 | 10093161987 | 11327740443 | 11208793451 | ? | 10444170837 |
| 12 | 9420469805 | 9088093489 | 6360721370 | 9263301944 | 9040176412 | 10096828805 | 9984757791 | ? | 9475823880 |
| 10 | 8664042378 | 8292960061 | 6072041032 | 8537514516 | 8266898557 | 9509208591 | 9280755037 | ? | 8499306558 |
| 8 | 7481289176 | 7076017122 | 5608690601 | 7271640774 | 7159848703 | 8213752489 | 7915901827 | ? | 7333303410 |
| 6 | 6113366421 | 5712415738 | 5008116468 | 5945793344 | 5885970847 | 6908507964 | 6406255849 | ? | 5979495436 |
| 5 | 5347241484 | 4950755653 | 4559320971 | 5211397300 | 5147556688 | 6102819114 | ? | ? | 5279913012 |
| 4 | 4516367973 | 4171394518 | 4000526631 | 4409668071 | 4362983810 | 5155504007 | ? | ? | 4464359082 |
| 3 | 3531078686 | 3239899601 | 3246558586 | 3429985933 | 3433104937 | 4035945486 | ? | ? | 3475052196 |
| 2 | 2451575186 | 2417779080 | ? | ? | ? | ? | ? | ? | ? |
| 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,
| потоков | HT | mdadm raid5 | mdadm raid5 resync | mdadm raid6 resync | lvm raid5 | ? | ? | ? | ? |
| 64 | 10777033988 | 9557700554 | 9600143409 | 8712255726 | 9045223070 | ? | ? | ? | ? |
| 48 | 10850600622 | 9998207655 | 10087072451 | 9155182703 | 9395765509 | ? | ? | ? | ? |
| 40 | 11033620641 | 10102877404 | 10130582011 | 9227696188 | 9518319597 | ? | ? | ? | ? |
| 36 | 11008221967 | 10174858143 | 10177991092 | 9321900780 | 9469665817 | ? | ? | ? | ? |
| 32 | 11116781852 | 10225158665 | 10235542678 | 9314110789 | 9593739027 | ? | ? | ? | ? |
| 28 | 11290263828 | 10301969590 | 10288425896 | 9376309568 | 9745739572 | ? | ? | ? | ? |
| 24 | 11475546238 | 10409148516 | 10486606264 | 9466242857 | 9670626264 | ? | ? | ? | ? |
| 20 | 11224852560 | 10202218392 | 10249535183 | 9457929131 | 9664834453 | ? | ? | ? | ? |
| 16 | 10829129507 | 9657828868 | 9659875259 | 9382985330 | ? | ? | ? | ? | ? |
| 12 | 9420469805 | 9055618124 | 8988249112 | 8518060717 | ? | ? | ? | ? | ? |
| 10 | 8664042378 | 8261678001 | 8167836163 | 7769460909 | ? | ? | ? | ? | ? |
| 8 | 7481289176 | 7209297339 | ? | 7028473783 | ? | ? | ? | ? | ? |
| 6 | 6113366421 | 5984612982 | ? | 5936716754 | ? | ? | ? | ? | ? |
| 5 | 5347241484 | 5247868964 | ? | 5179325438 | ? | ? | ? | ? | ? |
| 4 | 4516367973 | 4392369536 | ? | 4349553703 | ? | ? | ? | ? | ? |
| 3 | 3531078686 | 3445659723 | ? | 3406289924 | ? | ? | ? | ? | ? |
| 2 | 2451575186 | 2406675471 | ? | 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 ненастоящий - не умеет при проверке определять какой том предоставил неверные данные и чинить.
Серия Intel (в дальнейшем Solidigm от SK hynix) D7-P5620 расчитана на нагрузку 3 DWPD (методика не указана, гарантия 5 лет), поставляются в объёмах 12.8 TB (SSDPF2KE128T1), 6.4 TB (SSDPF2KE064T1), 3.2 TB и 1.6TB. Изготавливаются на базе 144-уровнего 3D TLC SK hynix. Имеются варианты с шифрованием и безопасной очисткой (OPAL 2.0 - SIE, SED, SED FIPS). Поставляется в формате U.2 (SFF/2.5", 15 мм толщиной) под PCIe 4.0 x4, NVME 1.4, NVMe-MI 1.1. Обещается защита от внезапного отключения питания (конденсатор с самотестированием) и сквозная защита данных (end-to-end). Размер сектора: 512, 520, 4096, 4104 или 4160 байт. ?Возможен выбор из 6 режимов потребления (12 В) вплоть до 20 Вт (?в реальности устройство предлагает до 27.5 Вт), в ожидании - от 5 Вт. Обещается производительность последовательных операций до 7100/3700 MB/s (в другом месте 7100/4200 при 128 kB записях), случайных - до 1000/374 kIOPS (в другом месте 1100/390 kIOPS), задержки чтения/записи - 75/15 мкс (99.9999%), UBER 1e-17, silent corruption 1e-25. Из интересного о контроллере (nvme id-ctrl -H /dev/nvme8):
Из интересного о свойствах пространств имён (nvme id-ns -H /dev/nvme0n1):
LBA Format 0 : Metadata Size: 0 bytes - Data Size: 512 bytes - Relative Performance: 0x2 Good (in use) LBA Format 1 : Metadata Size: 8 bytes - Data Size: 512 bytes - Relative Performance: 0x2 Good LBA Format 2 : Metadata Size: 0 bytes - Data Size: 4096 bytes - Relative Performance: 0x2 Good LBA Format 3 : Metadata Size: 8 bytes - Data Size: 4096 bytes - Relative Performance: 0x2 Good LBA Format 4 : Metadata Size: 64 bytes - Data Size: 4096 bytes - Relative Performance: 0x2 Good
Серия D7-5520 для интенсивного чтения (1DWPD) до 15.36 TB. Обзор.
Серия D7-5810 (SLC 144L) для интенсивной записи (50 DWPD), U.2, 800GB и 1600 GB.
Тестирование многопоточного восстановления файлов (bacula)
Тестирование многопоточного копирования файлов (tar_copy_all.sh) на себя (4.6 TB, 19 миллионов файлов, в промежутках umount/mount):
|
Bog BOS: hardware: SSD |