Здравствуйте, koandrew, Вы писали:
K>Дело в том, что флеш-память (в отличие от "обычных" HDD) нельзя просто перезаписать — нужно сначала обнулить сектор (erase), и только потом туда что-то записать. Если в промежутке между этими операциями кончится электричество — ну вы поняли...
Это работает несколько не так. SSD никогда не перезаписывает тот же сектор, пишется всегда в свободное место а старое стирается и становится свободным когда нибудь потом. TRIM всего лишь помогает с определением какие сектора в блоке точно ненужные если они просто были ОС освобождены но не "перезаписаны" в логическом пространстве.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, jazzer, Вы писали:
J>системный SSD перестал грузить винду, автоматический repair на старте винды не помогает (он просто висит много часов на "repairing disk" и виснет потом), если загрузиться с USB в recovery console, то можно почти все файлы скопировать (и на том спасибо), но на некоторых файлах и директориях (на этапе dir) консоль виснет намертво (я комп перезагрузил за прошлую ночь раз 80, наверное, пока выжившие файлы спасал).
Как это случилось? Вот просто так на ровном месте в один "прекрасный" момент всё перестало пахать? Или как?
К чему я это спрашиваю — у меня была похожая проблема после того, как неожиданно (для компа) в розетке кончилось электричество. И точно так же некоторые файлы (само собой, по закону подлости они оказались самыми нужными) оказались повреждёнными. Я грузился из-под "консоли восстановления" вин10 (кажись так она называется в русской версии), и копировал файлы по одному (потому что копирование сразу нескольких файлов почему-то зависало), причём копирование в рандомные моменты зависало (но после перезагрузки тот же файл нормально копировался). В общем, после 100500 перезагрузок все важные файлы я скопировал, после чего отформатировал диск — до сих пор работает как часы. Мораль — при работе с SSD 1) отключайте кэширование записи (по идее винда сама должна отключать, но лучше убедиться лично), и 2) купите хотя бы простейший ИБП. Дело в том, что флеш-память (в отличие от "обычных" HDD) нельзя просто перезаписать — нужно сначала обнулить сектор (erase), и только потом туда что-то записать. Если в промежутке между этими операциями кончится электричество — ну вы поняли...
Здравствуйте, andrey.desman, Вы писали:
AD>Есть 3 безопасных варианта использования SSD: AD>в ноутбуке, AD>в десктопе с ИБП, AD>использовать SSD от Intel. Из тестов только интеловские SSD стабильно не сыпятся от потери питания.
+ самый топорный: делать регулярные бэкапы всего, для этого есть удобные программы с инкрементальными бэкапами. Причём в случае HDD их тоже желательно делать, особенно в случае ноутбука — так как его могут украсть, можно разбить, утопить и т.п.
системный SSD перестал грузить винду, автоматический repair на старте винды не помогает (он просто висит много часов на "repairing disk" и виснет потом), если загрузиться с USB в recovery console, то можно почти все файлы скопировать (и на том спасибо), но на некоторых файлах и директориях (на этапе dir) консоль виснет намертво (я комп перезагрузил за прошлую ночь раз 80, наверное, пока выжившие файлы спасал).
Втыкал через переходник в USB в другой комп — тот говорит, что на SMART все хорошо, никаких проблем с диском не увидел (с копированием те же проблемы на тех же файлах/директориях).
Когда скопировал файлы, решил еще раз попробовать chkdsk (на родном компе, по SATA) — он дошел до 84% на Stage 2, повисел сколько-то минут, и выдал вот такую штуку: скриншот
Кто-нибудь что-нибудь в этом понимает? гугление ничего внятного не дало, что дальше делать, непонятно
P.S. SanDisk X110
лог chkdsk с другого компа (через USB, не SATA):
Stage 1: Examining basic file system structure ...
562944 file records processed. File verification completed.
13903 large file records processed.
0 bad file records processed.
Stage 2: Examining file name linkage ...
Read failure with status 0xc00000b5 at offset 0x1d8700000 for 0x1000 bytes.
Read failure with status 0xc00000b5 at offset 0x1d86ff000 for 0x3000 bytes.
A disk read error occurredc00000b5
The index buffer at VCN 0x1 of index $I30 in file 0x45e1
cannot be read.
Read failure with status 0xc00000b5 at offset 0x1d8701000 for 0x1000 bytes.
The index buffer at VCN 0x2 of index $I30 in file 0x45e1
cannot be read.
Correcting error in index $I30 for file 17889.
The index bitmap $I30 in file 0x45e1 is incorrect. CHKDSK discovered free space marked as allocated in the bitmap for index $I30 for file 17889.
Read failure with status 0xc00000b5 at offset 0x1d86ff000 for 0x1000 bytes. An unspecified error occurred (696e647863686b2e 849).
ругается на то же самое, что и то, что на скриншоте выше, но информации чуть больше (ну и сакраментальное: There was a problem repairing this drive. Windows was unable to repair the drive. Close this dialog box, and then try to repair the drive again).
J>Кто-нибудь что-нибудь в этом понимает? гугление ничего внятного не дало, что дальше делать, непонятно
(сразу скажу, ни разу не эксперт в этом, так что далее лишь предположения WITHOUT WARRANTY OF ANY KIND)
1. Попробуй сделать полный образ всего диска на сыром уровне, без вмешательства fs — dd if=/dev/SOURCEDEVICE of=~/sandisk_sdd.img bs=32M — это можно сделать практически с любого live-Linux (ЕМНИП в Clonezilla вообще через меню). Это может прояснить ситуацию в чём именно проблема — в железе или в ФС, плюс если получится сделать образ то можно не боятся экспериментировать с ним.
2. Есть разнообразные Live CD/USB на базе Linux (бывает и Windows) — напичканные утилитами для восстановления/проверки, да и получишь более подробный log. Из названий вспоминается R-Studio.
3. А сколько свободного места? Можно попробовать удалить не нужное/уже спасённое, и за-TRIM'ать это всё — может ему полегчает.
J>гугление ничего внятного не дало, что дальше делать, непонятно
Здравствуйте, Evgeny.Panasyuk, Вы писали:
J>>Кто-нибудь что-нибудь в этом понимает? гугление ничего внятного не дало, что дальше делать, непонятно
EP>(сразу скажу, ни разу не эксперт в этом, так что далее лишь предположения WITHOUT WARRANTY OF ANY KIND)
EP>1. Попробуй сделать полный образ всего диска на сыром уровне, без вмешательства fs — dd if=/dev/SOURCEDEVICE of=~/sandisk_sdd.img bs=32M — это можно сделать практически с любого live-Linux (ЕМНИП в Clonezilla вообще через меню). Это может прояснить ситуацию в чём именно проблема — в железе или в ФС, плюс если получится сделать образ то можно не боятся экспериментировать с ним.
EP>2. Есть разнообразные Live CD/USB на базе Linux (бывает и Windows) — напичканные утилитами для восстановления/проверки, да и получишь более подробный log. Из названий вспоминается R-Studio.
Попробовал Clonezilla — она (вернее, particlone, который она внутри себя запустила) показала свою левую резьбу:
ntfsclone-ng.c: NTFS volume '/dev/sdb2' is scheduled for a check or it was shutdown uncleanly. Please boot Windows or fix it by fsck.
(при этом про fsck жкраном раньше написано, что не надо рисковать на NTFS)
EP>3. А сколько свободного места? Можно попробовать удалить не нужное/уже спасённое, и за-TRIM'ать это всё — может ему полегчает.
места дофига, больше половины.
J>>гугление ничего внятного не дало, что дальше делать, непонятно
EP>Все нужные файлы спасены?
не все, в том-то и дело. некоторые директории не открылись
Здравствуйте, jazzer, Вы писали:
J>Попробовал Clonezilla — она (вернее, particlone, который она внутри себя запустила) показала свою левую резьбу: J>
J>ntfsclone-ng.c: NTFS volume '/dev/sdb2' is scheduled for a check or it was shutdown uncleanly. Please boot Windows or fix it by fsck.
J>(при этом про fsck жкраном раньше написано, что не надо рисковать на NTFS)
Нужно попробовать создать именно сырой образ всего диска, никак не пытаясь интерпретировать файловую систему. В Clonezilla ЕМНИП были варианты на этот счёт.
Если нет — то подойдёт практически любой live-linux (Ubuntu Live, Kali, etc) — в них есть dd.
EP>>3. А сколько свободного места? Можно попробовать удалить не нужное/уже спасённое, и за-TRIM'ать это всё — может ему полегчает. J>места дофига, больше половины.
А какая OS? TRIM был включён? SSD мог не видеть это пустое место, что увеличивает неравномерность износа ячеек.
Ключевые слова — Trim, Wear leveling.
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>Нужно попробовать создать именно сырой образ всего диска, никак не пытаясь интерпретировать файловую систему. В Clonezilla ЕМНИП были варианты на этот счёт. EP>Если нет — то подойдёт практически любой live-linux (Ubuntu Live, Kali, etc) — в них есть dd.
Да, я именно так и пробовал — он предлагал весь диск и по партишенам — я выбрал первое.
Попробую другие тоже.
EP>А какая OS? TRIM был включён? SSD мог не видеть это пустое место, что увеличивает неравномерность износа ячеек. EP>Ключевые слова — Trim, Wear leveling.
Здравствуйте, jazzer, Вы писали:
EP>>Нужно попробовать создать именно сырой образ всего диска, никак не пытаясь интерпретировать файловую систему. В Clonezilla ЕМНИП были варианты на этот счёт. EP>>Если нет — то подойдёт практически любой live-linux (Ubuntu Live, Kali, etc) — в них есть dd. J>Да, я именно так и пробовал — он предлагал весь диск и по партишенам — я выбрал первое.
Видимо он пытается где-то хитрить, типа копировать не всё а только занятое, а для этого нужно лезть в ФС.
Проще тогда взять dd — он топорнее всего — я им много раз делал образы/бэкапы, а потом перезаливал, иногда частично — только MBR.
Вот здесь для него показана опция для продолжения после ошибок — conv=noerror,sync
J>Втыкал через переходник в USB в другой комп — тот говорит, что на SMART все хорошо
USB переходники могут некорректно передавать SMART.
По симптомам, похоже, да, какие-то конкретные секторы ушли навеки. И, похоже, это были секторы из MFT или одного из extent'ов.
Здравствуйте, jazzer, Вы писали:
J>системный SSD перестал грузить винду, автоматический repair на старте винды не помогает (он просто висит много часов на "repairing disk" и виснет потом), если загрузиться с USB в recovery console, то можно почти все файлы скопировать (и на том спасибо), но на некоторых файлах и директориях (на этапе dir) консоль виснет намертво (я комп перезагрузил за прошлую ночь раз 80, наверное, пока выжившие файлы спасал).
J>Втыкал через переходник в USB в другой комп — тот говорит, что на SMART все хорошо, никаких проблем с диском не увидел (с копированием те же проблемы на тех же файлах/директориях).
J>Когда скопировал файлы, решил еще раз попробовать chkdsk (на родном компе, по SATA) — он дошел до 84% на Stage 2, повисел сколько-то минут, и выдал вот такую штуку: J>скриншот
Обработка ошибок обычно является наименее тестируемой частью в любой программе, и софт накопителя, равно как и файловой системы, тут не исключение. Так что в описанном поведении ничего странного вроде как и нет.
J>Кто-нибудь что-нибудь в этом понимает? гугление ничего внятного не дало, что дальше делать, непонятно
J>P.S. SanDisk X110
Для начала я б попробовал влить в него наираспоследнюю прошивку. Вдруг как раз этот баг починили и оно начнёт просто на ошибки ругаться.
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Здравствуйте, koandrew, Вы писали:
K>К чему я это спрашиваю — у меня была похожая проблема после того, как неожиданно (для компа) в розетке кончилось электричество. И точно так же некоторые файлы (само собой, по закону подлости они оказались самыми нужными) оказались повреждёнными. Я грузился из-под "консоли восстановления" вин10 (кажись так она называется в русской версии), и копировал файлы по одному (потому что копирование сразу нескольких файлов почему-то зависало), причём копирование в рандомные моменты зависало (но после перезагрузки тот же файл нормально копировался). В общем, после 100500 перезагрузок все важные файлы я скопировал, после чего отформатировал диск — до сих пор работает как часы.
K>Мораль — при работе с SSD 1) отключайте кэширование записи (по идее винда сама должна отключать, но лучше убедиться лично),
Это не надо, не поможет.
и 2) купите хотя бы простейший ИБП.
Это верно.
K>Дело в том, что флеш-память (в отличие от "обычных" HDD) нельзя просто перезаписать — нужно сначала обнулить сектор (erase), и только потом туда что-то записать. Если в промежутке между этими операциями кончится электричество — ну вы поняли...
На диске тоже можно сектор потерять, не в этом дело. На SSD надо стирать весь erase-block, который может быть от 512К и выше, чтобы переписать несчастные 4К. В этом деле TRIM очень помогает, потому как дает знать контроллеру SSD о наличии свободного места. Меньше шанс накосячить при незаполненной ФС.
Но дело дело даже не в этом. Ну потеряешь ты не 4К, а 1М — это не так страшно. Страшно, что на MLC SSD простейшей операцией записи можно похерить совершенно рандомные данные, в том числе и структуру файловой системы, которая к переписываемым данным никакого отношения не имеет.
Что еще хуже, так это то, что SSD часть памяти отводят на маппинг LBA<->flash offset и прочие внутренние данные, и при особом везении, если эта структура похерится, можно грохнуть вообще все данные на диске.
Есть 3 безопасных варианта использования SSD:
в ноутбуке,
в десктопе с ИБП,
использовать SSD от Intel. Из тестов только интеловские SSD стабильно не сыпятся от потери питания.
Здравствуйте, CreatorCray, Вы писали:
CC>Это работает несколько не так. SSD никогда не перезаписывает тот же сектор, пишется всегда в свободное место а старое стирается и становится свободным когда нибудь потом. TRIM всего лишь помогает с определением какие сектора в блоке точно ненужные если они просто были ОС освобождены но не "перезаписаны" в логическом пространстве.
Он не "всего лишь" помогает, а очень даже помогает. Без него, если один раз забил диск до отказа (то есть как минимум единожды записывал данные в каждый сектор LBA) то свободного места там будет только в объеме зарезервированного. Без трима и жизнь ССД сократится, и производительность будет страдать.
Здравствуйте, RBender, Вы писали:
RB>Здравствуйте, jazzer, Вы писали:
J>>системный SSD перестал грузить винду,
RB>Недавно была похожая проблема на Plextor 256M5S. RB>Помогла перепрошивка, видимо, что-то в коде контроллера поломалось.
В смысле, перепрошивка той же самой версии, просто на всякий случай?
Потому что мой сейчас на последней.
Здравствуйте, koandrew, Вы писали:
K>Здравствуйте, jazzer, Вы писали:
J>>системный SSD перестал грузить винду, автоматический repair на старте винды не помогает (он просто висит много часов на "repairing disk" и виснет потом), если загрузиться с USB в recovery console, то можно почти все файлы скопировать (и на том спасибо), но на некоторых файлах и директориях (на этапе dir) консоль виснет намертво (я комп перезагрузил за прошлую ночь раз 80, наверное, пока выжившие файлы спасал).
K>Как это случилось? Вот просто так на ровном месте в один "прекрасный" момент всё перестало пахать? Или как?
Да. Просто видна зависла в лок-скрине, а после ребута при запуске.
K>К чему я это спрашиваю — у меня была похожая проблема после того, как неожиданно (для компа) в розетке кончилось электричество. И точно так же некоторые файлы (само собой, по закону подлости они оказались самыми нужными) оказались повреждёнными. Я грузился из-под "консоли восстановления" вин10 (кажись так она называется в русской версии), и копировал файлы по одному (потому что копирование сразу нескольких файлов почему-то зависало), причём копирование в рандомные моменты зависало (но после перезагрузки тот же файл нормально копировался). В общем, после 100500 перезагрузок все важные файлы я скопировал, после чего отформатировал диск — до сих пор работает как часы. Мораль — при работе с SSD 1) отключайте кэширование записи (по идее винда сама должна отключать, но лучше убедиться лично), и 2) купите хотя бы простейший ИБП. Дело в том, что флеш-память (в отличие от "обычных" HDD) нельзя просто перезаписать — нужно сначала обнулить сектор (erase), и только потом туда что-то записать. Если в промежутке между этими операциями кончится электричество — ну вы поняли...
вроде, на win10 TRIM по умолчанию включен...
Тут еще две детали есть.
Я подключил к другому компу его по сата, и заюзал их родную сандисковскую утилитку.
Она тоже показала, что в SMART все хорошо, но когда я попросил провести SMART test, они (и базовый, и расширенный) не прошли дальше 10%.
После чего я заюзал HDDScan — сканирование "поверхности" в read-only — оно начало рисовать бэд-блоки.
Ну и на родном компе я сохранил низкоуровневый образ диска через dd — он тоже показал кучу read errors.
Так что я не уверен, что это все можно списать чисто на повреждение NTFS, и не уверен, что форматирование что-то изменит, с учетом ошибок низкоуровневого чтения.
Но попробую, конечно, тем более что саппорт тоже сказал форматнуть, прежде чем посылать к ним на замену.
Здравствуйте, jazzer, Вы писали:
J>Ну и на родном компе я сохранил низкоуровневый образ диска через dd — он тоже показал кучу read errors.
Этот образ кстати можно монтировать через mount (опять-таки, предварительно сделав резервную копию) — там сначала нужно узнать смещение partition через fdisk, а потом примонтировать с этим смещением + ещё какая-то опция, легко ищется по "mount dd image". Но не факт что *nix'овые NTFS утилиты прожуют этот раздел (так как в нём структурные ошибки).
Этот же образ можно то ли напрямую подцепить к VirtualBox, то ли сконвертировать штатной утилитой, тоже легко ищется "dd disk image virtualbox".
Можно попробовать запустить этот образ внутри VM, либо сразу загрузить с диска Windows Recovery Console, и уже через неё chkdsk на этот виртуальный образ. Дело в том что в этом случае железные ошибки не будут мешать, и шансов восстановится больше.
