Comments 58
Мне приносят ссдшки и флешки всех брендов, то есть всё ломается, и скоррелеровать какой-то индекс от количества принесённых ко мне трупов, относительно проданных устройств… будет величина в попугаях.
Моё личное мнение, если по простому, то Intel и Samsung, но это про микросхемы памяти, а контроллеры производители накопителей используют совсем разные и алгоритмы равномерного износа соответственно разные. По контроллерам мне можно высказаться только с точки зрения с каких проще делать восстановление данных. Так что мне лучше воздержаться от развешивания ярлыков «хороший» — «плохой».
немного не понятно, Intel и Samsung приносят на восстановление больше или более надежные?
Смотреть обзоры с фотками в разобранном виде. Обычно они ставят хорошую память
Личная статистика, может не соответствовать реальному положению вещей)
Цель: хранить/писать в своих проектах информацию так, чтобы минимизировать выход флешек из строя. Сейчас, например, в одном проекте использую один большой файл, записи фиксированной длины, несколько тысяч/десятков тысяч записей по 256 байт в сутки — вроде бы весьма щадящие условия, но флешки выходят из строя часто.
Чтобы было понятно: одновременно под такой/примерно такой нагрузкой у нас работает сотня-другая флешек USB/MicroSD, всё это много лет как.
Самые частые симптомы:
1. запись вроде как происходит нормально, но на самом деле ничего не пишется (обнаруживается обычно когда после перезагрузки изменения оказываются потерянными);
2. чтение некоторых областей даёт нестабильный результат (два раза подряд запущенный md5sum даёт разные результаты);
3. флешка просто перестаёт определяться как блочное устройство.
Статистику не собирал, но субъективно usb и microsd ведут себя одинаково.
P.S. а вообще есть у меня большие сомнения, что (во всяком случае у меня) дело только в износе NAND. BTW, давным давно покупали партию SLC флешек — они ломались так же.
Да и читал опыт коллег, которые используют read-only флешки (с raspberry pi, например) — частота выхода флешек из строя снижается, но остаётся совсем ненулевой.
P.P.S. выработал такую методику проверки:
1. заполняем флешку данными с известной контрольной суммой, в linux
dd if=/dev/urandom bs=1M count=РАЗМЕР iflag=fullblock | tee /dev/sdf | md5sum
2. вынимаем флешку и вставляем обратно
3. сверяем контрольную сумму с контрольной
md5sum /dev/sdf
4. заполняем нулями (надеясь, что контроллер флешки обработает это TRIM)
dd if=/dev/zero of=/dev/sdf bs=4k
5. для очистки совести проверяю, что с флешки читают нули
hd /dev/sdf
(если предыдущая проверка прошла успешно, то на мой памяти и тут сбоев не было)
Так вот, не так уж редко новая флешка из магазина не проходит подобный тест.
На самом деле, однократное прохождение теста ещё ничего не гарантирует, несколько раз встречал ситуацию, когда новая флешка ломается на втором или третьем повторе шагов 1-3.
Износом занимается контроллер сам, как говорится аппаратно. Как бы вы не писали код, данные контроллер будет писать так как его прошли. Может в сети и есть инфа об этих алгоритма, вы всё равно ничего не сможете изменить. Только если будете сами писать напрямую в нанд. А это опять железо, новый велосипед.
Прошу прощения за ошибки, пишу с мобилки в метро…
Что же до прямого доступа к памяти — да, пришли к этому, только у NAND слишком много ног, тут оказалось достаточно восьминогих NOR на несколько мегабайт.
По ним пока статистики нет, но вот буквально в конце прошлого года пришлось поменять такую микросхему в домашнем компютере, так что и они умеют ломаться, увы.
А при подключении к компу этот девайс определялся бы как 2 диска: первый — это наш RAID-массив из двух карточек, а второй — это маленький служебный диск с лежащей на нём portable утилитой для управления RAID'ом, инструкцией, а также ярлыком-ссылкой на сайт производителя с подробной инструкцией и прочей инфой.
Кому нужна надёжность — просто купят industrial usb drive и получат гораздо большую надёжность, чем у рэйда из дешманских карточек.
А кому не нужна, те и не будут покупать такую штуку.
Осветить эту ситуацию в рекламе — и девайсы будут брать.
Мне кажется, лучшее решение проблемы надежности USB-флешек (или иных портативных носителей) — это не хранить важные данные на флешке, не использовать флешку в качестве постоянного хранилища. Чтобы не быть "заплаканной студенткой, у которой пропала курсовая" — хранить на жестком диске, с бэкапами и облаком. Я отношусь к флешкам как к расходному материалу, правда больше потому что рассеянный и теряю.
Я отношусь к флешкам как к расходному материалу
Блин, вот я совсем не рассеянный, (за время учебы у меня была одна единственная флешка на 4 Гб, которую я не потерял и не сломал), но вот ни разу в голову не приходило что-то хранить на ней важное в единственном экземпляре. Да будь эта флешка с рейдом и с защитой от восстановления, ну и что, я МОГУ ее потерять, я МОГУ ее сломать, её МОГУТ украсть (у одногруппников флешки пропадали оставленные на парте в аудиотории во время перерыва).
Общее правило не то что не хранить важные данные на флешке, а не хранить «в одной корзине», что вы собственно и упомянули про бекапы и облако.
Я не доверяю зеркалам. Если умрут, то как правило оба девайса. И программная беда если произойдёт, то отзеркалируется на оба. Банальное копирование на два разных устройства, вот лучшая резервка.
Если студент осознаёт проблемы надёжности, чтобы задуматься о покупке такого устройства, 2 обычных копеечных флешки ему не сложно будет использовать.
Не говорю, что это разумно или конкурентоспособно. Просто можно сделать и так :)
Я бы купил (по цене ~2,5 флешек).
Ну и с синхронизацией интересно. В фоне-то синхронизирует, а если устройство вытащили из порта, сразу после записи, и синхронизироваться не успело? Батарейку добавить на этот случай?
В данной статье понятно, что флешка была забита под 0. А если бы утилизировалось из 32 только 20, прослужила бы она дольше?
Странно, что с увеличением размера не растет надежностьРастёт плотность записи. Первые flash-ячейки (SLC) хранили 1 бит, далее появились MLC, TLC, и вот уже QLC на подходе. Всё-таки, одно дело — есть заряд или нет, другое дело — точно дозировать заряд, чтобы безошибочно различать любой из 16 уровней.
Другая проблема — миниатюризация. Чем меньше ячейка, тем меньше в ней может храниться заряд при том же напряжении. Меньше заряд — сложнее защитить от утечек.
Качество современных чипов памяти весьма печальное, и несмотря на громогласные заявления производителей о том, что вот мы сделали огромное количество циклов записи… статистика показывает обратное. Износ происходит очень быстро, по сравнению с флешками которые измерялись мегабайтами.
Флешка — это ещё не так страшно, гораздо хуже — это отказ SSD!
флешка умирала и «сигнализировала» об этом косвенным путёмА я думал что это из за вынимания флешки на горячую, без отключения.
Одна флешка постоянно просит сделать проверку, вероятно пора её заменить…
Да конечно шансы есть. Просто доступ к микросхем памяти сложней. Посмотрите как мы восстанавливаем данные с монолитов https://habr.com/company/datalabs/blog/220667/
То есть вроде того, что увеличить объём заложенного производителем резервного пространства.
Здравая мысль, но упрямство: "Не хочу делать резервные копии" умиляет
Вопрос о том, чтобы минимизировать вероятность и максимально отсрочить необходимости внезапно заниматься переустановкой и восстановлением с бэкапа.
Резервом неиспользуемой области можно улучшить производительность записи и уменьшение износа при записи. Это обязательно сработает, если ОС не умеет использовать TRIM (т.к. в этом случае независимо от того, сколько свободно места на FS, контроллер считает весь диск занятым).
А если ОС современная и использует TRIM, то без разницы — свободные сектора на неразмеченном разделе, или на рабочем, помеченные как свободные. Просто во втором случае при необходимости можно занять место, пожертвовав гипотетической скоростью записи и ресурсом (а потом освободить), а в первом случае резерв уже железный, невозможно его случайно скушать.
На моих SSD самая разная статистика Host/Nand Writes (TB):
10/17, 3/38 и 73/60
Я думаю, Host<Nand — фоновое выравнивание износа, Host>Nand — несколько команд подряд на запись в один сектор, которые оптимизировались в одну физическую запись.
p.s. видимо, вы обратили внимание на неточность
ресурс всё равно меряется количеством host writesКонечно, тут должно быть nand writes
Нам же пришлось вычитывать битые сектора, многократным чтением, какие-то из них удалось прочитать или восстановить из ECC.
Судя по вот этому, с read-only там было не всё так просто.
Недавно одна флешка, которой пользовался много лет, стала read-only. На первый взгляд вроде читалась,
но в части файлов был мусор. Ещё и операционная система на чтении такого добра любит подвисать.
Так что не стал бы делать однозначные выводы.
А на «стол» pc3000 для монолитов смотрю денег не хватило? Проводочки…
Прежде чем считать наши деньги, удосужились бы посмотреть что статья про монолиты от апреля 2014 года, а столик для монолитов начал продаваться в марте 2017 года!!!
6 января 2019 в 09:37
Посмотрел заголовок. Наверное стар стал 2014 от 2019 ну ни как отличить не могу…
За минус спасибо. Это так же показывает что я на 100% точно оценил Вас.
еще телефон разбит и разломан, лежат потроха его в пакете, думаю как бы данные из памяти достать)
на счет «спаяем микросхему» — хочется больше подробностей.
А с телефонами проще, там стоит микросхема, к которой можно припаяться как к SD карте, и считать образ, дальше развернуть под линухами или любым софтом под Windows, который умеет работать с ext файловыми структурами (если аппарат android, если яблоко, то в топку, там шифрование)
Восстановление данных из пустого места