LINUX.ORG.RU
Форум — Linux-hardware  

SSD изнашиваются от чтения?

 , ,


1

5

Привет, ЛОР:) Есть мнение, что при чтении со временем падает заряд ячейки и контроллер её перезаписывает.

Ваши мысли или пруфы?

В день читается 500Тб с разных позиций на диске, какие-то наверняка читаются несколько раз. В таком режиме 3 месяца - полет нормальный. Записи нет вообще, только один раз при покупке нового диска.

Ширпотребный диск на 500 Гб.

Оффтор. Ещё говорят SSD надо подзаряжать раз в 3 месяца. За 2 года бездействия ничего не пропало :)

Важное дополнение: файловой системы нет, блоки читаются напрямую с диска, соответственно noatime и т.п. неактуальны. Определенная программа только 1 раз записывает нужный объем информации (около 100 Гб) и далее только читает на максимальной скорости. Больше никакой записи нет!

Перемещено hobbit из general



Последнее исправление: NotWin (всего исправлений: 2)

 ← 1 2 →

Ещё говорят SSD надо подзаряжать раз в 3 месяца. За 2 года бездействия ничего не пропало :)

а ты что не знал?? беги быстрее подключай его к разетке напрямую пока данные не разрядились доконца.

antech ☆
()

проясните плиз ситацию: в ссд каждый блок/ячейка/чтото еще маркируется временем записи ?? как это время определяется если в ссд нет энергонезависимого таймера ?? и ваапче ??

pfg ★★★★★
()

какие-то наверняка читаются несколько раз. В таком режиме 3 месяца - полет нормальный

Упоминают, что read disturb проявляется после 100 тысяч чтений для первых поколений MLC NAND, причём эти числа постепенно снижаются по мере уменьшения размеров ячеек. В статье 2015 года упоминается, что у некоторых свежих на тот момент видов флеш памяти уже 20 тысяч чтений приводят к проблемам. Тебе до этих значений ещё далеко.

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

Ещё говорят SSD надо подзаряжать раз в 3 месяца. За 2 года бездействия ничего не пропало :)

Если перечитаешь внимательно, заметишь, что речь там идёт про вхлам ушатанные накопители. Те, у которых число перезаписей подходит к лимиту. Не помню, чтобы кто-то опровергал конкретно вот это. Возможно, ты будешь первым.

i-rinat ★★★★★
()
Ответ на: комментарий от QsUPt7S

я о таком выражении «Ещё говорят SSD надо подзаряжать раз в 3 месяца.» и кучу подобных слышал. выражение конечно весьма далекое от прикладного применения, но все же….
единственное место, которое надо «подзаряжать» в SSD это плавающий затор. просто так взять и весь объем SSD «перезарядить» какбы бесмысленно (большинство блоков может быть и пустыми) и отрицательно скажется на жизни ячейки.
и т.д. и т.п. разъясните сию тонкую технологию или скажите что перезарядка ssd - туфта и все такое.

pfg ★★★★★
()

Насчёт SSD как продукта не знаю, а вот для голого nand read disturbance существует. Но эффект проявляется очень долго и с довольно нихкой вероятностью.

Для SLC прикидывали сколько проживёт страница если её читать раз в минуту - получалось что-то около трёх лет если мне память не изменяет. Для (M|L|Q|etc)LC - соответственно меньше, но там ECC есть и сколько-то флипнувшихся битов можно восстановить.

Короче, тебя это врядли коснётся.

А вот эти вот «заряжать ssd» - херня полная учи физику.

Dark_SavanT ★★★★★
()
Последнее исправление: Dark_SavanT (всего исправлений: 1)

С недавних пор самому интересен вопрос продолжительности жизни SSD, вот что накопал:

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

Dr64h ★★
()
Ответ на: комментарий от urxvt

если у тебя не смонтировано с noatime

Думаю, что почти везде уже по умолчанию используется опция relatime, с которой atime записывается далеко не каждый раз. Если вообще ничего никогда не записывать в файлы, то atime непосредственно на накопитель будет записываться только раз в сутки.

i-rinat ★★★★★
()

Моему SSD уже десятый год пошёл.

SMART Attributes Data Structure revision number: 10
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  1 Raw_Read_Error_Rate     0x000f   120   120   050    Pre-fail  Always       -       0/0
  5 Retired_Block_Count     0x0033   100   100   003    Pre-fail  Always       -       0
  9 Power_On_Hours_and_Msec 0x0032   043   043   000    Old_age   Always       -       50753h+48m+02.410s
 12 Power_Cycle_Count       0x0032   094   094   000    Old_age   Always       -       6980
171 Program_Fail_Count      0x0032   000   000   000    Old_age   Always       -       0
172 Erase_Fail_Count        0x0032   000   000   000    Old_age   Always       -       0
174 Unexpect_Power_Loss_Ct  0x0030   000   000   000    Old_age   Offline      -       2973
177 Wear_Range_Delta        0x0000   000   000   000    Old_age   Offline      -       2
181 Program_Fail_Count      0x0032   000   000   000    Old_age   Always       -       0
182 Erase_Fail_Count        0x0032   000   000   000    Old_age   Always       -       0
187 Reported_Uncorrect      0x0032   000   000   000    Old_age   Always       -       2797
194 Temperature_Celsius     0x0022   030   030   000    Old_age   Always       -       30 (Min/Max 30/30)
195 ECC_Uncorr_Error_Count  0x001c   100   100   000    Old_age   Offline      -       0/0
196 Reallocated_Event_Count 0x0033   100   100   003    Pre-fail  Always       -       0
201 Unc_Soft_Read_Err_Rate  0x001c   100   100   000    Old_age   Offline      -       0/0
204 Soft_ECC_Correct_Rate   0x001c   100   100   000    Old_age   Offline      -       0/0
230 Life_Curve_Status       0x0013   100   100   000    Pre-fail  Always       -       100
231 SSD_Life_Left           0x0013   094   094   010    Pre-fail  Always       -       0
233 SandForce_Internal      0x0000   000   000   000    Old_age   Offline      -       55843
234 SandForce_Internal      0x0032   000   000   000    Old_age   Always       -       55799
241 Lifetime_Writes_GiB     0x0032   000   000   000    Old_age   Always       -       55799
242 Lifetime_Reads_GiB      0x0032   000   000   000    Old_age   Always       -       32696
unixnik ★★★★★
()

и контроллер её перезаписывает.

Контроллер просто перезаписывае плохо читающиеся ячейки. Здесь тестируют по скорости чтения блоков старых файлов: https://www.overclock.net/threads/read-speeds-dropping-dramatically-on-older-...

За 2 года бездействия ничего не пропало :)

Чем считали и где хранили контрольные суммы?

Общее правило не забивать полностью, собирать gentoo в tmpfs.

mky ★★★★★
()
Ответ на: комментарий от pfg

«Подзарядка» flash-памяти не совсем ерунда. Заряд из плавающего затвора со временем утекает. На новых носителях это практически незаметно - информация без потерь может храниться десятилетиями, но, при износе слоя диэлектрика плавающего затвора, время утечки заряда уменьшается. Контроллеры отслеживают этот процесс, в случае необходимости перенося данные. Определение необходимости переноса данных, сильно зависит от прошивки контроллера, и может отличаться на разных версиях прошивки одного и того же устройства. Обычно, контроллеры определяют страницы, для которых необходимо выполнить перенос, во время обращения к этим страницам, хотя и могут самостоятельно сканировать набор живых данных, с целью выявления таких страниц.

Кроме обновления данных, контроллер в фоне может выполнять много дополнительной работы. К примеру, для консьюмерских устройств с «SLC-кешированием» характерно переносить данные из кеша в долговременную память именно в фоне. Большинство контроллеров флешек, для увеличения наблюдаемой пользователем пользователем производительности, тоже переносят довольно большую часть своей работы в фон. Если не давать контроллеру периоды бездействия с подключенным питанием, объём необходимой работы со временем накапливается, приводя к необходимости выполнения работы уже не в фоновом режиме. В таких случаях пользователь наблюдает замедление работы накопителя.

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

QsUPt7S ★
()
Ответ на: комментарий от pfg

При чтении контроллер прогоняет прочитанное через алгоритмы поиска и коррекции ошибок прежде чем отдать страницу системе.

Если всё ок – ничего больше со страницей он не делает.

А вот если не ок, контроллер восстанавливает данные как может и отправляет блок в очередь на запись.

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

timdorohin ★★★★
()
Ответ на: комментарий от pfg

Мне atime понадобился на практике один единственный раз, оказалось что mutt определяет наличие новой почты по изменению atime то ли файла ящика, то ли чего то ещё. Это было очень давно. Реально интересно, есть ли сейчас софт которому atime важен?

Jameson ★★★★★
()
Ответ на: комментарий от azsx

Чтение небольших блоков с рандомных позиций на максимальной скорости:) Серп копаю потихоньку.

noatime неактуален, т.к. нет файловой системы, чтение напрямую с диска.

Волнует массовый отказ SSD, если ставить ферму. Пока самых дешёвых на 128 Гб достаточно, а больше 256 Гб покупать в ближайшие 2 года нет смысла. Обычно на недорогих моделях память и контроллеры похуже ресурсом. Но у меня побольше диск стоит, пустой :)

NotWin
() автор топика
Ответ на: комментарий от timdorohin

ок, так и думал. удивился предположению что есть проверки имеено по времени записанного.
предположу что такая проверка запускается фоном после каждого пропадания питания ??

pfg ★★★★★
()
Ответ на: комментарий от Jameson

А фиче меж тем десять лет и она «по умолчанию» используется. То есть достаточно просто «не умничать» и ничего в fstab на тему atime не писать...

А как же тогда работают программы, которые от этого самого atime завися? Или таких уже не осталось?

urxvt ★★★★★
()
Ответ на: комментарий от urxvt

Так эта... man mount

...
relatime
           Update inode access times relative to modify or change
           time. Access time is only updated if the previous
           access time was earlier than the current modify or
           change time.
           (Similar to noatime, but it doesn’t break mutt(1) or
           other applications that need to know if a file has been
           read since the last time it was modified.)

           Since Linux 2.6.30, the kernel defaults to the behavior
           provided by this option (unless noatime was specified),
           and the strictatime option is required to obtain
           traditional semantics. In addition, since Linux 2.6.30,
           the file’s last access time is always updated if it is
           more than 1 day old.
...

Другое дело что я чот не вспомню ничего кроме mutt что этот механизм юзало бы. Но «в крации» мораль такова: не умничай! Не пиши noatime, не пиши relatime, вообще забей и ничего не пиши. И будет relatime, который аналогичен noatime, но не сломает то гипотетичское чему может понадобиться atime.

Jameson ★★★★★
()
Последнее исправление: Jameson (всего исправлений: 1)
Ответ на: комментарий от Jameson

Дополнил топ следующим:

Важное дополнение: файловой системы нет, блоки читаются напрямую с диска, соответственно noatime и т.п. неактуальны. Определенная программа только 1 раз записывает нужный объем информации (около 100 Гб) и далее только читает на максимальной скорости. Больше никакой записи нет!

NotWin
() автор топика
Ответ на: комментарий от NotWin

Я думаю ты не найдёшь однозначного ответа на свой вопрос. Потому что какую там магию делает контроллер когда массив ячеек обслуживает и чем эта магия различается в разных моделях разной ценовой категории ведомо только разработчикам фирмвари. Тут таких нет, да и под NDA это всё обычно. Кухонные обсуждения на уровне «общей эрудиции» не имеют ни смысла, ни пользы. Предлагаю просто не париться на эту тему и собирать свою собственную статистику отказов.

Jameson ★★★★★
()
Последнее исправление: Jameson (всего исправлений: 1)

изучайте

https://www.microsoft.com/en-us/research/wp-content/uploads/2016/08/a7-narayanan.pdf

или тут простенько на пальцах, но с полезными ссылками о причинах и на что надо обращать внимание https://www.techtarget.com/searchstorage/tip/4-causes-of-SSD-failure-and-how-to-deal-with-them

vaddd ★☆
()
Последнее исправление: vaddd (всего исправлений: 1)
Ответ на: комментарий от pfg

ваш флеш - по сути всего лишь разновидность конденсатора, со всеми отсюда => далее время жизни заряда в нём определяется лишь добротностью затвора=>тока утечки через него

mumpster ★★★★★
()
Ответ на: комментарий от NotWin

просто давай время простоя - там контроллер сам справится (обычно) если долго хранишь (годами) и критично - переписывай по новой блоками периодически сам

mumpster ★★★★★
()
Ответ на: комментарий от NotWin

У меня у сатовского ссд износ 0% при 14 ТБ записи (plextor 240GiB), а у Samsung 980 500G - 5% пр записи 19 ТБ, так что логика мне подсказывает, что запись на высоких скоростях быстрее расходует ресурс, банально чипы больше греются, а чем выше температура, тем быстрее электроны движутся

uwuwuu
()
Ответ на: комментарий от mumpster

теорию флеш-накопителей и чем они отличаются от конденсатора я знаю давно - в гараже до сих пор УФ-стираемые ППЗУ пачками валяются :)
вопрос был лишь в том как определять что зарядке блока приходит звездец и его надо перезаписывать. ответ про коды Хемминга и восстановления единичной ошибки меня вполне удовлетворил.

pfg ★★★★★
()

Вы все зря мастурбируете на показатель износа в виде срока службы или объема записи - он малоинформативен. CCД в большинстве своем дохнут не из-за объема-времени. а из-за внезапного отказа или роста дефектов. Происходит это в весьма малой зависимости от общего износа Выше ссылки на исследования.

vaddd ★☆
()
Ответ на: комментарий от vaddd

объём и время увеличивают вероятность, это же очевидно (в силу используемой технологии)

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

mumpster ★★★★★
()
 ← 1 2 →
Linux-hardware