Comments 75
Можно узнать в чем смысл статьи? В том что винчестер не работал, а после форматирования заработал?
Судя по тому что вы написали, вы даже не попробовали банально записать файл обратно.
Итого, имеем простую констатацию факта: «Винчестер глючил». Ни причины, ни конкретного способа решения нет. Только призрачное: «Когда файл проходит через контролер». Что было внутри файла? Он был пустой или нет? Какое было имя файла?
Судя по тому что вы написали, вы даже не попробовали банально записать файл обратно.
Итого, имеем простую констатацию факта: «Винчестер глючил». Ни причины, ни конкретного способа решения нет. Только призрачное: «Когда файл проходит через контролер». Что было внутри файла? Он был пустой или нет? Какое было имя файла?
Установить Data Migration еще раз.
Если файл появится, вы раскрыли заговор )
Если файл появится, вы раскрыли заговор )
Система как и SSD то уже со следами от этой пакости… Надо на чистых пробовать…
А желания и времени выгребать оставшийся после Data Migration мусор нет. Да и особых гарантий что все почистишь не найдешь — такие вещи в тихую делаются. :)
Я только подозреваю, что это от Data Migration… ХОТЯ МОТИВ ПОНЯТЕН… Может он, банально, из магазина Виндовс 8 приполз. Хотя какой смысл убивать вичестер?
Не получится раскрыть заговор без еще одного такого файла.
Вот и обращаюсь к сообществу, мож у кого похожая ситуация.
А желания и времени выгребать оставшийся после Data Migration мусор нет. Да и особых гарантий что все почистишь не найдешь — такие вещи в тихую делаются. :)
Я только подозреваю, что это от Data Migration… ХОТЯ МОТИВ ПОНЯТЕН… Может он, банально, из магазина Виндовс 8 приполз. Хотя какой смысл убивать вичестер?
Не получится раскрыть заговор без еще одного такого файла.
Вот и обращаюсь к сообществу, мож у кого похожая ситуация.
Надо, Федя, надо.
// Только я думаю, как же можно было увидеть имя файла, если само имя файла убивало контроллер?
// Только я думаю, как же можно было увидеть имя файла, если само имя файла убивало контроллер?
Чисто в теории, гипотетически как говорится, контроллер может делать какие то сервисные функции в фоне, и именно на эти функции как-то может влиять этот набор данных. А вот на чтение этих данных это не сказывается никак.
PS. Повторюсь гипотетически.
PS. Повторюсь гипотетически.
Так он и делает. Только ФС и прочих высокоуровневых вещей он касаться вообще не должен и про них не знает. Все на уровне блоков.
Хотя, имя файла то тоже в каком-то блоке лежит…
Хотя, имя файла то тоже в каком-то блоке лежит…
Чисто на практике это срабатывает в линуксе, поскольку объем памяти в контроллере мал, и впихивать поддержку всех 30ти с фигом файловых систем смысла нет.
А вот FAT, NTFS, HFS+ — очень даже знает (в той или иной степени). Как минимум служебные и часто перезаписываемые области он знать обязан — все-таки число перезаписей конечно. В той же NTFS всякие MFT да логи любят дырки протирать.
FAT* вообще полностью эмулируется.
А вот FAT, NTFS, HFS+ — очень даже знает (в той или иной степени). Как минимум служебные и часто перезаписываемые области он знать обязан — все-таки число перезаписей конечно. В той же NTFS всякие MFT да логи любят дырки протирать.
FAT* вообще полностью эмулируется.
Думаю изначально подвисало что-то другое а не контроллер SSD, иначе BSOD был бы при первой-же попытке чтения этого файла.
Что-то что также читает этот файл после 5 минут работы системы — например это могла бы быть служба super prefetch или служба индексирования.
Что-то что также читает этот файл после 5 минут работы системы — например это могла бы быть служба super prefetch или служба индексирования.
Средствами Windows к файлу обратится нельзя было — его имя с путем слишком длинное.
А под DOS, чем обясняется?
А под DOS, чем обясняется?
Ну если копирование производилось под DOS, тогда этот вариант отпадает.
А что за файловая система использовалась? Еще не понял — система подвисала при первом обращении к этому файлу, или файл просто не копировался, а SSD подвисал через 5 мин работы если этот файл просто присутствовал? Что если зайти в BIOS и там подождать 6 мин?
А что за файловая система использовалась? Еще не понял — система подвисала при первом обращении к этому файлу, или файл просто не копировался, а SSD подвисал через 5 мин работы если этот файл просто присутствовал? Что если зайти в BIOS и там подождать 6 мин?
все кеш файлы, реестр, профили пользователей и т.п. перенесены на 2Tb «механического винчемонстра».
Какой смысл покупать SSD, если активно используемые файлы все равно будет отправлены на HDD?
Это все страх того, что ссд скоропостижно скончается. Я вот тоже по глупости вынес все профили пользователей на хдд. Как оказалось, профита от этого немного, а страданий от медленного чтения — очень много.
Это был мой первый SSD. Делал все чтоб жыл дольше.
После года использования стало понятно, что можно было так не перестраховываться.
После года использования стало понятно, что можно было так не перестраховываться.
Я решил проблему просто: система на RAID1 SSD+HDD. Чтение: сумма скоростей, запись: соответствует скорости самого медленного. Разумеется, держать кэши и профиль пользователя так не имеет смысла, а вот систему и программы — вполне.
Сомневаюсь что будет «сумма скоростей»
Почему? При параллельном чтении — вполне (хоть это и freebsdwiki, но вариант от BSD там сравнивается с Linux mdadm).
Когда читает одно приложение и последовательно, конечно, никакого прироста нет: mdadm не занимается угадыванием блоков, которые будут запрошены далее.
Когда читает одно приложение и последовательно, конечно, никакого прироста нет: mdadm не занимается угадыванием блоков, которые будут запрошены далее.
Не сумма, а по скорости максимального.
Контроллеру без разницы какая ФС используется на диске. Скорее всего вам попался неисправный диск. У меня тоже Samsung 840 pro, правда другого объёма, полёт отличный.
Вообще говоря, при чем тут винт? Падала же винда.
Теперь таже Винда живет и здравствует… BSOD появлялся когда винт отключался — это следсвие а не причина.
На другом компе под виндовсом он просто пропадал. И даже под DOS винт тоже падал…
На другом компе под виндовсом он просто пропадал. И даже под DOS винт тоже падал…
А «драйвера» для NTFS, которые вы использовали в ДОС, писали не люди, а БОГи, которым ошибки не веданы.
Скорее всего, это и есть ПРИЧИНА.
У меня у друга так периодичностью в неделю — две HDD падал. Иногда спасал обычный chkdsk (система начинала загружаться нормально), иногда — нет. Приходилось форматировать целый раздел. Я долго гадал, что не так. Помогла замена шлейфов.
После полного отключения питания и передергивания шлейфов, SSD ожил.
Скорее всего, это и есть ПРИЧИНА.
У меня у друга так периодичностью в неделю — две HDD падал. Иногда спасал обычный chkdsk (система начинала загружаться нормально), иногда — нет. Приходилось форматировать целый раздел. Я долго гадал, что не так. Помогла замена шлейфов.
Silicon Power V20 основан на контроллере Sandforce SF-1200, у которого некорректно реализована работа с режимом энергосбережения. В результате ошибки в прошивке, SSD иногда не определяется системой (что приводит к BSOD с ошибкой 0x00000F4).
У других SSD на этом контроллере аналогичные проблемы: OCZ Vertex 2 now having problems after 5 minutes .
У других SSD на этом контроллере аналогичные проблемы: OCZ Vertex 2 now having problems after 5 minutes .
Оно то да… проблема очень похожая…
Только вот, почему глюк с вылетом пропал, как только был удален файл. Мож это бэкдор, а не некоректная реализация…
Только вот, почему глюк с вылетом пропал, как только был удален файл. Мож это бэкдор, а не некоректная реализация…
- Внезапные «обмороки» контроллера могли привести (и наверняка привели) к повреждению NTFS, что, в свою очередь, могло привести к появлению странного файла.
- Повреждения NTFS могут вызывать BSOD.
- Какая-то системная служба (например, сервис индексирования) добиралась до испорченного места примерно через пять минут после загрузки — бах, BSOD.
- Удаление файла исправило ошибку в NTFS, и всё стало окей.
Дело в том, что обмороков контролера, не было, до этих событий. И после удаления файла, их тоже не стало.
Помирал сначала контролер, а потом, как следствие, умирала система, которая не могла достучатся до своих файлов. Это проверено на другом компьютере, там SSD просто пропадал. А система работала дальше.
Сканировал, только что, SSD накопитель R-Studio — искал Файл. Ошибки в NTFS есть — они видимо следствие частых падений. Но сейчас он работает безотказно.
Помирал сначала контролер, а потом, как следствие, умирала система, которая не могла достучатся до своих файлов. Это проверено на другом компьютере, там SSD просто пропадал. А система работала дальше.
Сканировал, только что, SSD накопитель R-Studio — искал Файл. Ошибки в NTFS есть — они видимо следствие частых падений. Но сейчас он работает безотказно.
Вот вот, у меня подобная проблема, и единственное что «помогло» этому диску это перевод контроллера в режим эмуляции IDE, а там этих режимов энергосбережения просто нет. Фактически проблема была в том, что контроллер выключался вместо перехода в состояние глубокого сна.
p.s: к слову — производитель (OCZ) — редкостный козёл, ибо несколько вышедших прошивок проблему не исправили.
p.s: к слову — производитель (OCZ) — редкостный козёл, ибо несколько вышедших прошивок проблему не исправили.
День крип(т)оты на Хабре
так чего, автор будет ставить по новой Data migrtion? — всё таки интересно, повторите эксперимент?
Вообще говоря, на современных флэшках (ссд-шках, нужное подставить) контроллер умнее чем кажется. Так, унутре у него неонка, т. е. нечто вроде jffs2. А наружу контроллер выдает к примеру FAT. Или NTFS. Или RAW. Смотря что в суперблоке окажется, а то вдруг там своп, как у меня.
И ежель там что не то (особенно после sleep/standby!) — то диск просто дисконнектится. Ашыпка в слое эмуляции, куда тут работать дальше-то…
И поэтому диск становится весьма чувствительным к ошибкам вышележащей ФС. Особенно если система мастерски трапанулась накануне и как результат насоздавалось нечто непотребное.
Или банально ошибся драйвер фильтра ФС, подсунувший кривой буфер для reparse point ;-)
Обычно, слой эмуляции содержит защиту от дурака и переваривает что скажут, там кроме нулевого символа особых проблем быть не должно. Но есть нюансы с альтернативными потоками, junction / reparse points и кучей всякой экзотики, которой в NTFS тьма.
И вот когда в слой эмуляции прилетает не paged read / cached IO / IRP_MJ_BROWSE_DIRECTORY., а гораздо менее распространенный IOCTL, то у вышележащей 8ки и у слоя эмуляции начинаются рассогласования. Или диск детачится, или винда падает.
А удалив каталог вы удалили и все странности из него,
И ежель там что не то (особенно после sleep/standby!) — то диск просто дисконнектится. Ашыпка в слое эмуляции, куда тут работать дальше-то…
И поэтому диск становится весьма чувствительным к ошибкам вышележащей ФС. Особенно если система мастерски трапанулась накануне и как результат насоздавалось нечто непотребное.
Или банально ошибся драйвер фильтра ФС, подсунувший кривой буфер для reparse point ;-)
Обычно, слой эмуляции содержит защиту от дурака и переваривает что скажут, там кроме нулевого символа особых проблем быть не должно. Но есть нюансы с альтернативными потоками, junction / reparse points и кучей всякой экзотики, которой в NTFS тьма.
И вот когда в слой эмуляции прилетает не paged read / cached IO / IRP_MJ_BROWSE_DIRECTORY., а гораздо менее распространенный IOCTL, то у вышележащей 8ки и у слоя эмуляции начинаются рассогласования. Или диск детачится, или винда падает.
А удалив каталог вы удалили и все странности из него,
А как же тогда SSD совместимы с разными файловыми системами? Всяким разным, под linux, например.
Если он некоторые (неизвестные) системы игнорирует (как и swap) и «выдаёт RAW», то как это сказывается на производительности?
Пруф есть Вашим словам?
Если он некоторые (неизвестные) системы игнорирует (как и swap) и «выдаёт RAW», то как это сказывается на производительности?
Пруф есть Вашим словам?
Ну а как же тогда TRIM работает…
Здесь никого нет!
Я ничего не разглашал!
Это не я!
Куда вы меня тащите!!!
Оно не игнорирует. Оно дает возможность через доп-апи файловой системе напрямую управлять реальными блоками, чтобы не эмулировать raw поверх jffs2 поверх которого опять jffs2. Я оглянулся посмотреть не оглянулась ли ты чтобы увидеть не оглянулся ли я.
Это в линуксе, если что. И не на всех контроллерах NAND. Но есть уже лет пять как.
Другое дело что в винде за достижение считается TRIM… Который в общем и целом и придуман для этого самого слоя эмуляции. Все — мы записали, закрывай журнал! Я утрирую слегка, если что.
Я ничего не разглашал!
Это не я!
Куда вы меня тащите!!!
Оно не игнорирует. Оно дает возможность через доп-апи файловой системе напрямую управлять реальными блоками, чтобы не эмулировать raw поверх jffs2 поверх которого опять jffs2. Я оглянулся посмотреть не оглянулась ли ты чтобы увидеть не оглянулся ли я.
Это в линуксе, если что. И не на всех контроллерах NAND. Но есть уже лет пять как.
Другое дело что в винде за достижение считается TRIM… Который в общем и целом и придуман для этого самого слоя эмуляции. Все — мы записали, закрывай журнал! Я утрирую слегка, если что.
BSOD — это ошибка ОС, а не отказ оборудования. Почему ваша ОС так реагирует на странные имена файлов — спрашивайте вендора.
Вообще, не тянет на статью, без повторного воспроизведения проблемы, и без подробностей.
В стареньком OSZ я наступал на похожие грабли, когда ОС после года работы стала подвисать. Оказалось баг в фирмвари, там чтото переполнялось. Перепрошивка вылечила проблему, но осадочек остался.
Надо было когда винт вырубался попробовать включить его не подключая шлейф SATA, просто подать питание и посмотреть отрубится он через 5 минут или нет. Определить это по потреблению линии 5В (очевидно, не по звуку шпинделя). Кстати, вполне вероятно, что винт отключался не сам по себе, а его отключала ОС. Не знаю как в SATA, а у IDE винчестеров программно можно было отключать мотор шпинделя (и диск физически останавливался).
Сейчас гадать будет очень сложно. Жаль, что вы изначально не сделали копию того файла.
Сейчас гадать будет очень сложно. Жаль, что вы изначально не сделали копию того файла.
SSD Шредингера.
Довольно глупая статья, почти все приведенные «зацепки» автора — сродни объяснениям в стиле битвы экстрасенсов.
Большинству очевидно что имена файлов как и содержание файлов нисколько не трогают контроллер самого накопителя, для него всё это просто массив байт. Программы миграции это кастомные билды программ создания образов дисков, которые делают точную копию диска (а в случае посекторного образа — идентичную копию).
Наиболее вероятная причина подобной магии — ненадёжный контакт SATA-шлейфа.
Большинству очевидно что имена файлов как и содержание файлов нисколько не трогают контроллер самого накопителя, для него всё это просто массив байт. Программы миграции это кастомные билды программ создания образов дисков, которые делают точную копию диска (а в случае посекторного образа — идентичную копию).
Наиболее вероятная причина подобной магии — ненадёжный контакт SATA-шлейфа.
offtop:
Хотелось бы предостеречь пользователей от покупки OCZ Vector. Подыхает у 90% пользователей(кстати, с точно такими же симптомами) через 1.5-2 месяца. Они их, конечно, по гарантии меняют, но разве это нам нужно?
Хотелось бы предостеречь пользователей от покупки OCZ Vector. Подыхает у 90% пользователей(кстати, с точно такими же симптомами) через 1.5-2 месяца. Они их, конечно, по гарантии меняют, но разве это нам нужно?
Мне повезло, я в тех 10% :)
Не знаю, как Vector, а OCZ Agility вполне нормально работает более года. SMART говорит, что Power_On_Hours — 3861h+, т.е. около 160 суток чистого времени.
При этом все «ошибки» (Raw_Read_Error_Rate, etc.) на нуле.
При этом все «ошибки» (Raw_Read_Error_Rate, etc.) на нуле.
Такая проблема именно с Vector.
У меня OCZ Agility 3 больше года. Сразу обновил прошивку до 2.22. Так он работал больше года без проблем (компьютер включен около 85% времени). А потом начались зависания. 10 минут бездействия и все, винда висит. Помогало запустить видео, поставить на паузу и свернуть. Потом обновил прошивку до 2.25 и теперь опять работает нормально, месяц без зависаний. Не знаю, что уж там было причиной.
У меня Vector проработал полгода… Прошивку не менял. В один «прекрасный» момент перестал определяться и зажал 256Гб домашних файлов. Первое, что у меня вышло из строя за последние лет 10. Выводов делать не буду — выборка маловата.
фирменной программой от Samsung — Data Migration
Ох уж эти фирменные программы :D
Я, кстати, тоже для подобных целей использую одну)) Фирменная программа *nix. dd называется :)
Её одной недостаточно — место увеличилось. Если ФС позволяет и диск заполнен почти полностью, то будет тот же dd + xfs_growfs/…. А если диск не сильно заполнен или ФС не позволяет, то
tar c|tar x имеет больше смысла, так как вы не будете копировать с помощью dd данные, которые вам заведомо не нужны (при этом, разумеется, получите нелинейную запись с нелинейным чтением).А, действительно, какой-то занудный я, использую *nix программу в *nix way :D))
Дайте Samsung Data Migration)
Дайте Samsung Data Migration)
Зачем? Я просто указал на то, что только dd — это не замена Samsung Data Migration в данной ситуации. Нужна ещё программа для увеличения размера диска.
Если бы кто‐то внял вашему совету, то он бы был удивлён тем, что место не увеличилось.
Если бы кто‐то внял вашему совету, то он бы был удивлён тем, что место не увеличилось.
Вообще‐то
Так что нет, вы не используете программу в *nix way. Вам нужно создать новую ФС и перенести туда файлы. Вместо этого вы берёте один файл (в виде блочного устройства) и копируете его в другое место (другое блочное устройство).
Сколько своего времени вы потратите на resize, если цель больше, чем источник? Что будете делать с
dd — это утилита для копирования (и, возможно, некоторого изменения) одного файла. Одного. В документации так и написано: «dd — convert and copy a file» Это не средство переноса множества файлов. Это не средство для создания файловой системы. Средство для переноса — это cp (но tar’у я больше доверяю). Для создания — mkfs.Так что нет, вы не используете программу в *nix way. Вам нужно создать новую ФС и перенести туда файлы. Вместо этого вы берёте один файл (в виде блочного устройства) и копируете его в другое место (другое блочное устройство).
Сколько своего времени вы потратите на resize, если цель больше, чем источник? Что будете делать с
dd, если цель меньше, чем источник? Зачем вы вообще берёте с собой мусор из свободных блоков?Похоже, занудный здесь не я ;-)
Вы всегда написаное воспринимаете буквально?
Что для вас есть файл?
Вы всегда написаное воспринимаете буквально?
Что для вас есть файл?
Можете считать, что я использую определение из wikipedia. Скорее, более простое «именованная последовательность байт с определёнными операциями чтения и записи». (А изначально вообще собирался практически повторить определение для переменной — «именованная последовательность байт».)
Главный вопрос в том, какую задачу решаете вы, а какую — dd. Dd корректно решает задачу копирования данных на блочном устройстве. А нужен перенос файлов, с которыми работают ваши программы, на новое устройство, с новым размером. Даже если новое устройство имеет тот же размер, копирование зачастую уменьшает уровень фрагментации (и не переносит блоки с мусором).
Главный вопрос в том, какую задачу решаете вы, а какую — dd. Dd корректно решает задачу копирования данных на блочном устройстве. А нужен перенос файлов, с которыми работают ваши программы, на новое устройство, с новым размером. Даже если новое устройство имеет тот же размер, копирование зачастую уменьшает уровень фрагментации (и не переносит блоки с мусором).
может быть дело в «Утром с разбегу включил компьютер, проверил почту и Скайп.»-прислали что нибудь, может быть дело в том что самсунговская утилита миграции мочит жесткие диски конкурентов.
Охотно верю в теорию автора о том что данные на диски могли вызвать нестабильность работы самого диска, ибо такие примеры уже были: лет 5-6 назад была история про то, что при попытке записать на CD-R некий волшебный видео файл процесс записи обламывался и диск портился. Сначала никто не мог в это поверить а потом разобрались.
Охотно верю в теорию автора о том что данные на диски могли вызвать нестабильность работы самого диска, ибо такие примеры уже были: лет 5-6 назад была история про то, что при попытке записать на CD-R некий волшебный видео файл процесс записи обламывался и диск портился. Сначала никто не мог в это поверить а потом разобрались.
Sign up to leave a comment.
SSD винт отключается через 5 мин работы Или немыслимая логика SSD контроллера