LINUX.ORG.RU

Как точно определить, сдохла ли флешка?

 ,


0

2

Флешка JetFlash Transcend 32GB (1100).
В gparted сделал удалить раздел (был один раздел). Создать раздел ext3.
Что-то записал но упал с ошибкой, и с тех пор говорит что устройство read only.
Кроме gparted так говорят dd, fdisk и disks.
В инете нарыл сделать hdparm, выдает:

SG_IO: bad/missing sense data, sb[]:  70 00 05 00 00 00 00 0a 00 00 00 00 20 00 00 00 bf 1b 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 multcount     =  0 (off)
 readonly      =  1 (on)
 readahead     = 256 (on)
 geometry      = 29800/64/32, sectors = 61030400, start = 0

Сделал hdparm -r0 /dev/sdc
Флаг read only убирается, но это ничего не дает. При перевтыкании флаг снова установлен.
В инете пишут, что это значит что флешка сдохла, контроллер перешел в режим read only.
А вот как узнать точно, так это или что-то другое? Он, когда в ридонли переходит, выставляет это как-то в данных устройства?
Или тут что-то другое может быть? Как тогда починить флешку?


А вот как узнать точно, так это или что-то другое?

Т.е. то, что при попытке записи на устройство оно переходит в режим чтения тебе не достаточно?

Маловероятно, но ещё может выйти из строя какой-либо радио элемент на плате устройства.

Ещё можешь поискать сервисные утилиты, определить тип контроллера, через сервисные утилиты запустить процедуру переразметки и тестирования флеш памяти, но утилиты только под windows.

Так что думаю проще и быстрее купить новую флешку.

kostik87 ★★★★★
()

бесполезный ответ:

Раньше (лет 15 назад) под винду были утилиты для низкоуровненвой работы с контроллерами флешек. Сайт, к сожалению, потерял. И для линукса такого не видел

upd. гугл подсказывает https://www.usbdev.ru/ . вроде похож, но не уверен. на свой страх и риск

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

Узнать вид и пид. Скачать и запустить программу восстановления для этих вид и пид (под виндой!). Через несколько секунд контроллер перепрошьется и всё будет в шоколаде или не будет, если проблема в другом. Мне несколько раз помогало спасти накопитель.

anonymous
()

В данных устройства выставляется usb-флаг write protect, и об это написано в dmesg. Можете через usb quirks включить игнорирование этого флага для этого устройства, но лучше пойти купить новую флешку, а уже потом трать время на эту.

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

Можете через usb quirks включить игнорирование этого флага для этого устройства

О, спасибо, нашел в инете как это делается.
Действительно, запись начала работать.

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

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

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

Т.е. то, что при попытке записи на устройство оно переходит в режим чтения тебе не достаточно?

Да, недостаточно. Было бы лучше, если бы оно выставляло какой-нибудь специальный флаг, типа «да, кончился ресурс записи, именно так, сэр». Это было бы логично. Тогда программы записи на флешку могли бы четко говорить, что закончился ресурс записи, а не выдавать невнятную фигню, и потом бегай по форумам, чтобы понять шозанах.

snajl
() автор топика

Да, а для флешек используются те же файловые системы, что и для жестких дисков? То есть там обычно данные о файловой системе в первых секторах, которые переписывабтся по 100500 раз, в то время как все остальные сектора трогаются редко. И никакого способа сделать так, чтобы служебные данные можно было переместить в другую часть флешки и чтобы оно продолжало работать, если часть памяти исчерпает ресурс записи? Или там один ресурс записи на всю флешку?

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

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

Ну а то, то у тебя не флешка на SD карта - надо было сразу написать в теме.

Иди в магазин за новой.

kostik87 ★★★★★
()

Флешка точно сдохла, а данные с нее надо спасать так:

# dd if=/dev/флешка of=flash_drive.img conv=fsync conv=noerror status=progress
# mkdir -p /mnt/flash_drive_img
# mount -o loop flash_drive.img /mnt/flash_drive_img

Далее спасаем файлы, а затем покупаем новую флешку.

anonymous
()
Ответ на: комментарий от kostik87

Ну а то, то у тебя не флешка на SD карта - надо было сразу написать в теме.

Так, нет, стоп.
На самом деле я, ламер, подумал, что речь идет об обозначении типа SCSI что-то там, из-за чего оно в линуксе называется по типу sda, sdb и т.д. Это я что-то протупил.

Не в том смысле, что это SD карта. Я не знаю, SD карта это или нет. Выглядит как флешка, которую втыкают в USB. Название я написал.

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

Флеш память устроена сложно, там нельзя просто взять и перезаписать маленький блок (512 байт), там нужно сначала стереть большой блок (подготовить), а потом уже туда писать понемногу. И контроллер в любой флешке, sd карточке и пр. занимается переназначением адресов при чтении-записи. Насколько у него качественный алгоритм вравниния износа другой вопрос, но в любом случае, если всё время писать в сектор номер 1, данные будут записываться по разным адресам флеш-памяти и стремиться равномерно износить всю флешку.

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

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

mky ★★★★★
()

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

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

в ридонли переходит когда исчерпывается ресурс свободных блоков. которые подставляются взамен нечитаемых. которые появляются в процессе хранения данных естественным образом (background media scan с рефрешем утекающего заряда на sd/usb флешах в большинстве своем в принципе нет). которые выявляются в процессе записи данных…

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

В идеальном мире со сферическими поняшами и безглючными прошивками так есть. А в реальности переход в RO — это просто битик в памяти прошивки. Откуда он там появляется точно не скажешь, логов нет. Может глюк прошивки, может мутация бита под воздействием случайно залетевшей тяжёлой заряженной частицы, может, действительно, резервные блоки закончились. Но, с одной стороны, многим помогало игнорирование write protect или перепрошивка контроллера. С другой стороны, многие изношеные флешки/карточки спокойно портят данные, но не переходят в RO, считая что у них всё в порядке или забывают кто они (размер, и т.д.), теряют всё, но в RO не переходят.

И я не помню, в каком-то стандарте написано, что при отсутствии резервных блоков контроллер должен переходить в RO? Каждая строчка кода прошивки должна быть чем-то обоснована...

с рефрешем утекающего заряда

С утекающим зарядом вобще не понятно. В телефоне одна SD-карточка отработала несколько лет, кончилась, ФС «разбилась». По идее, вот он, изношеный флеш. Записал на неё известную последовательность и раз в месяц смотрю, что считывается. Уже три месяца прошло и считываются одинаковые данные, то есть как исходно, сразу после записи отдельные байты в отдельных секторах «мутировали», так всё и остаётся. «Порча» на соседние байты/сектора и т.д. не растекается, все биты в байте в ноль не превращаются.

Запросто, у флешек/карточек короткие CRC и нет сложной системы перекрёстных контрольных сумм, как у SSD, чтобы контроллер не загружать расчётами, и они просто не замечают, когда в блоке куча бит поменяла значения.

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

С другой стороны, многие изношеные флешки/карточки спокойно портят данные, но не переходят в RO, считая что у них всё в порядке

а рандомная запись в них при этом идет, или они только на чтение юзаются?

И я не помню, в каком-то стандарте написано, что при отсутствии резервных блоков контроллер должен переходить в RO?

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

Уже три месяца прошло и считываются одинаковые данные, то есть как исходно, сразу после записи отдельные байты в отдельных секторах «мутировали», так всё и остаётся

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

Запросто, у флешек/карточек короткие CRC и нет сложной системы перекрёстных контрольных сумм, как у SSD, чтобы контроллер не загружать расчётами, и они просто не замечают, когда в блоке куча бит поменяла значения.

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

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

а рандомная запись в них при этом идет,

Это надо у ТС'а спросить. В инете утверждают, что идёт. У меня дохлых флешек/карточек в RO нету, или совсем кирпич или рабочие, но я мало их использую. Наверно, можно было бы пошукать по знакомым, но страшно в эту тему глубоко погружаться, итак свободного времени нет.

а оно в принципе не должно читаться, должно ошибку выбивать.

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

там есть избыточность.

Конечно есть, но перешивая контроллер флешки можно указывать некий параметр ECC, который, чем больше, тем длинне ECC. Тем надёжнее сохраняются (восстанавливаются) данные, но тем больше нагрузка на контроллер, соответственно и работает медленне и грется больше. ИМХО, поэтому производители флешек в заводских прошивках не выкручивают ECC на максимум.

А у SSD, ИМХО, ECC выкручен на максимум, и, может путаю, но, вроде, у SSD вычисляется ECC на сектор и ещё отдельно ECC на блок. Где-то читал, но не могу вспомнить.

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

Это надо у ТС’а спросить.

Нет. Не тот случай. Вместо read only теперь говорит «ошибка ввода/вывода» в первом же блоке. То есть не пишет и не читает (ничего там нет, даже разметки).

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

Мы что-то записали на NAND память, что-то прочитали. Понятно, что прочиали другое, и нас спасает магия ECC, но, каждый ECC имеет свои границы, если слишком много ошибок, это уже будет другая последовательность, но правильная с точки зрения ECC.

нет, не будет правильной. будет ошибочной. но контроллер это игнорит…

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

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

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

Просто из интереса. А на флешке когда-то что то было записано, или пустая с завода? Если было, то что-то прочитать можно? Если читать другие блоки, что-то типа:

dd if=/dev/sdb skip=12345 conut=1 | hexdump

то какие-то байты выводятся или нули, или ошибка чтения (в dmesg -T) появляется? Вместо 12345 всякие разные числа, только побольше, чтобы не нулевой цилиндр.

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

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

А на флешке когда-то что то было записано, или пустая с завода?

Я там до этого своп держал. Ну или думал что держал. Воткнул, разметил в своп и забыл. А теперь вот решил образ на нее записать. Удалил раздел, что там был, и херак.
То есть там не было ничего осмысленного.

Я купил новую, потому что как я понял, с контроллерами работать умеют только проги под маздай. А я не собираюсь его ставить.

snajl
() автор топика

Что-то записал но упал с ошибкой, и с тех пор говорит что устройство read only.

Ты сам-то готов доверять такому устройству, даже если его удастся «починить»?

Выкинь да купи новую, это не так чтобы товар на всю жизнь.

MoldAndLimeHoney
()
Ответ на: комментарий от snajl

Ну в первом блоке swap-раздела (1024 байта от начала) содержатся не нули, его метка, размер и т.д., суперблок там. Можно попробовать его найти, если вспомнить, была ли таблица разделов и где начинался первый раздел. А если swap заполнялся, то там ещё могут быть ненулевые блоки.

Интерес то не в осмысленности данных, а в том, вобще флешка в этом режим write protect что-то позволяет с себя считать или нет. Можно вобще попробовать сделать:

dd if=/dev/sdb conv=noerror,sync | hexdump | head -n 50

и посмотреть, хотя бы какой-нибудь мусор выведется.

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

Вот такой мусор вывелся

0000010 1bbf 5006 b957 01e5 a4f3 bdcb 07be 04b1
0000020 6e38 7c00 7509 8313 10c5 f4e2 18cd f58b
0000030 c683 4910 1974 2c38 f674 b5a0 b407 8b07
0000040 acf0 003c fc74 07bb b400 cd0e eb10 88f2
0000050 104e 46e8 7300 fe2a 1046 7e80 0b04 0b74
0000060 7e80 0c04 0574 b6a0 7507 80d2 0246 8306
0000070 0846 8306 0a56 e800 0021 0573 b6a0 eb07
0000080 81bc fe3e 557d 74aa 800b 107e 7400 a0c8
0000090 07b7 a9eb fc8b 571e f58b bfcb 0005 568a
00000a0 b400 cd08 7213 8a23 24c1 983f de8a fc8a
00000b0 f743 8be3 86d1 b1d6 d206 42ee e2f7 5639
00000c0 770a 7223 3905 0846 1c73 01b8 bb02 7c00
00000d0 4e8b 8b02 0056 13cd 5173 744f 324e 8ae4
00000e0 0056 13cd e4eb 568a 6000 aabb b455 cd41
00000f0 7213 8136 55fb 75aa f630 01c1 2b74 6061
0000100 006a 006a 76ff ff0a 0876 006a 0068 6a7c
0000110 6a01 b410 8b42 cdf4 6113 7361 4f0e 0b74
0000120 e432 568a cd00 eb13 61d6 c3f9 6e49 6176
0000130 696c 2064 6170 7472 7469 6f69 206e 6174
0000140 6c62 0065 7245 6f72 2072 6f6c 6461 6e69
0000150 2067 706f 7265 7461 6e69 2067 7973 7473
0000160 6d65 4d00 7369 6973 676e 6f20 6570 6172
0000170 6974 676e 7320 7379 6574 006d 0000 0000
0000180 0000 0000 0000 0000 0000 0000 0000 0000
*
00001b0 0000 0000 2c00 6344 2e18 c307 0000 2000
00001c0 0021 fe83 ffff 0800 0000 3800 03a3 0000
00001d0 0000 0000 0000 0000 0000 0000 0000 0000
*
00001f0 0000 0000 0000 0000 0000 0000 0000 aa55
0000200 0000 0000 0000 0000 0000 0000 0000 0000
*
0101000 0401 0000 0402 0000 0403 0000 0000 1ff5
0101010 0002 0000 0000 0000 0000 0000 0000 0000
0101020 8401 0000 8402 0000 8403 0000 73d3 2000
0101030 0000 0000 0000 0000 0000 0000 0000 0000
0101040 0000 0001 0001 0001 0002 0001 7dfe 2000
0101050 0000 0000 0000 0000 0000 0000 0000 0000
0101060 8401 0001 8402 0001 8403 0001 79fd 2000
0101070 0000 0000 0000 0000 0000 0000 0000 0000
0101080 0000 0002 0001 0002 0002 0002 7dfe 2000
0101090 0000 0000 0000 0000 0000 0000 0000 0000
01010a0 8401 0002 8402 0002 8403 0002 79fd 2000
01010b0 0000 0000 0000 0000 0000 0000 0000 0000
01010c0 0000 0003 0001 0003 0002 0003 7dfe 2000
01010d0 0000 0000 0000 0000 0000 0000 0000 0000
01010e0 8401 0003 8402 0003 8403 0003 79fd 2000
01010f0 0000 0000 0000 0000 0000 0000 0000 0000
0101100 0000 0004 0001 0004 0002 0004 7dfe 2000

(Я не понял, как на форуме скрыть эту простыню текста)

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

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

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

и да, проблемные блоки с нескорректированными ошибками контроллер пытается читать десятки-сотни раз в надежде на то что они таки прочитаются. ну а дальше - уже нюансы поведения: либо выдает ошибку, либо - делает вид что все прочиталось успешно…

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

с microsd - можно штатными методами его попробовать стереть (mmc-utils). и команды для формата, и security erase - установка пароля и потом снятие пароля форматом, смотря что флэшка поддерживает.

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

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

Нет. Ещё раз пишу, в sd-картах и флешках могут использовать алгоритмы малой корректриющей способностью. Экономят.

И «в разы больше» звучит пафосно, но классический код хэмминга не видит трёхкратные ошибки, а его в SLC использовали. Завал трёх бит на сектор (512) байт вобще ерунда. Запись в ячейку с пробитой изолячией может завиливать биты во всех физически соседних на кристале ячейках.

А дальше стали использовать BCH, и они, как бы, круче Соломона, но, они заточены на одиночные ошибки. А со смежными ошибками хуже.

контроллер пытается читать десятки-сотни раз

Это общая теория, у меня есть изношеная microSD, с которой читается не то, что записалось, без запинок, никакого проседания скорости в области ошибочных данных нет. Другой контроллер может делать что угодно - менять напряжения для многоуровневых ячеек, скорость чтения, порядок чтения...

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

Нормальны MBR без загрузчика (Invalid partition table.Error loading operating system.Missing operating system). Только я не понял, если там был swap, то почему тип раздела 83, это же обычная ФС, swap должен быть 82. Или у вас swap был в файле поверх файловой системы?

Ну, так получается, что флешка повела себя корректно, по какой-то причине залочилась, писать не даёт, читать даёт.

Только я не понял, что там с файловой системой. У меня получилось смещение 4кбайт от начала раздела, как-то многовато, как будто вместо суперблока нули.

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

Нет. Ещё раз пишу, в sd-картах и флешках могут использовать алгоритмы малой корректриющей способностью. Экономят.

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

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

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

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

в рамках заявленных обнаруживаемых битов

К этому всё и сводится. Если разом появилась существеная область, неправильных бит, то штатный ECC будет выдавать или ошибку или скорректированую, но неправильную последовательность. Допустим, NAND флеш и производитель допускает до 4 единичных ошибок на 512 байт, которые на исправной памяти действительно появляются и в разных местах, от чтения к чтению. А если первый байт «пробило» и при чтении всегда 0xFF, а мы туда записали 0x00, то алгоритм ECC скорее вернёт корректируемую ошибку, чем некорректируемую. Рандомно возникаемы одиночные ошибки на остальных байтах, если что помогут алгоритму не при первом, дак при втором чтении.

То есть, по-хорошему, контроллер сразу после записи в NAND сектора данных+ECC, должен его прочитать (без коррекции), посчитать сколько бит неправильно прочиталось и принимать решение об исправности NAND. Но он так не делает, это же производительность минимут вдвое снизит.

чтобы не было возвратов флэшек

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

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

Только я не понял, если там был swap, то почему тип раздела 83, это же обычная ФС, swap должен быть 82. Или у вас swap был в файле поверх файловой системы?

Я сделал в gparted удалить раздел, а потом сделал раздел с ext3 (мне он был не нужен, я его сделал не подумав, чисто протупив). Во время создания этого раздела, оно и свалилось с ошибкой.

Потом я уже туда пытался и образ писать и тупо нули, но это уже после того как оно стало read only.

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

Допустим, NAND флеш и производитель допускает до 4 единичных ошибок на 512 байт, которые на исправной памяти действительно появляются и в разных местах, от чтения к чтению. А если первый байт «пробило» и при чтении всегда 0xFF, а мы туда записали 0x00, то алгоритм ECC скорее вернёт корректируемую ошибку, чем некорректируемую.

но у вас в принципе ошибки не возвращает же. как читала так и читает…

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

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

NiTr0 ★★★★★
()