Raid10 на бытовых SSD

для тех кто не видел как флеш течет

2tb 990 pro в моем ПК https://imgur.com/a/eDiF0YS (4х кратно упала скорость чтения в начале диска где файлы ОС и прочее не перезаписываемое)

2tb sata ssd купленый для опытов с рейдом https://imgur.com/a/iNcewAS , так же скорость чтения в начале диска (где я записал тестовые данные сразу после покупки) упала до 58 MB/s . диску всего 1 месяц

флеш течет на старых данных

Bit rot или что?

выше как раз запостил примеры чтобы нагляднее было

энтерпрайзные диски умеют сами отслеживать устаревание данных и записывать их заново

Я сварщик не настоящий, но данное утверждение слышу впервые. Возможно, речь идёт о TRIM.

почему-то многие об этом слышат впервые или вообще начинают утверждать что такое может быть только с палеными или бу ssd, но правда в том что они все текут (разряжаются ячейки) в течении уже месяцев, что приводит к драматичному падению скорости чтения

особенно там где в ячейку записывается больше одного значения (tlc, qlc, у меня в тесте как раз tlc драйв)

флеш течет на старых данных

Причём тут скорость?

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

притом что чем сильнее утек флеш тем дольше он читается – контролер пробует разные варианты чтения чтобы определить что же там записано. Вплоть до того что скорость падает <1 МБ/с , это вполне реальные случаи. там где-то уйма ссылок с примерами совершенно разных десктопных драйвов https://www.reddit.com/r/unRAID/comments/10bi4sc/ssds_that_dont_slow_down_reading_old_files/

Я имел ввиду утверждение, что диски сами находят устаревшие данные. Похоже на механизм TRIM, который в 2025, наверное, поддерживается всеми.

Заряды разряжаются, да, но насколько сильно это влияет на скорость и как скоро с момента ввода в эксплуатацию — не знаю.

нет у меня оба включены были все это время. да и там нет никакой подзарядки, он может только определить сдохший блок и пометить неиспользуемым. такое чтобы в фоне проверять скорость чтения и переписывать в новое место в моем понимании аппаратно существует лишь в серверных решениях

«Я имел ввиду утверждение, что диски сами находят устаревшие данные» – как я понимаю в обычных десктопных драйвах такого не существует, по крайней мере не гуглятся контролеры с таким функционалом

вот еще пример с графиками как простая поблочная перезапись всего диска заново восстанавливает скорость чтения

https://thegearforum.com/threads/ssd-slowness-over-time-i-learned-my-lesson-re-charging-memory-cells.4677/

но это довольно тупое решение с точки зрения траты ресурса диска, оно перезаписывает и хорошо и плохо читаемые данные.

но правда в том что они все текут (разряжаются ячейки) в течении уже месяцев

По идее такой быстрой деградации быть не должно. Читал, что свежая, неизношенная флеш-память способна в обесточенном состоянии хранить данные десятилетиями. Да и JEDEC для консьюмерских накопителей устанавливает годовой срок хранения в обесточенном состоянии при исчерпании заявленного ресурса службы ячеек.

JEDEC для консьюмерских применений устанавливает срок хранения 1 год «на полке» для любого диска, даже нового

https://www.crucial.com/support/articles-faq-ssd/ssds-and-smart-data

The Joint Electron Device Engineering Council (JEDEC) is the industry group which creates standards and specifications for semiconductor-based devices and assemblies. Micron is a leading member of JEDEC, which defines data retention in a specific way: For SSDs in client applications (like business or personal computers), data retention for an SSD shall be one year, in an unpowered state, stored at 30 °C (86 °F). This should give most computer users plenty of time to retrieve any data from an unused drive after some time on the shelf, if needed.

нигде нет оговорок что это относится к дискам с изношенным ресурсом.

да и вцелом, даже срок хранения 1 год для драйвов с уже исчерпавшимся ресурсом, это никак не противоречит тому что скорость через год может упасть до 1 МБ/с как по ссылкам выше пишут. Скорость никто не гарантирует. А на больших обьемах 1 МБ/с чтение это то же самое что потеря данных, копировать с ССД ты их будешь неделями.

Вцелом не похоже что для SSD хранение на полке или с питанием отличается , если у его контролера нет функции проверки чтения и записи заново всех данных (а ее если я верно понял нет ни в одном десктопном диске)

если кто-то хочет проверить свой ssd драйв на скорость чтения

fio –filename=/dev/sda –direct=1 –rw=read –bs=64k –ioengine=libaio –iodepth=64 –runtime=2000 –numjobs=1 –time_based –group_reporting –eta-newline=1 –readonly –name=linear-read-job

это не деструктивно можно запустить на испльзуемом диске и по выводу очевидна скорость чтения по мере того как он идет по диску, просадки будут хорошо видны

нигде нет оговорок что это относится к дискам с изношенным ресурсом.

JEDEC SSD Specifications Explained

Страница 25 (Endurance rating):

The SSD manufacturer shall establish an endurance rating for an SSD that represents the maximum number of terabytes that may be written by a host to the SSD, using the workload specified for the application class, such that the following conditions are satisfied:

1. the SSD maintains its capacity;
2. the SSD maintains the required UBER for its application class;
3. the SSD meets the required functional failure requirement (FFR) for its application class; and
4. the SSD retains data with power off for the required time for its application class.

This rating is referred to as TBW. Requirements for UBER, FFR, and retention are defined for each application class.

Страница 39 (Direct endurance verification method):

• Best method but not likely to be used.
• SSDs are stressed to their stated endurance rating (in TBW) using specified workloads.
• The endurance stressing is to be performed at both high and low temperatures.
• Following this endurance stressing, retention testing shall be performed. Since the retention use time requirements are long, extrapolation or acceleration is required to validate that the SSD meets the retention requirement.

В SSD нет никакого «начала диска».

Есть конечно, у него же есть LBA. Другое дело что это «начало диска» со временем меняет своё физическое расположение (точнее, расположения блоков, из которых оно состоит) в чипах флеш-памяти, но это уже другая история, и в контексте данной темы не важная.

Я посмотрел твой график: в «начале» диска просадка, явно, программная. Предполагаю, что контроллер что-то в фоне делал («перекладывал» данные в TLC из SLC-«кэша», например) - слишком стабильно и долго держалась «просадка». Или перегрев и тротлинг.

П.с. Что не отменяет факта существования заявленной тобой проблемы. Не удивлюсь, что btrfs/zfs scrub может косвенно заставить контроллер переложить инфу из медленных ячеек в свежетримленные.

П.п.с. Очень многие знают, что может страдать скорость ЗАПИСИ (если трим не работает), но про падение скорости ЧТЕНИЯ давно записанных данных не знает почти никто.

Нет смысла читать поблочно, так как на диске могут быть и тримнутые блоки.

Вот скрипт для подобных целей

Падение скорости чтения с ssd для файлов, записанных N месяцев назад (комментарий)

Я посмотрел твой график: в «начале» диска просадка, явно, программная –

там во первых два совершенно разных диска, один nvme и один ssd. во вторых я их на протяжении пары недель несколько раз прогонял в тесте с идентичной картиной. Низкая скорость чтения в начале диска это 100% старые файлы которые были на него записаны первыми. Если его затереть или записать что-то заново на всю емкость, он снова весь начнет читаться на полной скорости как новый. Будет просто ровная полоса чтения, как ты можешь увидеть в тестах этих дисков обзорщиками – потому что они их тестируют только распаковав. Это многократно проверено на разных SSD , ну вот я выше постил Raid10 на бытовых SSD (комментарий) или вот чел обновляет диск для восстановления скорости https://forum.ixbt.com/topic.cgi?id=4:142795 да таких ссылок миллион в пример могу найти.

Не удивлюсь, что btrfs/zfs scrub может косвенно заставить контроллер переложить инфу из медленных ячеек в свежетримленные. – не, не заставит. Если бы все было так просто, то и мои тесты линейного чтения заставляли бы его перекладывать данные, они делают то же самое что scrub. но они не меняют ничего

Покажи sudo nvme smart-log /dev/nvme? | grep percentage_used

Нет смысла читать поблочно, так как на диске могут быть и тримнутые блоки.

ТС, а что, если начало диска («просадка») - это чтение реальных данных, а остаток - это пустые/тримнутые ячейки (которые контроллер даже не пытается считывать из чипов, зная об этом). Что, если забить диск полностью, и сделать тест чтения? Причём, забивать надо плохо сжимаемыми данными (/dev/random, фильмы и т.п.), т.к. контроллер тоже не дурак - если видит нули (или просто хорошо сжимаемые данные), то он не пишет всё честно во флеш.

Смотри на atime файлов и читай те что давно не читались. man find

Вот диск на ноутбуке. Первая треть LBA «неактивна», потому что винду не загружал уже год.

$ fdisk -l /dev/nvme0n1
Disk /dev/nvme0n1: 931.51 GiB, 1000204886016 bytes, 1953525168 sectors
Disk model: WD Blue SN570 1TB                       
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: 4D1AD5F6-5D83-4B9E-BDED-6D6FE82B5B1A

Device              Start        End    Sectors   Size Type
/dev/nvme0n1p1       2048     206847     204800   100M EFI System
/dev/nvme0n1p2     206848     239615      32768    16M Microsoft reserved
/dev/nvme0n1p3     239616  694163425  693923810 330.9G Microsoft basic data
/dev/nvme0n1p4  694163456 1919969279 1225805824 584.5G Linux filesystem
/dev/nvme0n1p5 1919969280 1953523711   33554432    16G Linux swap

Активная файловая система заполнена на 80%:

$ df -lh /
Filesystem      Size  Used Avail Use% Mounted on
/dev/nvme0n1p4  575G  428G  118G  79% /

Не вижу провалов на «неактивных» LBA (я честно не удалял строчки с r<2000MiB/s, просто форум не позволяет запостить всю портянку):

$ fio --readonly --eta-newline=1 linear-read-job.ini
linear-read-job: (g=0): rw=read, bs=(R) 64.0KiB-64.0KiB, (W) 64.0KiB-64.0KiB, (T) 64.0KiB-64.0KiB, ioengine=libaio, iodepth=64
fio-3.35
Starting 1 process
Jobs: 1 (f=1): [R(1)][0.9%][r=3242MiB/s][r=51.9k IOPS][eta 05m:18s]
...
Jobs: 1 (f=1): [R(1)][10.3%][r=3013MiB/s][r=48.2k IOPS][eta 04m:31s]
...
Jobs: 1 (f=1): [R(1)][20.4%][r=3013MiB/s][r=48.2k IOPS][eta 04m:06s] 
...
Jobs: 1 (f=1): [R(1)][30.5%][r=3014MiB/s][r=48.2k IOPS][eta 03m:36s] 
...
Jobs: 1 (f=1): [R(1)][40.3%][r=3187MiB/s][r=51.0k IOPS][eta 03m:05s] 
...
Jobs: 1 (f=1): [R(1)][50.5%][r=3272MiB/s][r=52.4k IOPS][eta 02m:32s] 
...
Jobs: 1 (f=1): [R(1)][56.0%][r=812MiB/s][r=13.0k IOPS][eta 02m:16s]       !!!
...
Jobs: 1 (f=1): [R(1)][60.1%][r=3150MiB/s][r=50.4k IOPS][eta 02m:03s] 
...
Jobs: 1 (f=1): [R(1)][67.0%][r=411MiB/s][r=6570 IOPS][eta 01m:43s]        !!!
...
Jobs: 1 (f=1): [R(1)][68.0%][r=691MiB/s][r=11.1k IOPS][eta 01m:41s]       !!!
...
Jobs: 1 (f=1): [R(1)][70.5%][r=1018MiB/s][r=16.3k IOPS][eta 01m:34s]      !!!
Jobs: 1 (f=1): [R(1)][70.9%][r=1190MiB/s][r=19.0k IOPS][eta 01m:33s]      !!!
Jobs: 1 (f=1): [R(1)][71.1%][r=636MiB/s][r=10.2k IOPS][eta 01m:33s]       !!!
...
Jobs: 1 (f=1): [R(1)][75.2%][r=548MiB/s][r=8762 IOPS][eta 01m:21s]        !!!
...
Jobs: 1 (f=1): [R(1)][80.4%][r=3143MiB/s][r=50.3k IOPS][eta 01m:04s] 
...
Jobs: 1 (f=1): [R(1)][90.4%][r=3029MiB/s][r=48.5k IOPS][eta 00m:31s] 
...
Jobs: 1 (f=1): [R(1)][94.8%][r=619MiB/s][r=9910 IOPS][eta 00m:17s]        !!!
Jobs: 1 (f=1): [R(1)][95.4%][r=3213MiB/s][r=51.4k IOPS][eta 00m:15s] 
Jobs: 1 (f=1): [R(1)][95.7%][r=460MiB/s][r=7365 IOPS][eta 00m:14s]   
Jobs: 1 (f=1): [R(1)][95.7%][r=779MiB/s][r=12.5k IOPS][eta 00m:14s] 
Jobs: 1 (f=1): [R(1)][96.3%][r=3197MiB/s][r=51.2k IOPS][eta 00m:12s]
Jobs: 1 (f=1): [R(1)][96.9%][r=3274MiB/s][r=52.4k IOPS][eta 00m:10s] 
Jobs: 1 (f=1): [R(1)][97.3%][r=659MiB/s][r=10.5k IOPS][eta 00m:09s]  
Jobs: 1 (f=1): [R(1)][97.6%][r=2654MiB/s][r=42.5k IOPS][eta 00m:08s]
Jobs: 1 (f=1): [R(1)][98.2%][r=3240MiB/s][r=51.8k IOPS][eta 00m:06s] 
Jobs: 1 (f=1): [R(1)][98.5%][r=358MiB/s][r=5734 IOPS][eta 00m:05s]   
Jobs: 1 (f=1): [R(1)][98.5%][r=766MiB/s][r=12.3k IOPS][eta 00m:05s]  
Jobs: 1 (f=1): [R(1)][98.8%][r=1468MiB/s][r=23.5k IOPS][eta 00m:04s]
Jobs: 1 (f=1): [R(1)][99.1%][r=502MiB/s][r=8029 IOPS][eta 00m:03s]  
Jobs: 1 (f=1): [R(1)][99.1%][r=448MiB/s][r=7172 IOPS][eta 00m:03s]  
Jobs: 1 (f=1): [R(1)][99.7%][r=3260MiB/s][r=52.2k IOPS][eta 00m:01s] 
Jobs: 1 (f=1): [R(1)][100.0%][r=3272MiB/s][r=52.4k IOPS][eta 00m:00s]
linear-read-job: (groupid=0, jobs=1): err= 0: pid=264473: Thu Feb  6 11:46:51 2025
  read: IOPS=45.3k, BW=2834MiB/s (2972MB/s)(932GiB/336571msec)
    slat (nsec): min=1026, max=510584, avg=1371.35, stdev=865.77
    clat (usec): min=30, max=160663, avg=1409.77, stdev=1987.46
     lat (usec): min=31, max=160668, avg=1411.14, stdev=1987.64
    clat percentiles (usec):
     |  1.00th=[   529],  5.00th=[   840], 10.00th=[   955], 20.00th=[  1074],
     | 30.00th=[  1156], 40.00th=[  1237], 50.00th=[  1319], 60.00th=[  1319],
     | 70.00th=[  1336], 80.00th=[  1369], 90.00th=[  1614], 95.00th=[  1942],
     | 99.00th=[  5669], 99.50th=[  8586], 99.90th=[ 14222], 99.95th=[ 16581],
     | 99.99th=[116917]
   bw (  MiB/s): min=  122, max= 3331, per=100.00%, avg=2835.04, stdev=811.80, samples=672
   iops        : min= 1964, max=53302, avg=45360.67, stdev=12988.75, samples=672
  lat (usec)   : 50=0.01%, 100=0.01%, 250=0.19%, 500=0.65%, 750=2.15%
  lat (usec)   : 1000=9.94%
  lat (msec)   : 2=82.40%, 4=3.02%, 10=1.24%, 20=0.37%, 50=0.02%
  lat (msec)   : 100=0.01%, 250=0.02%
  cpu          : usr=3.51%, sys=10.27%, ctx=13818754, majf=0, minf=16
  IO depths    : 1=0.1%, 2=0.1%, 4=0.1%, 8=0.1%, 16=0.1%, 32=0.1%, >=64=100.0%
     submit    : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
     complete  : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.1%, >=64=0.0%
     issued rwts: total=15261915,0,0,0 short=0,0,0,0 dropped=0,0,0,0
     latency   : target=0, window=0, percentile=100.00%, depth=64

Run status group 0 (all jobs):
   READ: bw=2834MiB/s (2972MB/s), 2834MiB/s-2834MiB/s (2972MB/s-2972MB/s), io=932GiB (1000GB), run=336571-336571msec

Disk stats (read/write):
  nvme0n1: ios=15252997/1453, merge=0/906, ticks=21483322/586, in_queue=21484195, util=100.00%

Самая нестабильная латентность в конце LBA, где должны быть свежие блоки от файловой системы и свопа.

Первая треть LBA «неактивна», потому что винду не загружал уже год.

Тоже есть похожий ноутбук, в котором оффтоп вначале lba, и не используется более года.

Есть сильные просадки в блоках, где записан оффтоп.

так чтение не помогает, нужно их именно перезаписывать чтобы восстановить читаемость

Да, точно. Перезаписывать т.е. скопировать куда-то в tmpfs(если влезет) и обратно

На даче дешманский ssd держит годами раздел с 98 виндой. Летом приезжаешь, чекдиск проходишь, но система с данными в целом живые)

скопировать куда-то в tmpfs

и выключить :)

Не, если есть задача сохранять скорость - можно тогда и HDD взять. А в остальном - ну, упадёт скорость чтения, ну, подождёшь немного.

файлы могут быть гораздо больше чем размер tmpfs , не говоря уже о том что такое пофайловое копирование не поможет если часть файла протухла а часть нет (например, для какого то большого древнего лога или образа ВМ который дописывается в конец)

тут нужно решение которое именно посекторно читает ssd и если скорость ниже порога записывает содержимое того же сектора обратноо, как делают виндовые freshdisk и прочие, которыми восстанавливают скорости читаемости SSD до изначальных. И периодически запускать его в фоне, как и fstrim . badblocks не подходит, поскольку он паттерны пишет, делался еще для FDD где надо было поверхность проверять, тут все равно контролер скорее всего в новую область сектор запишет и проверять паттернами просто трата ресурса диска

очень странно что ничего подобного готового еще нет.

ну там по ссылкам выше видно что за год-два падает вплоть до 1 мбайт в секунду, если обьем данных большой это фактически означает его потерю, копировать будешь неделями.

да это норма. странно что так много людей уверены что SSD что-то там сам проверяет и перезаписывает в фоне и следит за скоростью протухания флеша, обычные консьюмерские ничего подобного не делают. Об этом узнаешь только при копировании старых данных

Ну, мне трудно представить хранилище, к которому не обращались год-два. Но, если так надо, в самом деле, наверное, лучше взять HDD.

так речь не про обращение, а про запись. странно представить хранилище с данными за 1-2 года что ли ? это наоборот вполне обычный сценарий даже флешки в ноутбуке с локальной файлопомойкой, не то что какого то nas.

Проблема в не обращении, а в том что обращение не «освежает» прочитанный блок.

Из man dd_rescue

dd_rescue −A −d −D −b 512 /dev/sda /dev/sda

reads the contents of every sector of disk sda and writes it back to the same location. 

Но скорость чтения не контролируется. fr закинуть…

Не замечал практического эффекта. Т.е. доставал SSD с фряхой через год - всё прекрасно грузилось и быстро работало.

Не «не обращались», а не записывали файлы. Если вы с этим не сталкивались, значит повезло. Подождать там приходится не немного, если скорость чтения 5-15 Мбайт/с, то это труба. После сбоя питания RAID начинает resync, если битмапа нет, то это означет просто копирование одного диска на другой, сотни гигабайт с вышеуказаной скоростью...

2ТС, ни в RAID, ни в ядре ничего подобного нет. Насколько я знаю, в RAID даже не пропуска блоков, заполненых нулями при DRAT (Deterministic Read After Trim) и ZRAT (Zero Return After Trim). ТО есть resync RAID приведёт к тому, что trim'нутые блоки будут записаны нулями. Если SSD такое не понимает, то на RAID разделе все блоки буду занятыми, следовательно, на бытовых SSD нельзя делать RAID на весь объём, нужно оставлять часть неразмеченым.

По идее, на отмонтированом разобраном raid должно хватать и user-space утилиты, но я таких не знаю. Чтобы и скорость чтения изменяла и блоки, заполненые нулями (тримнутые) игнорировала.

А проблема глубже, так как не понятно, через сколько времени на такой памяти медленое чтение превращается в ошибку чтения. То есть через сколько лет на накопителе перестанут читаться таблица разделов, суперблок ФС и прочие не перезаписываемые при нормальной эксплуатации блоки.

Мне кажется, проблема несколько надуманна. SSD широко применяются уже 10 лет, в том числе в виде флешек и прочего холодного хранилища. В противном случае, весь интернет бы трубил «Нам втюхивают г..о! Покупайте HDD, пока можете! SSD не дают никакого выигрыша в скорости!»

Вообще, активная запись файлов - редкий сценарий для консьюмерских винчестеров.

У badblocks есть режим неразрушающего write-теста, там как раз сначла читается, потом записывается. Но, изменения скорости нет.

Плосю, как fstrim, скорее всего не получится. fstrim — просто вызов в ядро, а здесь нужно считать, записать, а если в этот момент система что-то будет в этот блок писать? На знаю, можно ли как-то на уровне системных вызовов блокировать другим запись на блочное устройство.

так он и трубит, я выше уйму ссылок привел и замерил собственные диски, там падение скорости 10 кратное на графиках (на самом деле даже более чем 10 кратное, если ориентироваться на инфу о минимальной скорости чтения, некоторые блоки в 20 раз медленее максимальной скорости чтения но их мало и не видно на общем графике)

просто обычный юзер не сидит и не запускает linear read на весь диск

Это кажется, пока не купите такой SSD. Надуманости нет, вспомните, в каком году был Samsung 840, https://www.overclock.net/threads/samsung-840-evo-read-speed-drops-on-old-wri... Как раз 10+ лет назад :) Просто у «нормальных» SSD на уровне прошивки реализована перезапись медленых блоков, проблема памяти спрятана под капот. Но если в прошивке бага или просто не стали подобный функционал реализовывать, то будет как описывал ТС.

Если внимательно читать отзывы, то по ряду SSD примрно такое и пишут, что винда через полгода начала тормозить, BSOD'ы, «SSD-г..о, купил другой». Но, память у всех разная, «утекает» разной скоростью, где-то полгода надо, чтобы заметить, а где-то 2-3 года. А 2-3 года мало какая винда живёт, переустановка или upgrade железа, это ещё маскирует данную проблему.

Ну, а по флешка и sd-карточкам, дак уже норма, что через несколько лет ничего не прочитается. Просто об это будет написано не в обзорах, на форме, в темах «Внезапно умерла карточка».

ну да, вот это аналог diskfresh под оффтопиком. но это расходование ресурса диска переписывать его целиком каждый раз, вот у меня на графике выше использования 2тб nvme в рабочем ПК только 20% диска сильно просели за год, остальные данные создаются-удаляются и не успевают настолько устареть, переписывать диск целиком чудовищно неразумно, такое разве что для бакапов на полке подходит раз в год подключить диск и прогнать этой командой обновление всех ячеек

Обычный юзер дисяточку поставил 9 лет тому назад - и большинство системных файлов с тех пор не обновлялось. Он бы заметил, если бы любые проги, использующие user.dll, начали бы по минуте стартовать на ровном месте.

так он и заметит и просто винду переустановит , решив проблему. это типа дефолт что пк под оффтопиком начинает со временем тормозить и его перезаливают