Ошибки программирования худший штамп

Куратор(ы):  

KT   

Автор Сообщение
 
Прилепленное (важное) сообщение

СообщениеДобавлено: 05.09.2005 22:35 

[профиль]

Member

Статус: Не в сети
Регистрация: 06.05.2005
Откуда: Moldova

ПРОСЯ О ПОМОЩИ, ВЫКЛАДЫВАЙТЕ S.M.A.R.T. ПРОБЛЕМНОГО НАКОПИТЕЛЯ!

Его можно посмотреть программами Everest, AIDA 64, Victoria 4.x, Dtemp, HDDScan, HD Tune, Crystal Disk Info, SpeedFan… Обращайте внимание на DATA/RAW-параметры, это главные и основные показатели здоровья диска.

>>>При использовании Crystal Disk Info в меню Сервис>Дополнительно>Raw-значения выберите вариант «10 [DEC]» это несколько упростит восприятие информации утилиты форумчанами.<<<

<<Скриншоты>>

При выкладке скриншотов не забываем ограничения накладываемы пунктом 3.12 правил конференции. А именно: «Размещать в тегах «Img» картинки объемом свыше 500 кБ на сообщение. Допускаются картинки до 2 МБ под тегом «spoiler=«, а также прямые ссылки на картинки любого размера. Ссылки на страницы, где картинка отображается среди рекламы, запрещены, применяющие их сайты блокируются автоцензором.»
Немного о том, как ПРАВИЛЬНО создавать скриншоты для выкладки в форуме: http://forums.overclockers.ru/viewtopic … 4&t=373001

Для лучшего понимания сути вопроса смотрите информацию на первой странице темы, составленную камрадом Ing-Syst.

Так же помочь разобраться в показаниях СМАРТ может очень подробный материал размещенный на сайте ixbt.com: Оцениваем состояние дисков при помощи S.M.A.R.T.

Возможно, для решения Вашей проблемы потребуется провести цикл процедур утилитами Виктория и MHDD. Ссылки на инструкции по работе с программами можно найти на первой странице темы.

Связанные темы

[FAQ] Всё о винчестерах Western Digital
[FAQ] по винчестерам Seagate
[FAQ] Всё о винчестерах Hitachi
[FAQ] Всё о винчестерах Samsung

Восстановление данных
Ремонт HDD

Сигейт официально признал проблему с 7200.11

Полезные сообщения участников этой темы:

Обнуление некоторых параметров СМАРТ на винчестерах Samsung
Как найти файлы на которые приходятся кандидаты на ремап.
Отключение парковки на винчестерах Seagate 7200.14 без батников и автозагрузки (нуждается в проверке)
Remap и Advanced remap, erase и erase delays — назначение команд утилиты Victoria (1,2)
Смена режима контроллера с IDE на AHCI при наличии уже установленной операционной системы Win 7 Win XP

ShutUp — программа камрада CoolCMD для предотвращения частых парковок HDD.

https://disk.yandex.ru/d/x3UITAgo3EGqub

Программа считывает один сектор через определенный пользователем промежуток времени.

Учёт и поиск запчастей к жестким дискам — R.baza.

Последний раз редактировалось KT 29.11.2021 18:36, всего редактировалось 15 раз(а).

Реклама

Партнер
 
miro1674n

Member

Предупреждение 

Статус: Не в сети
Регистрация: 14.06.2018

clancy писал(а):

Живу в соседней стране в которой «иногда не до законов»

А ну если в соседней тогда сори. Тогда не знаю.

 
homerS

Junior

Статус: Не в сети
Регистрация: 27.11.2022

добрый день
подскажите что параметр в смарте
ID Описание атрибута Порог Значение Наихудшее Данные Статус
AD <зависит от поставщика> 1 1 1 1583 Внимание: превышен лимит использования или срок

 
miro1674n

Member

Предупреждение 

Статус: Не в сети
Регистрация: 14.06.2018

homerS SSD? Модель скажите. Можно даже было скрин самрта дать в программе Crystal Disk Info
Вообще это количество циклов перезаписи ячеек памяти ссд, всего ссд (или скорее количество стираний блоков, но суть та же).

 
int-997

Junior

Статус: Не в сети
Регистрация: 04.12.2022

Добрый день!
Прошу подсказать, в чем может быть проблема.
Купил в феврале HDD WD Blue 4 Tb. Поставил, некоторое время всё было в порядке. Затем стал замечать странности — подвисания при открытии и копировании файлов (диск использовался исключительно как хранилище для фоток и видео, без торрентов). Примерно через полгода поставил WD Dashboard и та показала наличие более 4000 тысяч ошибок CRC. Диск сдал в магазин, поменял на такой же.
Прошло ещё 2 месяца. С новым диском стала твориться та же история. Сходил опять в магазин, поменял уже на WD Purple 4 Tb.
И с первого же запуска увидел такую же проблему с зависанием при открытии/копировании. При этом провел тест в виктории — и все нормально (кроме одного предупреждения — «preset timeout limit«)! СМАРТ ничего не показывает. WD Dashboard или показывает, что всё нормально и все тесты пройдены, или же вообще не может завершить тест и выдаёт ошибку.
Да, когда диск долго не используется, он сначала раскручивается — это всё понятно и нормально. Но с какого ж он посреди записи может просто перестать определяться в диспетчере задач??
Не пойму, в чём дело. Проблемы по питанию? Но раньше у меня было не 2 хдд, а 3. И всё нормально работало. Шлейфы менял, переставлял с одного диска на другой — бесполезно. Драйверы? Винда? Или такая жуткая невезуха с WD? На что тогда поменять можно? Сигейты лично у меня когда-то сыпались в течение года-двух, я их поэтому уже лет 10 не покупаю.

 
Опричник

Member

Статус: Не в сети
Регистрация: 18.04.2018
Откуда: Советский Союз
Фото: 2

int-997 писал(а):

На что тогда поменять можно?

Лично я Тошиба пользуюсь уже много лет. Тоже неприязнь к Сигейтам имею. Рекомендую. Ну а модель выбирайте по кошельку, серию Х300 допустим.


_________________
i7-11700k/Gigabyte Z590 D/64Гб DDR4/RTX 3060/HP Z24n G3 — WUXGA/SSD 256Гб+3HDD (9Тб)/Win10

 
Sania.

Member

Статус: Не в сети
Регистрация: 22.12.2012
Фото: 1

int-997 писал(а):

Драйверы? Винда? Или такая жуткая невезуха с WD?

Скорее мать или проц или оперативка.

Добавлено спустя 3 минуты 30 секунд:

int-997 писал(а):

Проблемы по питанию? Но раньше у меня было не 2 хдд, а 3.

Это раньше, а теперь они дохнут и нужно возможно менять, тут нужно проверять.

 
int-997

Junior

Статус: Не в сети
Регистрация: 04.12.2022

Sania. писал(а):

Скорее мать или проц или оперативка.

Если так, то каким образом проверить?
Не пойму вот что — второй диск ведь работает нормально. Тоже WD, но на 1 Тб. Работает идеально и не первый год, причем на тех же самых шлейфах, что и новый 4 Тб (буквально на тех же самых, менял их местами).

 
Sania.

Member

Статус: Не в сети
Регистрация: 22.12.2012
Фото: 1

самый простой способ, подключить в другой компьютер, там и БП другой будет.

 
Cocoa

Member

Статус: Не в сети
Регистрация: 15.03.2017
Откуда: Канада
Фото: 24

Sania. писал(а):

самый простой способ, подключить в другой компьютер, там и БП другой будет.

Опередили меня. Также считаю, причём это самый верный и быстрый метод разобраться.
Насчёт сравнения WD 4TB с 1-террабайтником, — последние намного более выносливые, простонародно выражаясь.


_________________
i7-3770K, Noctua NH-U9S, G1.Sniper M3/Z77, G.Skill_4x8GB_F3-2400, Sapphire_RX460, Corsair_RM750-Gold, SilverStone-LC16MBM_HTPC, A/V Sony_STR-DH790 7.2

 
OLD Hunter

Member

Статус: Не в сети
Регистрация: 14.06.2009
Откуда: Омск

Здравствуйте. 870 evo 500gb тоже проблемные или от объема не зависит?

 
MaximillianGreat

Member

Статус: Не в сети
Регистрация: 18.02.2006

Есть ссд Colorful SL500 480GB, покупал давно на ебее.
Начал зависать в определнных местах. Прогнал викторией, там такое в нескольких местах.

Цитата:

20:14:42 : Get S.M.A.R.T. command… OK
20:14:43 : Drive reported: SMART status = GOOD
20:14:43 : Victoria reported: SMART status = Unideal
20:14:50 : Recallibration… OK
20:14:50 : Starting Reading, LBA=0..937694830, FULL, sequential access, timeout 10000ms
20:15:17 : Block start at 12337152 (6 GB) Read error: UNCR «Ошибка в данных (CRC)»

И после этого часто диск перестает отвечать. Мест таких на диске не много, штук 7. Reallocated sector count вроде растет

Начинка

Код:

v0.564a
Drive: 1(ATA)
OS: 6.3 build 9600
Model: Colorful SL500 480GB                   
Fw   : R0522A0
Size : 457858 MB [480.1 GB]
From smart : [SMI2258XT] [R0522A0 00] [IM00]
Controller : SM2258   bufferless
FlashID: 0x89,0xb4,0x78,0x32,0xaa,0x1,0x0,0x0 — Intel 32L(B0KB) TLC 384Gb/CE 384Gb/die
Channel: 3
CE     : 4
TotDie : 12
Plane  : 4
Die/Ce : 1
Ch map : 0x07
CE map : 0x0F
Inter. : 4
First Fblock  :    2
Total Fblock  :  548
Total Hblock  : 7155
Fblock Per Ce :  548
Fblock Per Die:  548
Original Spare Block Count :    80
Vendor Marked Bad Block    :     0
Bad Block From Pretest     :    11

Смарт

Код:

—————————————————————————-
 (02) Colorful SL500 480GB
—————————————————————————-
           Model : Colorful SL500 480GB
        Firmware : R0522A0
       Disk Size : 480,1 GB (8,4/137,4/480,1/480,0)
     Buffer Size : Неизвестно
     Queue Depth : 32
    # of Sectors : 937694831
   Rotation Rate : —- (SSD)
       Interface : Serial ATA
   Major Version : ACS-2
   Minor Version : ACS-2 Revision 3
   Transfer Mode : SATA/300 | SATA/600
  Power On Hours : 7332 ч
  Power On Count : 1177 раз
      Host Reads : 11264 GB
     Host Writes : 7267 GB
     NAND Writes : 8344 GB
     Temperature : 40 C (104 F)
   Health Status : Хорошо (100 %)
        Features : S.M.A.R.T., APM, NCQ, TRIM, GPL
       APM Level : 0080h [ON]
       AAM Level : —-
    Drive Letter : E:

— S.M.A.R.T. —————————————————————
ID Cur Wor Thr RawValues(6) Attribute Name
01 100 100 _50 000000000000 Частота ошибок чтения
05 100 100 _50 000000000010 Перераспределённые сектора
09 100 100 _50 000000001CA4 Часы работы
0C 100 100 _50 000000000499 Включения/отключения
A0 100 100 _50 000000000019 Невосстановимые сектора при чтении/записи
A1 100 100 _50 000000000050 Действующие запасные блоки
A3 100 100 _50 00000000000B Изначально недействительные блоки
A4 100 100 _50 0000000071C0 Всего стираний
A5 100 100 _50 000000000052 Максимум стираний
A6 100 100 _50 000000000003 Минимум стираний
A7 100 100 _50 000000000038 В среднем стираний
A8 100 100 _50 000000001B58 Максимум стираний по спецификации
A9 100 100 _50 000000000064 Оставшийся ресурс
AF 100 100 _50 000000000000 Ошибки программирования, худший штамп
B0 100 100 _50 000000000000 Ошибки стирания, худший штамп
B1 100 100 _50 000000000000 Всего операций Wear Leveling
B2 100 100 _50 000000000010 Недействительные блоки при работе
B5 100 100 _50 000000000000 Всего ошибок программирования
B6 100 100 _50 000000000000 Всего ошибок стирания
C0 100 100 _50 00000000006A Аварийные парковки при отключении питания
C2 100 100 _50 000000000028 Температура
C3 100 100 _50 00000007B47E Аппаратное ECC-восстановление
C4 100 100 _50 000000000019 События перераспределения
C5 100 100 _50 000000000010 Текущие нестабильные сектора
C6 100 100 _50 000000000019 Невосстановимые офлайн-ошибки
C7 100 100 _50 000000000003 CRC-ошибки Ultra DMA
E8 100 100 _50 000000000050 Доступное резервное место
F1 100 100 _50 000000038C7B Всего LBA записано
F2 100 100 _50 00000005800A Всего LBA прочитано
F5 100 100 _50 000000041300 Сектора записи флэш-памяти

————————————————————————————
  ID      Name                   Value  Worst  Tresh       Raw    Health
————————————————————————————
  1 Raw read error rate                 100    100     50                0   •••••
  5 Reallocated sector count            100    100     50               16   •••••
  9 Power-on time                       100    100     50             7332   •••••
 12 Start/stop count                    100    100     50             1177   •••••
160 Uncorrectable sector count read or write      100    100     50               25   •••••
161 Number of valid spare block         100    100     50               80   •••••
163 Number of initial invalid block      100    100     50               11   •••••
164 Total erase count                   100    100     50            29120   •••••
165 Maximum erase count                 100    100     50               82   •••••
166 Minimum erase count                 100    100     50                3   •••••
167 Average erase count                 100    100     50               56   •••••
168 Max NAND erase count from specification      100    100     50             7000   •••••
169 Total bad block count / SMI remain life (percentage)      100    100     50              100   •••••
175 SMI program fail count in worst die      100    100     50                0   •••••
176 Erase fail count in worst die       100    100     50                0   •••••
177 Wear leveling range percent         100    100     50                0   •••••
178 Used reserved block count (Chip)      100    100     50               16   •••••
181 Program Fail Count (Total)          100    100     50                0   •••••
182 Erase Fail Count (Total)            100    100     50                0   •••••
192 Unsafe shutdown count               100    100     50              106   •••••
194 Temperature controller              100    100     50       40°C/104°F   •••• 
195 Hardware ECC recovered              100    100     50           504956   •••••
196 Reallocated event count             100    100     50               25   •••••
197 Current pending sectors             100    100     50               16   •••••
198 Offline uncorrectable sectors count      100    100     50               25   •••••
199 Ultra DMA CRC errors                100    100     50                3   •••••
232 Available Reserved Space            100    100     50               80   •••••
241 Total sectors write                 100    100     50           232571   •••••
242 Total LBA read                      100    100     50           360458   •••••
245 Timed Workload Media Wear           100    100     50         4 / 4864   •••••

Хотелось бы починить его для неважных задач.
Что лучше делать? Ремапить в виктории? Прошивать? Или еще что?

И еще вопрос, может у Colorful какая-нибудь RMA есть по которой его можно попробовать обменять? Ну это я конечно совсем губу раскатал :D

 
miro1674n

Member

Предупреждение 

Статус: Не в сети
Регистрация: 14.06.2018

MaximillianGreat писал(а):

Что лучше делать? Ремапить в виктории? Прошивать? Или еще что?

SE сделать (диск сотрет все блоки), не размечать, посмотреть как изменится смарт, просканировать в виктории все сектора. Если не исправит дело, прописывать конкретно те участки где есть вот эти бэд-блоки. то есть выбирать в виктории запись и тот LBA где при сканировали зафиксировали бэд. Посмотреть переназначает ли при перезаписи, если переназначает, то дальше сканировать опять полностью чтобы проверить что больше нет сбойных блоков.

Я как-то так это представляю :?:.

 
O Smirnoff

Member

Статус: Не в сети
Регистрация: 11.11.2010
Откуда: Новосибирск

miro1674n писал(а):

SE сделать (диск сотрет все блоки), не размечать, посмотреть как изменится смарт, просканировать в виктории все сектора.

Нафига что-то пытаться «сканировать» на SSD после Secure Erase?!. :?:
Контроллер SSD читает только те физические блоки, которым сопоставлен LBA в трансляторе — но после процедуры SE таких просто нет.

miro1674n писал(а):

и тот LBA где при сканировали зафиксировали бэд.

Ещё один бред: физические блоки NAND никак не привязаны к какому-то конкретному LBA, на какой именно физический блок попадёт конкретный LBA — решает транслятор…


_________________
С уважением,
Олег Р. Смирнов

 
MaximillianGreat

Member

Статус: Не в сети
Регистрация: 18.02.2006

Хмм. Так, получается, мнения разделились :?:
Что делать то?

 
Lightwarrior

Member

Статус: Не в сети
Регистрация: 15.01.2013

O Smirnoff писал(а):

… Ещё один бред: физические блоки NAND никак не привязаны к какому-то конкретному LBA, на какой именно физический блок попадёт конкретный LBA — решает транслятор…

Другими словами на ССД все средства и методы для работы с битыми блоками которые применялись на ХДД целиком и полностью бесполезны. Можно не тратить время.

Если блок действительно неисправен (а не просто забыл данные, от чего поможет SE) то тут ровно 2 варианта — либо ССД его сам исключит из пула используемых блоков, либо ССД отправится в помойку.

MaximillianGreat писал(а):

Хмм. Так, получается, мнения разделились :?:
Что делать то?

Начать с SE, затем если хочется проверить то нужно сначала писать весь объём, а потом только пробовать читать.


_________________
https://valid.x86.fr/3597q9

 
O Smirnoff

Member

Статус: Не в сети
Регистрация: 11.11.2010
Откуда: Новосибирск

Lightwarrior писал(а):

если хочется проверить то нужно сначала писать весь объём, а потом только пробовать читать

Причём, писать не «0», а случайными паттернами (либо, как предлагает Victoria, писать в каждый LBA его номер.


_________________
С уважением,
Олег Р. Смирнов

 
MaximillianGreat

Member

Статус: Не в сети
Регистрация: 18.02.2006

Ага. :?: В TXbench получается СЕ не работает (диск перетыкал). Начинает и потом пишет «failed». Сработало стирание только через трим.
Как еще СЕ делать?

 
miro1674n

Member

Предупреждение 

Статус: Не в сети
Регистрация: 14.06.2018

O Smirnoff писал(а):

Контроллер SSD читает только те физические блоки, которым сопоставлен LBA в трансляторе — но после процедуры SE таких просто нет.

Прописать полностью, потом прочитать, не?

Добавлено спустя 1 минуту 23 секунды:

O Smirnoff писал(а):

Причём, писать не «0», а случайными паттернами

А какая разница? Не пишут нули только определённые контроллеры. 2258XT к ним не относится.

 
MaximillianGreat

Member

Статус: Не в сети
Регистрация: 18.02.2006

Так, после очистки тримом, диск полностью записался викторией и полностью прочитался без ошибок.
Смарт вроде особо не изменился. 196 и 198 добавили единичку, но это вроде еще до стирания.

Странно тогда устроены эти прошивки, если они не могут починить, то что тримом чинится :roll:

Кто сейчас на конференции

Сейчас этот форум просматривают: nox567, Voron33 и гости: 9

Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Лаборатория

Новости

  1. Цена: US $16.98 (брал за $9.65)
  2. Перейти в магазин

Всем привет! В конце ноября были хорошие скидки и я заказал SSD (пост о скидке) на 128 GB от WALRAM.
Ничего особенного не ждал, главное что бы работали и не глючили)
Брал 6 шт, в ноуты/компы ставить вместо жестких дисков (или в дополнение). Почти все поставил — все работают.
Посмотрим и протестируем, обзор краткий(больше отзыв).
Обычный дешевый SSD, не вижу смысла писать «много букв»)

Упаковка — запаянный пакет. Раньше, судя по информации из другого обзора, была картонная упаковка

Корпус изготовлен из пластика.

Разбирается легко. Внутри контроллер Yeestor YS9082HC, неожиданно, обычно SM2258XT ставят.
Память hynix TLC.


На странице товара указаны скорости в 560мб/с чтение и 490мб/с запись
CrystalDiskInfo

Посмотрим, что покажет SSD-Z

Тест в программе

Теперь CrystalDiskMark. Накопитель заполнен на четверть

Программа ATTO Disk Benchmark

Программа As SSD Benchmark

Проверим линейное чтение и запись в программе HD TUNE. Все настройки по умолчанию.
Чтение — постоянные 400 мб/с

Запись — на большей части объема ~ 300мб/с, потом упала.

Через 20 минут провел тест еще раз — результат изменился.

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

Спасибо за внимание!



Планирую купить

+7


Добавить в избранное

Обзор понравился

В истории программирования не всегда все было легко и безоблачно. Ведь любому программисту, вне зависимости от опыта и технического бэкграунда, трудно уберечься от ошибок и порой даже небольшого количества плохого кода хватало, чтобы вызвать серьезную проблему. «Библиотека программиста» немного полистала ИТ-летописи и нашла для вас 10 самых худших ошибок в истории кодинга. Поехали!

1. Ошибка 2000 года

⚠️💻 10 самых известных ошибок в коде в истории программирования

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

Суть проблемы заключалась в том, что большинство устаревших информационных систем, созданных еще в 70-х и 80-х, использовали только две цифры для исчисления года. Это значит, что часы внутри микропроцессоров различного аппаратного ПО регистрировали 1999 год как «99», основываясь на ошибочном предположении разработчиков прошлого, что мы всегда будем жить в 20-м веке и цифра «19» в обозначении года никогда не изменится.

Тогда все полагали, что в 2000 году у всех нас наверняка будут реактивные ранцы, еда в форме таблеток, футуристическая серебристая униформа и человечество к этому времени откажется от старых компьютерных систем середины века. Но чуда не случилось!

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

2. Терак-25

⚠️💻 10 самых известных ошибок в коде в истории программирования

Плохой код на самом деле может убить. Такая катастрофа произошла с аппаратом лучевой терапии Therac-25, произведенным компанией Atomic Energy of Canada, ставшего причиной гибели не менее шести пациентов. Расследование выявило недоработку системы, вызвавшую передозировку радиацией. Связано это было с трудностью проведения автоматизированных тестов такого специфического программного обеспечения. И поэтому машина, призванная помочь людям, стала машиной для убийств из научной фантастики. Этот случай заставил разработчиков ПО медицинской отрасли крайне ответственно подходить к тестированию такого оборудования.

3. Сеть AT&T выходит из строя

⚠️💻 10 самых известных ошибок в коде в истории программирования

15 января 1990 года около 50 процентов мобильной сети AT&T вышло из строя. За девять часов простоя более 75 миллионов звонков остались без ответа. И хотя в первоначальных отчетах следствия по этому делу значилось хакерская атака, на самом деле, виновником сего происшествия стало стандартное обновление ПО. Ошибка всего в одной строке кода стоила компании огромных денег. Все организации, целиком зависящие от наличия и качества связи, выставили AT&T иски с внушительными суммами. К примеру, крупнейший авиаперевозчик American Airlines, понес колоссальные финансовые убытки из-за того, что получил наполовину меньше звонков своих клиентов из-за сбоя. Авария 1990 года до сих пор служит прекрасным примером важности тестирования программного обеспечения и служит напоминанием о неразрывной связи между технологиями и экономической деятельностью большинства компаний.

4. Досрочное освобождение заключенных

⚠️💻 10 самых известных ошибок в коде в истории программирования

В 2005 году в США штате Мичиган произошел сбой тюремной программы, отвечающей за расчет срока наказания заключенных, в результате чего более 20 заключенных досрочно вышли на свободу. Программа ошибочно посчитала смягчающий коэффициент и снизила срок пребывания отбывающих наказание людей в несколько раз. Ошибку в коде заметили не сразу, а лишь по прошествии некоторого времени. И поэтому меру пресечения счастливчикам никто не пересчитывал. Среди них, к слову, не было матерых гангстеров и маньяков. В основном это были мелкие правонарушители, отбывавшие срок за неуплату алиментов, махинации с налогами и незаконное хранение психотропов.

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

5. Взрыв Ariane 5

⚠️💻 10 самых известных ошибок в коде в истории программирования

Случай произошел 4 июня 1996 года при первом запуске Ariane 5 — одной из самых надежных беспилотных ракетных установок, целью которой было изучение взаимодействия между солнечным ветром и магнитосферой Земли. Через 37 секунд после старта ракета, вылетевшая с космодрома, находящегося на берегах Французской Гвианы, развернулась на 90 градусов и всего через несколько секунд превратилась в огромный огненный шар.

Специальная группа прочесала место происшествия, собирая обломки, чтобы попытаться выяснить, что произошло. Через некоторое время техническая комиссия установила, что авария была вызвана программным сбоем.

Отказ системы произошел из-за полной потери информации о точности наведения ракеты и ориентации ее в пространстве, поступающей в центральный процессор. Потеря — следствие ошибки проектировщиков ПО и вызвана она была некорректным преобразованием 64-битного числа с плавающей запятой в 16-битное целое число.

К слову, целочисленное переполнение является широко распространенной ошибкой в ​​​​компьютерном программировании.

6. Ошибка Paypal

⚠️💻 10 самых известных ошибок в коде в истории программирования

Что бы вы сделали, если бы PayPal случайно зачислил на ваш счет 92 квадриллиона долларов? Крису Рейнольдсу, 56-летнему американцу, продающему автозапчасти на eBay, не пришлось долго об этом думать. Ведь он даже не успел ощутить себя первым в мире квадриллионером и самым богатым человеком в мире, так как ошибка была устранена в течение нескольких минут. Поэтому, прежде чем мужчина начал мечтать о новом кадиллаке и золотой карте члена королевского яхт-клуба, сумма на его счету вернулась к привычному балансу. Конечно, стоило бы потребовать с компании хотя бы часть этой суммы за моральный ущерб, но, видимо, шок от увиденного не позволил ему сделать это.

7. Калькулятор Windows

⚠️💻 10 самых известных ошибок в коде в истории программирования

Эта ошибка, существующая в большинстве версий Windows (кроме Windows 10), которую вы сможете проверить самостоятельно.

Для этого нужно:

  1. Открыть калькулятор Windows и ввести 4.
  2. Извлечь из этого числа квадратный корень и получите 2.
  3. Вычесть из него 2 и вместо нулевого результата в разных версиях Windows вы увидите разные результаты.

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

Microsoft признала эту ошибку в приложении калькулятора и исправила ее в Windows 10.

8. Проблема 2038 года

⚠️💻 10 самых известных ошибок в коде в истории программирования

Ошибка 2038 будет вызвана использованием 32-разрядных процессоров в 32-разрядных системах. Проще говоря, 19 января 2038 года наступит в 03:14:07. Компьютеры, которые все еще используют 32-разрядные системы для управления датой и временем, не смогут справиться с этим изменением. Как и в случае с ошибкой 2000 года, компьютеры не смогут отличить 2038 год от 1970 года.

Однако волноваться не стоит: почти все современные процессоры в настольных ПК имеют 64-битные системы с 64-битным программным обеспечением и в 2038 году само существование 32-битных систем будет под вопросом.

9. Видео Gangnam Style «сломало» YouTube

⚠️💻 10 самых известных ошибок в коде в истории программирования

Счетчик YouTube ранее использовал 32-битное целое число для определения максимального количества просмотров видеоролика, и равно оно было 2 147 483 647.

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

«Когда мы его делали, никогда не думали, что какое-нибудь видео посмотрят столько раз, но это было до Gangman Style», — написал на своей странице в сети один из разработчиков портала.

Клип PSY опубликовали 15 июля 2012 года и к концу мая 2014 года он стал единственным видеороликом, которой просмотрели больше 2 млрд раз.

В настоящее время YouTube использует 64-битное целое число для счетчика видео, что означает, что максимальное количество просмотров видео составляет 9,22 квинтиллиона.

10. Синий экран смерти

⚠️💻 10 самых известных ошибок в коде в истории программирования

BSOD или «Синий экран смерти» — жаргонное название фатальной системной ошибки Windows, показывающей системный сбой, при котором операционка достигала состояния, в котором она больше не могла надежно работать. Как правило, вызывалась она в Windows 95-98 после неожиданного завершения важного процесса или общего сбоя оборудования. Старожилы наверняка помнят этот баг, который довольно часто возникал на заре становления ИТ-культуры.

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

***

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

Материалы по теме

  • ⚠️ 10 самых распространенных ошибок, ежедневно допускаемых каждым программистом
  • ⚠️ Как не нужно учить TypeScript: 5 распространенных ошибок
  • 😢 Дорогостоящие ошибки: почему нам пришлось отказаться от Firebase

Как бы упорно мы не полагались на машины, они далеки от идеала. Как минимум, потому что сделаны человеком.

Пока программы не станут умнее людей, нам придётся следить за их состоянием постоянно. Особенно когда говорим об отвественном деле.

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

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

1. Система заживо похоронила 8 500 пациентов больницы в Мичигане

В 2003 году Медцентр Св. Марии Милосердия в городе Гранд-Рапидс обновил свою программу для учёта больных до новой версии. Из-за неверного толкования данных переменные «выписан» и «скончался» перепутались.

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

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

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

2. Обновление ПО лишило 60 тысяч человек междугородных звонков

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

Данные начали наслаиваться друг на друга, и проблема быстро распространилась по другим точкам. На обратном конце люди слышали только шум. Так продолжалось 9 часов.

Проблему решили откатом ПО до предыдущей версии, однако проблема не перестала быть актуальной.

Ситуация повторилась как минимум один раз в 1998 году, но тогда были затронуты только сервисные уведомления по SMS.

3. 5% всех магазинов России сломалось из‑за новой онлайн‑кассы

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

Сбои начались в салонах сети DNS во Владивостоке, где люди просыпаются раньше Москвы. Система не давала отправлять расчёты в Федеральную налоговую службу (ФНС), а из-за этого кассиры не имели права реализовывать товар.

Пока проблема добралась до столицы, откуда начал решаться вопрос, по всей России встали некоторые точки Магнита, Пятёрочки с Перекрёстком, Эльдорадо и аптек Ригла.

ФНС пришлось быстро реагировать и разрешать магазинам работать в офлайн режиме. Тем разрешили вносить данные после того, как система восстановится.

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

Теоретический ущерб, по мнению Ассоциации компаний интернет-торговли, мог дойти до 2,5 млрд рублей. Реальный оказался чуть ниже благодаря быстрой оптимизации процессов со стороны ФНС.

4. Машине дали проектировать стадион в Коннектикуте. Тот рухнул

С 1972 года город Хартфорд старался расширить свою инфраструктуру и вкладывался в крупные проекты. Одним из них стал Hartford Civic Center – комплекс торговых, развлекательных и спортивных площадок.

Структуру стадиона проектировали через программу, что вместе с оптимизированным расходом материалов сэкономило городу около $500 тысяч.

Комплекс полностью функционировал и даже был «домом» для местной хоккейной группы New England Whalers с 1975 года.

Однако утром 18 января 1978-го стадион обвалился. Игр в тот день не проходило: здание было пустым и никто не пострадал.

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

Четыре несущие колонны с момента возведения были плохо продуманы в размере и креплении. Стадион начал постепенно «складываться» ещё во время строительства, а группы по контролю качества распределялись между разными подрядчиками и плохо согласовали данные.

Восстановление стоило городу $90 млн. В последствии на месте комплекса возвели арену XL Center, которая до сих пор исполняет роль главной спортивной площадки Хартфорда.

5. Intel выпустила процессор с ошибкой и устроила международный скандал

В 1994 году CPU под брендом Pentium был флагманом компании, и в нём пряталась микроскопическая проблема, которая касалась крошечной части людей: когда пользователь делил одно число на другое, результат был неверным. Выглядела ошибка так:

Программисты неправильно настроили одну из веток операций, вшитых в процессор. Она искала корневые данные и находила не те.

При этом основной ущерб пришёлся не на пользователей, а на компанию.

Из-за того, что Intel уже тогда уверенно чувствовала себя на рынке, а чипы были новые, даже федеральные СМИ многих стран подхватили новость и нанесли катастрофический ущерб имиджу и доходу компании.

В итоге за 1994 год замена всех повреждённых процессоров сократила выручку компании вдвое от запланированной – на $475 млн.

6. 6 миллионов автомобилей могут не раскрыть воздушные подушки

В январе 2020 года выяснилось, что датчики в некоторых моделях компаний Toyota и Honda слишком чувствительны к электрическому шуму.

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

Проблема может быть глобальнее, поскольку компьютер из автомобилей Toyota разрабатывался сторонней организацией ZF-TRW. А она поставляла свои наработки как минимум шести компаниям в одних США, которые продали 12,3 млн машин.

Но пока только японские производители решили чинить датчики. И то, многие всё ещё ждут уведомления от своих диллеров.

7. MySpace уничтожил 50 миллионов песен пользователей

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

А в ходе переноса своей огромной библиотеки музыки, фотографий и видео возникла ошибка на сервере, которая их безвозвратно удалила.

Поскольку точной причины руководство не раскрыло, по поводу источника проблемы ходят разные слухи. Например, есть предположение, что хранить такой объём старых данных невыгодно и руководству было дешевле его «случайно» удалить.

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

8. 144 тысячи родителей-одиночек не получили государственных выплат

В апреле 2003 года британская компания по поддержке малообеспеченных и неполноценных семей Child Support Agency внедрила систему по фильтрации заявлений. Она стоила £300 млн.

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

Скандал длился как минимум до 2006 года, пока программа продолжала съедать 70% выделяемых на проект денег и затраты к 2010 году не составили £1,1 млрд.

В итоге в 2012 году агенство закрыли и вместо него запустили новую организацию Child Maintenance Group.

9. Уязвимость в защите 500 тысяч крупнейших сайтов давала доступ к вашей RAM

В апреле 2014 года специалисты по информационной безопасности обнаружили в библиотеке OpenSSL, на которой держится самый распространённый протокол HTTPS, критическую дыру в безопасности.

Её назвали Heartbleed по аналогии с процессом Heartbeat, взятым за основу этой ошибки.

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

И, хотя максимальный объём украденной информации не мог превышать 64 Кб за один запрос, этого хватало на доступ к паролям и конфиденциальным сообщениям.

Ошибка затронула 17% всех защищенных сайтов. В том числе Google, Facebook, Instagram, Twitter и даже Minecraft.

Опасность закрывалась простым патчем, поэтому многие компании отреагировали быстро.

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

10. Мир потратил $300 млрд, чтобы в 2000 году компьютеры продолжили работать

Фото Эмори Кристоф / Emory Kristof

До 1999 года системы программировали так, что одни отмечали даты форматом из 8 цифр (ЧЧ.ММ.ГГГГ), а другие оставляли 6.

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

Дата формата ЧЧ.ММ.ГГ могла заменить 2000 на 1900 год, поскольку оба числа кончаются на «ОО». Таким образом ошибка бы переписала и стёрла данные, нарушила работу алгоритмов и спровоцировала коллапс онлайн-систем.

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

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

Вокруг Проблемы 2000 года (или Y2K) было много разговоров, в том числе о целесообразности паники. Их подогревало то, что страны восприняли вопрос серьезно и прописывали инициативы на государственном уровне.

Например, Россия создала официальный документ Национальный план действий по решению “Проблемы 2000” в Российской Федерации.

Табло на последней строке «обнулилось» и показывает 1900 вместо 2000

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

64-х битных систем ситуация коснётся через 292 миллиарда лет, так что тут можно расслабиться.

Куда реальнее и скорее грозит Проблема 10 000 года своим переходом на значения из пяти цифр. Кажется, что не стоит о ней беспокоиться – пока вопрос ведь скорее теоретический.

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

Может, призадуматься и стоит.

1 Звезд2 Звезды3 Звезды4 Звезды5 Звезд (30 голосов, общий рейтинг: 4.77 из 5)

🤓 Хочешь больше? Подпишись на наш Telegram.

undefined

iPhones.ru


В последнем случае – миллиардов.

  • Подборки,
  • Это интересно

Павел avatar

Павел

@Tinelray

У меня 4 новых года: обычный, свой, WWDC и сентябрьская презентация Apple. Последний — самый ожидаемый, и ни капли за это не стыдно.

World of Warcraft когда-то страдал компьютерным вирусом другого рода. В 2005 году цифровая чума проникла на несколько игровых серверов. Тысячи персонажей стали жертвами Кровавого вируса. Разработчик WoW Blizzard представил Хаккара, бога Крови. Значительный враг заразил персонажей испорченной кровью. В то время как заражение крови первоначально предназначалось для поражения игроков в непосредственной близости от тела Хаккара, передача между игроками происходила за пределами области. Это непреднамеренное средство распространения вируса крови, порожденного внутриигровыми питомцами. Более того, неигровые персонажи (NPC) стали носителями.

Архимонд стал первым зараженным сервером. Низкоуровневые персонажи мгновенно умерли. Даже сильные персонажи не продержались долго. Хотя глюк кодирования увековечил вирус с помощью NPC и домашних животных, вирус не планировалось выпустить за пределы королевства Хаккар. В то время как тысячи игроков погибли, в World of Warcraft нет вечной смерти. Blizzard исправила вирус крови с помощью перезапуска сервера. Но не раньше, чем трупы игроков замусорили пейзаж WoW .

Почему это одна из худших ошибок в программировании? Хорошо, так что World of Warcraft может не представлять проблему безопасности данных или опасный для жизни сценарий — но геймеры серьезно относятся к своим развлечениям. Blizzard потратила часы на перезагрузку серверов. Интересно, что поведение игроков в игре имитировало то, что может произойти в реальной эпидемии с безудержной вспышкой, паникой и коллапсом цивилизации. Не играл в WoW ? Начните с этого полного руководства для новичка новичка новичка

В то время как многие ошибки программирования приводят к уязвимостям или мертвым игрокам в игре, плохой код на самом деле может убить. Катастрофа Therac-25 произошла с аппаратом лучевой терапии Therac-25. Произведенный Атомной энергией Канады, Therac-25 вызвал случайные передозировки, унесшие жизни по меньшей мере шести пациентов. Расследования обнаружили, что плохое программное обеспечение и недостаточная разработка системы вызывали передозировки радиации. Во многом это связано с трудностями при проведении автоматических тестов программного обеспечения .

Передозировки излучения Therac-25 служат напоминанием для создания кода, который легко тестируется. Машины, убивающие людей, могут звучать как научная фантастика, но инцидент с Therac-25 доказывает обратное. Но на самом деле это было результатом человеческой ошибки в кодировании, вызвавшей эти проблемы. Эксперты, в том числе Нэнси Левесон, обнаружили, что неопытные программисты создали программное обеспечение с ошибками. Более того, только один программист создал программное обеспечение, и оно было основано на коде из Therac-6 и Therac-20.

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

5. Полет древнего моряка 1

НАСА использует немало технологий. Его New Horizons Probe использует процессор PlayStation. Вице-президент по архитектуре и проектированию решений в NVIDIA Марк Хэмилтон регулярно пишет в блоге об использовании НАСА оборудования NVIDIA. Ракета Mariner 1 запущена с космическим зондом, предназначенным для исследования Венеры. Однако, после запуска ракета немного отклонилась от предполагаемой траектории полета. Моряк 1 был уничтожен вскоре после взлета.

Небольшая ошибка программиста вызвала ошибку Mariner 1. Хотя отчеты отличаются, знаки указывают на отсутствующий дефис. Согласно архивным документам НАСА «Совет по проверке после полета« Моряк-1 »установил, что пропуск дефиса в кодированных компьютерных инструкциях в программе редактирования данных позволил передавать неправильные сигналы наведения на космический корабль». Известный автор Артур Кларк ( 2001) (Космическая Одиссея ) назвал катастрофу Mariner 1 «самым дорогим дефисом в истории».

Почему это одна из худших ошибок в программировании: ошибки Mariner 1 можно было легко избежать. Объявление о государственной службе: уважаемые разработчики, пожалуйста, проверьте свое программное обеспечение.

6. Сеть AT & T выходит из строя

AT & T-сети вниз

Изображение предоставлено: Unsplash через Pixabay

Сейчас ты меня слышишь? Нет. 15 января 1990 года более 50 процентов сети AT & T вышли из строя. За девять часов 75 миллионов звонков остались без ответа. В то время как первоначальные сообщения обвиняли хакеров, фактический виновник был намного хуже: стандартное обновление программного обеспечения. Помните об этом, когда вы в следующий раз будете жаловаться на обновления Windows 10. Обновления Ошибка только в одной строке кода привела к падению сети AT & T на несколько часов. Сам коммутатор сбрасывался, но ошибка означала, что второй коммутатор отправил другое сообщение. По сути, эффект домино начался с сети, продолжающей повторять свою ошибку. В конечном итоге AT & T разработала решение, уменьшив нагрузку на сеть. Затем переключатели сбрасываются сами.

Несмотря на тяжелые испытания, единственное утверждение нанесло ущерб сети. Программа была написана на языке C. Оператор break внутри предложения if остался вложенным в предложение switch. Большой сбой AT & T 1990 года кажется простой проблемой. Множество пропущенных звонков или, как было бы сегодня, куча пропущенных текстов, Instagram, Twitter и уведомления Snapchat. Тем не менее, отсутствие связи несет огромные денежные последствия. Такие компании, как American Airlines, понесли финансовые потери. Американские авиалинии получили на две трети меньше звонков из-за сбоя. Отключение 1990 года продолжает служить отличным примером того, почему тестирование важно. Кроме того, отключение AT & T служит напоминанием о неразрывной связи между технологиями и экономикой.

Почему это одна из худших ошибок в программировании: сеть AT & T не только рухнула, но и несколько часов, которые она провела, привели к финансовому краху.

7. День живых мертвецов: Госпиталь милосердия Святой Марии

Стартовые mercys-Фо-мертвый

Изображение предоставлено: Vitalworks через Pixabay

В 2003 году программный сбой неправильно «убил» 8500 человек. Медицинский центр Святой Марии Милосердия в Гранд-Рапидсе, штат Мичиган, ошибочно сообщил, что многие пациенты погибли из-за сбоя в их программной системе управления пациентами. Это плохое кодовое бедствие довольно безобидно по сравнению со смертельным исходом в Therac-25, поскольку никто на самом деле не погиб. Тем не менее, чтение о вашей собственной смерти вызывает смущение — особенно когда вы живы и здоровы.

Отчеты о ложной смерти не ограничивались пациентами. Эта переписка шла в страховые компании и офисы социального обеспечения. Поскольку поставщики услуг социального обеспечения и страхования гарантируют, что подходящие пациенты имеют Medicare, это представляло собой довольно большую проблему. Служащие Милосердия Марии проинформировали пациентов, государственные учреждения и страховые компании об ошибке. В конечном счете ошибка программирования не привлекла большого внимания. Неясно, была ли когда-либо исправлена ​​ошибка кодирования. Однако никаких дальнейших ложных сообщений о смерти не появилось. Госпиталь Святой Марии просто поменял программное обеспечение для управления пациентами.

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

8. Заключенный пре-альфа: досрочное освобождение

тюремная случайно-релиз

Кредит изображения: Alexas_Fotos через Pixabay

В период между 2003 и 2005 годами в Мичигане произошел сбой в обработке данных. За это время из-за недостатка компьютерного программирования было досрочно освобождено 23 заключенных, что привело к сокращению сроков заключения для заключенных штата Мичиган. Удачливые заключенные получали выгоду от сокращенных сроков с 39 до 161 дня. Хотя любое случайное прекращение тюремного заключения является проблематичным, к счастью, это были мелкие нарушения, такие как обвинения в наркотиках и растрате.

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

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

9. Хартфордский Колизей Фолс

Хотя обрушение Хартфордского Колизея в 1978 году обошлось в 90 миллионов долларов, оно могло быть значительно хуже. Колизей Хартфорда рухнул через несколько часов после того, как фанаты покинули помещение. Его стальная решетчатая крыша не выдержала тяжести мокрого снега. Здание рухнуло из-за простой ошибки программирования. Кодировщик программного обеспечения САПР, использованного для проектирования Колизея Хартфорда, не смог учесть несколько переменных. Вместо этого программист предположил, что стальные опоры крыши будут подвергаться только чистому сжатию.

Инженеры сталкиваются со многими проблемами. Использование программного обеспечения должно облегчить их работу. Однако отсутствие учета нескольких переменных приводит к огромным проблемам. Хотя вы можете просто исправить ошибку в Minecraft , программное обеспечение САПР напрямую влияет на структуры реального мира.

Почему это одна из худших ошибок программирования: ну, по крайней мере, никто не умер. Но экономическое опустошение, оцениваемое в 90 миллионов долларов, огромно.

10. У меня 99 проблем, а Pentium — один

Как правило, процессоры Intel могут похвастаться лучшей производительностью, чем аналоги AMD. Тем не менее, AMD предлагает отличное соотношение цены и производительности Но в 1994 году микропроцессоры Intel Pentium столкнулись с серьезной проблемой. Процессоры 486DX и Pentium оснащены модулем с плавающей запятой (FPU). Этот FPU был математическим сопроцессором. Процессоры Intel предыдущего поколения обрабатывали математику с целыми числами. Благодаря встроенному FPU этот чип Pentium следующего поколения обещал значительно более быстрые численные вычисления.

В Pentium FPU использовался алгоритм STRX 4 STRX. Неправильно введенная информация вызвала немного некорректные расчеты. Но даже незначительное изменение может означать огромные проблемы, которые проявляются в случае коллапса Хартфорда или Therac-25. Приблизительно пять записей из тысячи были опущены, отбрасывая длинные возможности подразделения Pentium. Корпорация Intel официально заявила, что ошибка сценариев вызвала проблемы с поиском. В любом случае математика Pentium приписывается плохому коду.

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

Плохо для кода: ошибки в программировании

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

Существует множество примеров ошибок в программировании. Некоторые из них довольно безобидны, как ошибка World of Warcraft . Другие приводят к смерти либо реальной (Therac-25), либо воображаемой (Святой Марии). Не позволяйте этим знаменитым примерам удерживать вас от кодирования. Ознакомьтесь с этим руководством по выбору правильного языка веб-программирования.

Какие исторические примеры плохого кода вы помните? Оставьте комментарий ниже с вашими выборами ошибок программирования!

Изображение предоставлено: nouskrabs и McIek через Shutterstock.com

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

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

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

  • Ваш набор инструментов для борьбы с ошибками
    • Оператор печати
    • Отладчик
    • Система отслеживания ошибок
    • Верификация программ
    • Контроль версий
    • Модульность
    • Автоматизированные тесты
    • Метод «Плюшевый мишка» (или отладка «Резиновая уточка»)
    • Пишите комментарии к коду
    • Пишите документацию
  • На пути к мастерству: избавляемся от ошибок

Инструмент номер один для отладки кода – это опробованный и верный способ вставки операторов печати. В качестве равнозначной замены, для случаев, когда операторов печати много, и ими трудно управлять, может быть использована система протоколирования вместо операторов печати. Во многих языках программирования для этого есть в свободном доступе специальные библиотеки, как, например, библиотека logging, встроенная в Python.

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

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

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

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

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

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

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

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

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

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

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

Использование верификации позволяет значительно сэкономить время по отслеживанию источника неисправности, вызванных синтаксическими ошибками, опечатками, и некорректными типами данных. Чтобы получить более полное представление о возможностях верификатора, посмотрите Pyflakes, верификатор для Python.

Также как и использование системы отслеживания ошибок, применение системы контроля версии – это самая лучшая практика в разработке программного обеспечения, которая не может быть игнорирована при разработке любого проекта значительного размера.

Системы контроля версии, такие как Git, Mercurial и SVN, позволяют разным версиям базы кода быть разделенными, основываясь на том, над чем работают или кто разрабатывает код. Разные версии могут быть объединены вместе, поэтому несколько программистов могут работать с базой кода в одно то же время, не создавая ошибки, которые могли бы повлиять на ход работы остальных разработчиков.

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

Плохо спроектированный код – это главный источник трудно исправляемых ошибок. Если код легко понять, и он может быть «выполнен» в уме или на бумаге, есть большая вероятность, что программисты смогут быстро находить и исправлять ошибки.

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

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

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

Модульные тесты и другие типы автоматизированных тестов идут рука об руку с модульным программированием.

Автоматизированный код – это участок кода, который выполняет программу с определенными входными параметрами и проверяет, соответствует ли поведение программы ожидаемому.

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

Существует много фреймворков для тестирования, которые делают написание тестов легче. Многие из известных фреймворков, используемых сегодня, были получены из библиотеки JUnit, написанной Кентом Бентом (Kent Bent), одним из первых сторонников идеи разработки через тестирование. Стандартная библиотека Python включает свою версию JUnit под именем PyUni или просто unittest.

Если верить легендам программирования Брайану Кернигану и Робу Пайку (Brain Kernighan и Rob Pike), отладка по типу «Резиновая уточка» возникла в университетском компьютерном центре, где студенты должны были садиться напротив плюшевого мишки и объяснять ему их ошибки, прежде чем обращаться за помощью к живому человеку.

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

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

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

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

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

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

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

Программирование – это, прежде всего, искусство. И также как для любого другого вида искусства, путь к мастерству в нем вымощен трудолюбием и стремлением учиться. Работа по изучению программирования никогда не заканчивается. Всегда есть что-то новое для изучения и новые способы по улучшению.

Какими из этих 10 средств отладки вы пользуетесь сейчас? Какими вы могли бы начать пользоваться с сегодняшнего дня? Какие из этих инструментов требуют времени на практику и освоения новых навыков?

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

Improve Article

Save Article

  • Read
  • Discuss
  • Improve Article

    Save Article

    Although C does not provide direct support to error handling (or exception handling), there are ways through which error handling can be done in C. A programmer has to prevent errors at the first place and test return values from the functions.
    A lot of C function calls return a -1 or NULL in case of an error, so quick test on these return values are easily done with for instance an ‘if statement’. For example, In Socket Programming, the returned value of the functions like socket(), listen() etc. are checked to see if there is an error or not.

    Example: Error handling in Socket Programming

    if ((server_fd = socket(AF_INET, SOCK_STREAM, 0)) == 0)
    {
       perror("socket failed");
       exit(EXIT_FAILURE);
    }
    

    Different methods of Error handling in C

    1. Global Variable errno: When a function is called in C, a variable named as errno is automatically assigned a code (value) which can be used to identify the type of error that has been encountered. Its a global variable indicating the error occurred during any function call and defined in the header file errno.h.
      Different codes (values) for errno mean different types of errors. Below is a list of few different errno values and its corresponding meaning:
      errno value       Error
      1             /* Operation not permitted */
      2             /* No such file or directory */
      3             /* No such process */
      4             /* Interrupted system call */
      5             /* I/O error */
      6             /* No such device or address */
      7             /* Argument list too long */
      8             /* Exec format error */
      9             /* Bad file number */
      10            /* No child processes */
      11            /* Try again */
      12            /* Out of memory */
      13            /* Permission denied */
      
      

      #include <stdio.h>

      #include <errno.h>

      int main()

      {

          FILE * fp;

          fp = fopen("GeeksForGeeks.txt", "r");

          printf(" Value of errno: %dn ", errno);

          return 0;

      }

      Output:

      Value of errno: 2
      

      Note: Here the errno is set to 2 which means – No such file or directory. On online IDE it may give errorno 13, which says permission denied.

    2. perror() and strerror(): The errno value got above indicate the types of error encountered.
      If it is required to show the error description, then there are two functions that can be used to display a text message that is associated with errorno. The functions are:
      • perror: It displays the string you pass to it, followed by a colon, a space, and then the textual representation of the current errno value.
        Syntax:
        void perror (const char *str)
        str: is a string containing a custom message
        to be printed before the error message itself.
      • strerror(): returns a pointer to the textual representation of the current errno value.
        Syntax:
        char *strerror (int errnum)
        errnum: is the error number (errno).

      #include <stdio.h>

      #include <errno.h>

      #include <string.h>

      int main ()

      {

          FILE *fp;

          fp = fopen(" GeeksForGeeks.txt ", "r");

          printf("Value of errno: %dn ", errno);

          printf("The error message is : %sn"

                               strerror(errno));

          perror("Message from perror");

          return 0;

      }

      Output:
      On Personal desktop:

      Value of errno: 2
      The error message is : No such file or directory
      Message from perror: No such file or directory
      

      On online IDE:

       Value of errno: 13
      The error message is : Permission denied
      

      Note: The function perror() displays a string passed to it, followed by a colon and the textual message of the current errno value.

    3. Exit Status: The C standard specifies two constants: EXIT_SUCCESS and EXIT_FAILURE, that may be passed to exit() to indicate successful or unsuccessful termination, respectively. These are macros defined in stdlib.h.

      #include <stdio.h>

      #include <errno.h>

      #include <string.h>

      #include <stdlib.h>

      int main ()

      {

          FILE * fp;

          fp = fopen ("filedoesnotexist.txt", "rb");

          if (fp == NULL)

          {

              printf("Value of errno: %dn", errno);

              printf("Error opening the file: %sn",

                                   strerror(errno));

              perror("Error printed by perror");

              exit(EXIT_FAILURE);

              printf("I will not be printedn");

          }

          else

          {

              fclose (fp);

              exit(EXIT_SUCCESS);

              printf("I will not be printedn");

          }

          return 0;

      }

      Output:

      Value of errno: 2
      Error opening the file: No such file or directory
      Error printed by perror: No such file or directory
      
    4. Divide by Zero Errors: A common pitfall made by C programmers is not checking if a divisor is zero before a division command. Division by zero leads to undefined behavior, there is no C language construct that can do anything about it. Your best bet is to not divide by zero in the first place, by checking the denominator.

      #include<stdio.h>

      #include <stdlib.h>

      void function(int);

      int main()

      {

          int x = 0;

          function(x);

          return 0;

      }

      void function(int x)

      {

          float fx;

          if (x==0)

          {

              printf("Division by Zero is not allowed");

              fprintf(stderr, "Division by zero! Exiting...n");

              exit(EXIT_FAILURE);

          }

          else

          {

              fx = 10 / x;

              printf("f(x) is: %.5f", fx);

          }

      }

      Output:

      Division by Zero is not allowed

    This article is contributed by MAZHAR IMAM KHAN. If you like GeeksforGeeks and would like to contribute, you can also write an article using contribute.geeksforgeeks.org or mail your article to contribute@geeksforgeeks.org. See your article appearing on the GeeksforGeeks main page and help other Geeks.

    Please write comments if you find anything incorrect, or you want to share more information about the topic discussed above.

    Студворк — интернет-сервис помощи студентам

    Здравствуйте, у меня такая проблема.
    На днях чистил комп от пыли, и черт меня дернул подуть в ЖД (внутрь, между платой и крышкой этой). После этого пару часов всё было нормально. Потом решил скачать игру в стиме и во время скачивания начал слышать как ЖД выключается и включается каждые 3-5 секунд. Глянул скорость чтения/записи — она скачет от нуля до максимума в такт включениям и выключениям. Выключил комп, перевтыкнул провода sata, включил, проблема ушла. Открыл CrystalDisk, он обнаружил проблему — 2 нестабильных сектора. В свойствах ЖД в винде нажал просканировать и восстановить. Винда написала, что ошибки есть, потом вроде бы исправила их. В CrystalDisk всё осталось по-прежнему — значение два в С5. Дальше комп проработал нормально. Весь след. день, часов 14, проработал так же, за день температура диска выросла с ~30 утром до ~37 вечером, а потом я услышал как он опять выключается периодически и в этот момент зависала игра на пару секунд. Открыл CrystalDisk, а там данные уже немного поменялись (на скрине и копия текстом ниже).
    ОС стоит на ссд, с ним всё нормально.

    Кликните здесь для просмотра всего текста

    —————————————————————————-
    CrystalDiskInfo 8.8.6 (C)
    —————————————————————————-

    OS : Windows 10 Professional [10.0 Build 19042] (x64)
    Date : 2022/03/27 11:08:25

    — Controller Map ———————————————————-
    — Стандартный контроллер SATA AHCI [ATA]
    + Стандартный контроллер SATA AHCI [ATA]
    — WDC WD5000AAKX-001CA0
    — DeTech SSD 240GB
    — Контроллер дискового пространства (Майкрософт) [SCSI]

    — Disk List —————————————————————
    (01) WDC WD5000AAKX-001CA0 : 500,1 GB [0/0/0, pd1]
    (02) DeTech SSD 240GB : 240,0 GB [1/0/0, pd1] — sm

    —————————————————————————-
    (01) WDC WD5000AAKX-001CA0
    —————————————————————————-
    Model : WDC WD5000AAKX-001CA0
    Firmware : 03.03B.3
    Serial Number : WD-WMAYUS432120
    Disk Size : 500,1 GB (8,4/137,4/500,1/500,1)
    Buffer Size : 16384 KB
    Queue Depth : 32
    # of Sectors : 976773168
    Rotation Rate : Неизвестно
    Interface : Serial ATA
    Major Version : ATA8-ACS
    Minor Version : —-
    Transfer Mode : SATA/300 | SATA/300
    Power On Hours : 5662 ч
    Power On Count : 1306 раз
    Temperature : 29 C (84 F)
    Health Status : Тревога!
    Features : S.M.A.R.T., AAM, NCQ
    APM Level : —-
    AAM Level : 8080h [ON]
    Drive Letter : D: E:

    — S.M.A.R.T. —————————————————————
    ID Cur Wor Thr RawValues(6) Attribute Name
    01 200 200 _51 0000000004A9 Частота ошибок чтения
    03 184 139 _21 0000000006DE Время раскрутки
    04 _99 _99 __0 0000000006A4 Запуски/остановки шпинделя
    05 200 200 140 000000000000 Переназначенные сектора
    07 100 253 _51 000000000000 Частота ошибок позиционирования
    09 _93 _93 __0 00000000161E Часы работы
    0A 100 100 _51 000000000000 Повторные попытки раскрутки
    0B 100 100 _51 000000000000 Повторы рекалибровки
    0C _99 _99 __0 00000000051A Включения/отключения
    B8 100 100 _97 000000000000 Ошибки End-to-End
    BB _99 __1 __0 0000000004CF Неисправимые ошибки
    BC _99 __1 __0 0003000304A1 Таймаут команды
    BE _71 _56 __0 00000000001D Температура воздушного потока
    C0 200 200 __0 00000000004B Аварийные парковки при отключении питания
    C1 200 200 __0 000000000658 Полных циклов парковок головок
    C2 114 _99 __0 00000000001D Температура
    C3 200 200 __0 000000000000 Аппаратное ECC-восстановление
    C4 200 200 __0 000000000000 События переназначения
    C5 200 200 __0 000000000013 Нестабильные сектора
    C6 200 200 __0 000000000013 Неисправимые ошибки секторов
    C7 200 200 __0 000000000000 CRC-ошибки UltraDMA
    C8 200 200 _51 00000000000C Частота ошибок записи

    — IDENTIFY_DEVICE ———————————————————
    0 1 2 3 4 5 6 7 8 9
    000: 427A 3FFF C837 0010 0000 0000 003F 0000 0000 0000
    010: 5744 2D57 4D41 5955 5334 3332 3132 3020 2020 2020
    020: 0000 8000 0032 3033 2E30 3342 2E33 5744 4320 5744
    030: 3530 3030 4141 4B58 2D30 3031 4341 3020 2020 2020
    040: 2020 2020 2020 2020 2020 2020 2020 8010 0000 2F00
    050: 4001 0000 0000 0007 3FFF 0010 003F FC10 00FB 0110
    060: FFFF 0FFF 0000 0007 0003 0078 0078 0078 0078 0000
    070: 0000 0000 0000 0000 0000 001F 1706 0004 0044 0040
    080: 01FE 0000 7469 7F01 4123 7469 BE01 4123 407F 0000
    090: 0000 0000 0000 0000 8080 0000 0000 0000 0000 0000
    100: 6030 3A38 0000 0000 0000 0000 0000 0000 5001 4EE0
    110: 0341 3058 0000 0000 0000 0000 0000 0000 0000 4018
    120: 4018 0000 0000 0000 0000 0000 0000 0000 0000 0000
    130: 0000 0000 0000 16FE 0125 0000 0000 0000 0000 0000
    140: 0000 0000 0004 0000 0000 0000 0000 0000 0000 0000
    150: 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000
    160: 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000
    170: 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000
    180: 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000
    190: 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000
    200: 0000 0000 0000 0000 0000 0000 3037 0000 0000 0000
    210: 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000
    220: 0000 0000 101E 0000 0000 0000 0000 0000 0000 0000
    230: 0000 0000 0000 0000 0001 1000 0000 0000 0000 0000
    240: 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000
    250: 0000 0000 0000 0000 0000 35A5

    — SMART_READ_DATA ———————————————————
    +0 +1 +2 +3 +4 +5 +6 +7 +8 +9 +A +B +C +D +E +F
    000: 10 00 01 2F 00 C8 C8 A9 04 00 00 00 00 00 03 27
    010: 00 B8 8B DE 06 00 00 00 00 00 04 32 00 63 63 A4
    020: 06 00 00 00 00 00 05 33 00 C8 C8 00 00 00 00 00
    030: 00 00 07 2F 00 64 FD 00 00 00 00 00 00 00 09 32
    040: 00 5D 5D 1E 16 00 00 00 00 00 0A 33 00 64 64 00
    050: 00 00 00 00 00 00 0B 32 00 64 64 00 00 00 00 00
    060: 00 00 0C 32 00 63 63 1A 05 00 00 00 00 00 B8 33
    070: 00 64 64 00 00 00 00 00 00 00 BB 32 00 63 01 CF
    080: 04 00 00 00 00 00 BC 32 00 63 01 A1 04 03 00 03
    090: 00 00 BE 22 00 47 38 1D 00 00 00 00 00 00 C0 32
    0A0: 00 C8 C8 4B 00 00 00 00 00 00 C1 32 00 C8 C8 58
    0B0: 06 00 00 00 00 00 C2 22 00 72 63 1D 00 00 00 00
    0C0: 00 00 C3 36 00 C8 C8 00 00 00 00 00 00 00 C4 32
    0D0: 00 C8 C8 00 00 00 00 00 00 00 C5 32 00 C8 C8 13
    0E0: 00 00 00 00 00 00 C6 30 00 C8 C8 13 00 00 00 00
    0F0: 00 00 C7 32 00 C8 C8 00 00 00 00 00 00 00 C8 09
    100: 00 C8 C8 0C 00 00 00 00 00 00 00 00 00 00 00 00
    110: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    120: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    130: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    140: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    150: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    160: 00 00 00 00 00 00 00 00 00 00 82 00 58 20 01 7B
    170: 03 00 01 00 02 54 05 00 00 00 00 00 00 00 00 00
    180: 00 00 01 02 00 00 00 00 00 00 00 00 00 00 00 00
    190: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    1A0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    1B0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    1C0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    1D0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    1E0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    1F0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 F3

    — SMART_READ_THRESHOLD —————————————————-
    +0 +1 +2 +3 +4 +5 +6 +7 +8 +9 +A +B +C +D +E +F
    000: 10 00 01 33 C8 C8 00 00 00 00 00 00 00 00 03 15
    010: 00 00 00 00 00 00 00 00 00 00 04 00 00 00 00 00
    020: 00 00 00 00 00 00 05 8C 00 00 00 00 00 00 00 00
    030: 00 00 07 33 64 64 00 00 00 00 00 00 00 00 09 00
    040: 00 00 00 00 00 00 00 00 00 00 0A 33 00 00 00 00
    050: 00 00 00 00 00 00 0B 33 00 00 00 00 00 00 00 00
    060: 00 00 0C 00 00 00 00 00 00 00 00 00 00 00 B8 61
    070: 00 00 00 00 00 00 00 00 00 00 BB 00 00 00 00 00
    080: 00 00 00 00 00 00 BC 00 00 00 00 00 00 00 00 00
    090: 00 00 BE 00 00 00 00 00 00 00 00 00 00 00 C0 00
    0A0: 00 00 00 00 00 00 00 00 00 00 C1 00 00 00 00 00
    0B0: 00 00 00 00 00 00 C2 00 00 00 00 00 00 00 00 00
    0C0: 00 00 C3 00 C8 C8 00 00 00 00 00 00 00 00 C4 00
    0D0: 00 00 00 00 00 00 00 00 00 00 C5 00 00 00 00 00
    0E0: 00 00 00 00 00 00 C6 00 07 0C 00 00 00 00 00 00
    0F0: 00 00 C7 00 00 00 00 00 00 00 00 00 00 00 C8 33
    100: C8 C8 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    110: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    120: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    130: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    140: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    150: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    160: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    170: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    180: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    190: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    1A0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    1B0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    1C0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    1D0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    1E0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    1F0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 55

    —————————————————————————-
    (02) DeTech SSD 240GB
    —————————————————————————-
    Model : DeTech SSD 240GB
    Firmware : S0918A0
    Serial Number : 2020041700077
    Disk Size : 240,0 GB (8,4/137,4/240,0/240,0)
    Buffer Size : Неизвестно
    Queue Depth : 32
    # of Sectors : 468862128
    Rotation Rate : —- (SSD)
    Interface : Serial ATA
    Major Version : ACS-3
    Minor Version : ACS-3 Revision 4
    Transfer Mode : SATA/600 | SATA/600
    Power On Hours : 4868 ч
    Power On Count : 1263 раз
    Host Reads : 8288 GB
    Host Writes : 6820 GB
    NAND Writes : 7530 GB
    Temperature : 30 C (86 F)
    Health Status : Хорошо (89 %)
    Features : S.M.A.R.T., APM, NCQ, TRIM
    APM Level : 0000h [OFF]
    AAM Level : —-
    Drive Letter : C:

    — S.M.A.R.T. —————————————————————
    ID Cur Wor Thr RawValues(6) Attribute Name
    01 100 100 _50 000000000000 Частота ошибок чтения
    05 100 100 _50 000000000000 Перераспределённые сектора
    09 100 100 _50 000000001304 Часы работы
    0C 100 100 _50 0000000004EF Включения/отключения
    A0 100 100 _50 000000000000 Невосстановимые сектора при чтении/записи
    A1 100 100 _50 000000000064 Действующие запасные блоки
    A3 100 100 _50 000000000018 Изначально недействительные блоки
    A4 100 100 _50 00000001CDFC Всего стираний
    A5 100 100 _50 000000000404 Максимум стираний
    A6 100 100 _50 000000000007 Минимум стираний
    A7 100 100 _50 0000000000A6 В среднем стираний
    A8 100 100 _50 0000000005DC Максимум стираний по спецификации
    A9 100 100 _50 000000000059 Оставшийся ресурс
    AF 100 100 _50 000000000000 Ошибки программирования, худший штамп
    B0 100 100 _50 000000000000 Ошибки стирания, худший штамп
    B1 100 100 _50 000000000000 Всего операций Wear Leveling
    B2 100 100 _50 000000000000 Недействительные блоки при работе
    B5 100 100 _50 000000000000 Всего ошибок программирования
    B6 100 100 _50 000000000000 Всего ошибок стирания
    C0 100 100 _50 00000000004A Аварийные парковки при отключении питания
    C2 100 100 _50 00000000001E Температура
    C3 100 100 _50 00000001EF7B Аппаратное ECC-восстановление
    C4 100 100 _50 000000000000 События перераспределения
    C5 100 100 _50 000000000000 Текущие нестабильные сектора
    C6 100 100 _50 000000000000 Невосстановимые офлайн-ошибки
    C7 100 100 _50 000000000000 CRC-ошибки Ultra DMA
    E8 100 100 _50 000000000064 Доступное резервное место
    F1 100 100 _50 000000035484 Всего LBA записано
    F2 100 100 _50 000000040C1D Всего LBA прочитано
    F5 100 100 _50 00000003AD4D Сектора записи флэш-памяти

    — IDENTIFY_DEVICE ———————————————————
    0 1 2 3 4 5 6 7 8 9
    000: 0040 3FFF C837 0010 0000 0000 003F 0000 0000 0000
    010: 3230 3230 3034 3137 3030 3037 3720 2020 2020 2020
    020: 0000 0000 0000 5330 3931 3841 3020 4465 5465 6368
    030: 2053 5344 2032 3430 4742 2020 2020 2020 2020 2020
    040: 2020 2020 2020 2020 2020 2020 2020 8001 4000 2F00
    050: 4000 0000 0000 0007 3FFF 0010 003F FC10 00FB 0101
    060: FFFF 0FFF 0000 0007 0003 0078 0078 0078 0078 0D00
    070: 0000 0000 0000 0000 0000 001F 850E 0006 0044 0040
    080: 07F8 011B 746B 7409 4060 7469 B401 4060 407F 0003
    090: 0003 0000 FFFE 0000 0000 0000 0000 0000 0000 0000
    100: 44B0 1BF2 0000 0000 0000 0008 4000 0000 0000 0000
    110: 0000 0000 0000 0000 0000 0000 0000 0000 0000 401C
    120: 401C 0000 0000 0000 0000 0000 0000 0000 0029 0000
    130: 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000
    140: 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000
    150: 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000
    160: 0000 0000 0000 0000 0000 0000 0000 0000 0003 0001
    170: 0000 0000 0000 0000 0000 0000 2020 2020 2020 2020
    180: 2020 2020 2020 2020 2020 2020 2020 2020 2020 2020
    190: 2020 2020 2020 2020 2020 2020 2020 2020 2020 2020
    200: 2020 2020 2020 2020 2020 2020 0000 0000 0000 4000
    210: 0000 0000 0000 0000 0000 0000 0000 0001 0000 0000
    220: 0000 0000 10FF 0000 0000 0000 0000 0000 0000 0000
    230: 0000 0000 0000 0000 0020 0020 0000 0000 0000 0000
    240: 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000
    250: 0000 0000 0000 0000 0000 A0A5

    — SMART_READ_DATA ———————————————————
    +0 +1 +2 +3 +4 +5 +6 +7 +8 +9 +A +B +C +D +E +F
    000: 01 00 01 32 00 64 64 00 00 00 00 00 00 00 05 32
    010: 00 64 64 00 00 00 00 00 00 00 09 32 00 64 64 04
    020: 13 00 00 00 00 00 0C 32 00 64 64 EF 04 00 00 00
    030: 00 00 A0 32 00 64 64 00 00 00 00 00 00 00 A1 33
    040: 00 64 64 64 00 00 00 00 00 00 A3 32 00 64 64 18
    050: 00 00 00 00 00 00 A4 32 00 64 64 FC CD 01 00 00
    060: 00 00 A5 32 00 64 64 04 04 00 00 00 00 00 A6 32
    070: 00 64 64 07 00 00 00 00 00 00 A7 32 00 64 64 A6
    080: 00 00 00 00 00 00 A8 32 00 64 64 DC 05 00 00 00
    090: 00 00 A9 32 00 64 64 59 00 00 00 00 00 00 AF 32
    0A0: 00 64 64 00 00 00 00 00 00 00 B0 32 00 64 64 00
    0B0: 00 00 00 00 00 00 B1 32 00 64 64 00 00 00 00 00
    0C0: 00 00 B2 32 00 64 64 00 00 00 00 00 00 00 B5 32
    0D0: 00 64 64 00 00 00 00 00 00 00 B6 32 00 64 64 00
    0E0: 00 00 00 00 00 00 C0 32 00 64 64 4A 00 00 00 00
    0F0: 00 00 C2 22 00 64 64 1E 00 00 00 00 00 00 C3 32
    100: 00 64 64 7B EF 01 00 00 00 00 C4 32 00 64 64 00
    110: 00 00 00 00 00 00 C5 32 00 64 64 00 00 00 00 00
    120: 00 00 C6 32 00 64 64 00 00 00 00 00 00 00 C7 32
    130: 00 64 64 00 00 00 00 00 00 00 E8 32 00 64 64 64
    140: 00 00 00 00 00 00 F1 30 00 64 64 84 54 03 00 00
    150: 00 00 F2 30 00 64 64 1D 0C 04 00 00 00 00 F5 32
    160: 00 64 64 4D AD 03 00 00 00 00 00 00 78 00 00 11
    170: 02 00 01 00 02 0A 00 00 00 00 00 00 00 00 00 00
    180: 00 00 53 30 39 31 38 41 30 20 30 30 00 00 00 00
    190: 53 4D 49 32 32 35 39 58 54 00 00 00 00 00 00 00
    1A0: FC CD 01 00 1A 00 00 00 00 00 00 00 00 00 23 AC
    1B0: 04 00 00 4E 31 38 30 30 00 00 00 00 00 00 00 00
    1C0: 28 0B FD 0D 00 00 00 00 99 C3 F2 1C 00 00 00 00
    1D0: 00 00 00 00 B3 09 00 00 4F 28 01 00 F3 03 04 04
    1E0: 38 00 AD A5 00 00 42 00 51 00 07 00 00 00 00 00
    1F0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 3D

    — SMART_READ_THRESHOLD —————————————————-
    +0 +1 +2 +3 +4 +5 +6 +7 +8 +9 +A +B +C +D +E +F
    000: 01 00 01 32 00 00 00 00 00 00 00 00 00 00 05 32
    010: 00 00 00 00 00 00 00 00 00 00 09 32 00 00 00 00
    020: 00 00 00 00 00 00 0C 32 00 00 00 00 00 00 00 00
    030: 00 00 A0 32 00 00 00 00 00 00 00 00 00 00 A1 32
    040: 00 00 00 00 00 00 00 00 00 00 A3 32 00 00 00 00
    050: 00 00 00 00 00 00 A4 32 00 00 00 00 00 00 00 00
    060: 00 00 A5 32 00 00 00 00 00 00 00 00 00 00 A6 32
    070: 00 00 00 00 00 00 00 00 00 00 A7 32 00 00 00 00
    080: 00 00 00 00 00 00 A8 32 00 00 00 00 00 00 00 00
    090: 00 00 A9 32 00 00 00 00 00 00 00 00 00 00 AF 32
    0A0: 00 00 00 00 00 00 00 00 00 00 B0 32 00 00 00 00
    0B0: 00 00 00 00 00 00 B1 32 00 00 00 00 00 00 00 00
    0C0: 00 00 B2 32 00 00 00 00 00 00 00 00 00 00 B5 32
    0D0: 00 00 00 00 00 00 00 00 00 00 B6 32 00 00 00 00
    0E0: 00 00 00 00 00 00 C0 32 00 00 00 00 00 00 00 00
    0F0: 00 00 C2 32 00 00 00 00 00 00 00 00 00 00 C3 32
    100: 00 00 00 00 00 00 00 00 00 00 C4 32 00 00 00 00
    110: 00 00 00 00 00 00 C5 32 00 00 00 00 00 00 00 00
    120: 00 00 C6 32 00 00 00 00 00 00 00 00 00 00 C7 32
    130: 00 00 00 00 00 00 00 00 00 00 E8 32 00 00 00 00
    140: 00 00 00 00 00 00 F1 32 00 00 00 00 00 00 00 00
    150: 00 00 F2 32 00 00 00 00 00 00 00 00 00 00 F5 32
    160: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    170: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    180: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    190: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    1A0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    1B0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    1C0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    1D0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    1E0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    1F0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 F5

    Куратор(ы):  

    KT   

    Автор Сообщение
     

    Прилепленное (важное) сообщение

    СообщениеДобавлено: 05.09.2005 22:35 

    [профиль]

    Member

    Статус: Не в сети
    Регистрация: 06.05.2005
    Откуда: Moldova

    ПРОСЯ О ПОМОЩИ, ВЫКЛАДЫВАЙТЕ S.M.A.R.T. ПРОБЛЕМНОГО НАКОПИТЕЛЯ!

    Его можно посмотреть программами Everest, AIDA 64, Victoria 4.x, Dtemp, HDDScan, HD Tune, Crystal Disk Info, SpeedFan… Обращайте внимание на DATA/RAW-параметры, это главные и основные показатели здоровья диска.

    >>>При использовании Crystal Disk Info в меню Сервис>Дополнительно>Raw-значения выберите вариант «10 [DEC]» это несколько упростит восприятие информации утилиты форумчанами.<<<

    <<Скриншоты>>

    При выкладке скриншотов не забываем ограничения накладываемы пунктом 3.12 правил конференции. А именно: «Размещать в тегах «Img» картинки объемом свыше 500 кБ на сообщение. Допускаются картинки до 2 МБ под тегом «spoiler=«, а также прямые ссылки на картинки любого размера. Ссылки на страницы, где картинка отображается среди рекламы, запрещены, применяющие их сайты блокируются автоцензором.»
    Немного о том, как ПРАВИЛЬНО создавать скриншоты для выкладки в форуме: http://forums.overclockers.ru/viewtopic … 4&t=373001

    Для лучшего понимания сути вопроса смотрите информацию на первой странице темы, составленную камрадом Ing-Syst.

    Так же помочь разобраться в показаниях СМАРТ может очень подробный материал размещенный на сайте ixbt.com: Оцениваем состояние дисков при помощи S.M.A.R.T.

    Возможно, для решения Вашей проблемы потребуется провести цикл процедур утилитами Виктория и MHDD. Ссылки на инструкции по работе с программами можно найти на первой странице темы.

    Связанные темы

    [FAQ] Всё о винчестерах Western Digital
    [FAQ] по винчестерам Seagate
    [FAQ] Всё о винчестерах Hitachi
    [FAQ] Всё о винчестерах Samsung

    Восстановление данных
    Ремонт HDD

    Сигейт официально признал проблему с 7200.11

    Полезные сообщения участников этой темы:

    Обнуление некоторых параметров СМАРТ на винчестерах Samsung
    Как найти файлы на которые приходятся кандидаты на ремап.
    Отключение парковки на винчестерах Seagate 7200.14 без батников и автозагрузки (нуждается в проверке)
    Remap и Advanced remap, erase и erase delays — назначение команд утилиты Victoria (1,2)
    Смена режима контроллера с IDE на AHCI при наличии уже установленной операционной системы Win 7 Win XP

    ShutUp — программа камрада CoolCMD для предотвращения частых парковок HDD.

    https://disk.yandex.ru/d/x3UITAgo3EGqub

    Программа считывает один сектор через определенный пользователем промежуток времени.

    Учёт и поиск запчастей к жестким дискам — R.baza.

    Последний раз редактировалось KT 29.11.2021 18:36, всего редактировалось 15 раз(а).

    Реклама

    Партнер
     
    miro1674n

    Member

    Статус: Не в сети
    Регистрация: 14.06.2018

    clancy писал(а):

    Живу в соседней стране в которой «иногда не до законов»

    А ну если в соседней тогда сори. Тогда не знаю.

     
    homerS

    Junior

    Статус: Не в сети
    Регистрация: 27.11.2022

    добрый день
    подскажите что параметр в смарте
    ID Описание атрибута Порог Значение Наихудшее Данные Статус
    AD <зависит от поставщика> 1 1 1 1583 Внимание: превышен лимит использования или срок

     
    miro1674n

    Member

    Статус: Не в сети
    Регистрация: 14.06.2018

    homerS SSD? Модель скажите. Можно даже было скрин самрта дать в программе Crystal Disk Info
    Вообще это количество циклов перезаписи ячеек памяти ссд, всего ссд (или скорее количество стираний блоков, но суть та же).

     
    int-997

    Junior

    Статус: Не в сети
    Регистрация: 04.12.2022

    Добрый день!
    Прошу подсказать, в чем может быть проблема.
    Купил в феврале HDD WD Blue 4 Tb. Поставил, некоторое время всё было в порядке. Затем стал замечать странности — подвисания при открытии и копировании файлов (диск использовался исключительно как хранилище для фоток и видео, без торрентов). Примерно через полгода поставил WD Dashboard и та показала наличие более 4000 тысяч ошибок CRC. Диск сдал в магазин, поменял на такой же.
    Прошло ещё 2 месяца. С новым диском стала твориться та же история. Сходил опять в магазин, поменял уже на WD Purple 4 Tb.
    И с первого же запуска увидел такую же проблему с зависанием при открытии/копировании. При этом провел тест в виктории — и все нормально (кроме одного предупреждения — «preset timeout limit«)! СМАРТ ничего не показывает. WD Dashboard или показывает, что всё нормально и все тесты пройдены, или же вообще не может завершить тест и выдаёт ошибку.
    Да, когда диск долго не используется, он сначала раскручивается — это всё понятно и нормально. Но с какого ж он посреди записи может просто перестать определяться в диспетчере задач??
    Не пойму, в чём дело. Проблемы по питанию? Но раньше у меня было не 2 хдд, а 3. И всё нормально работало. Шлейфы менял, переставлял с одного диска на другой — бесполезно. Драйверы? Винда? Или такая жуткая невезуха с WD? На что тогда поменять можно? Сигейты лично у меня когда-то сыпались в течение года-двух, я их поэтому уже лет 10 не покупаю.

     
    Опричник

    Member

    Статус: Не в сети
    Регистрация: 18.04.2018
    Откуда: Советский Союз
    Фото: 2

    int-997 писал(а):

    На что тогда поменять можно?

    Лично я Тошиба пользуюсь уже много лет. Тоже неприязнь к Сигейтам имею. Рекомендую. Ну а модель выбирайте по кошельку, серию Х300 допустим.


    _________________
    i7-11700k/Gigabyte Z590 D/64Гб DDR4/RTX 3060/HP Z24n G3 — WUXGA/SSD 1Тб + 3HDD (9Тб)/Win10

     
    Sania.

    Member

    Статус: Не в сети
    Регистрация: 22.12.2012
    Фото: 1

    int-997 писал(а):

    Драйверы? Винда? Или такая жуткая невезуха с WD?

    Скорее мать или проц или оперативка.

    Добавлено спустя 3 минуты 30 секунд:

    int-997 писал(а):

    Проблемы по питанию? Но раньше у меня было не 2 хдд, а 3.

    Это раньше, а теперь они дохнут и нужно возможно менять, тут нужно проверять.

     
    int-997

    Junior

    Статус: Не в сети
    Регистрация: 04.12.2022

    Sania. писал(а):

    Скорее мать или проц или оперативка.

    Если так, то каким образом проверить?
    Не пойму вот что — второй диск ведь работает нормально. Тоже WD, но на 1 Тб. Работает идеально и не первый год, причем на тех же самых шлейфах, что и новый 4 Тб (буквально на тех же самых, менял их местами).

     
    Sania.

    Member

    Статус: Не в сети
    Регистрация: 22.12.2012
    Фото: 1

    самый простой способ, подключить в другой компьютер, там и БП другой будет.

     
    Cocoa

    Member

    Статус: Не в сети
    Регистрация: 15.03.2017
    Откуда: Канада
    Фото: 24

    Sania. писал(а):

    самый простой способ, подключить в другой компьютер, там и БП другой будет.

    Опередили меня. Также считаю, причём это самый верный и быстрый метод разобраться.
    Насчёт сравнения WD 4TB с 1-террабайтником, — последние намного более выносливые, простонародно выражаясь.


    _________________
    i7-3770K, Noctua NH-U9S, G1.Sniper M3/Z77, G.Skill_4x8GB_F3-2400, Sapphire_RX460, Corsair_RM750-Gold, SilverStone-LC16MBM_HTPC, A/V Sony_STR-DH790 7.2

     
    OLD Hunter

    Member

    Статус: Не в сети
    Регистрация: 14.06.2009
    Откуда: Омск

    Здравствуйте. 870 evo 500gb тоже проблемные или от объема не зависит?

     
    MaximillianGreat

    Member

    Статус: Не в сети
    Регистрация: 18.02.2006

    Есть ссд Colorful SL500 480GB, покупал давно на ебее.
    Начал зависать в определнных местах. Прогнал викторией, там такое в нескольких местах.

    Цитата:

    20:14:42 : Get S.M.A.R.T. command… OK
    20:14:43 : Drive reported: SMART status = GOOD
    20:14:43 : Victoria reported: SMART status = Unideal
    20:14:50 : Recallibration… OK
    20:14:50 : Starting Reading, LBA=0..937694830, FULL, sequential access, timeout 10000ms
    20:15:17 : Block start at 12337152 (6 GB) Read error: UNCR «Ошибка в данных (CRC)»

    И после этого часто диск перестает отвечать. Мест таких на диске не много, штук 7. Reallocated sector count вроде растет

    Начинка

    Код:

    v0.564a
    Drive: 1(ATA)
    OS: 6.3 build 9600
    Model: Colorful SL500 480GB                   
    Fw   : R0522A0
    Size : 457858 MB [480.1 GB]
    From smart : [SMI2258XT] [R0522A0 00] [IM00]
    Controller : SM2258   bufferless
    FlashID: 0x89,0xb4,0x78,0x32,0xaa,0x1,0x0,0x0 — Intel 32L(B0KB) TLC 384Gb/CE 384Gb/die
    Channel: 3
    CE     : 4
    TotDie : 12
    Plane  : 4
    Die/Ce : 1
    Ch map : 0x07
    CE map : 0x0F
    Inter. : 4
    First Fblock  :    2
    Total Fblock  :  548
    Total Hblock  : 7155
    Fblock Per Ce :  548
    Fblock Per Die:  548
    Original Spare Block Count :    80
    Vendor Marked Bad Block    :     0
    Bad Block From Pretest     :    11

    Смарт

    Код:

    —————————————————————————-
     (02) Colorful SL500 480GB
    —————————————————————————-
               Model : Colorful SL500 480GB
            Firmware : R0522A0
           Disk Size : 480,1 GB (8,4/137,4/480,1/480,0)
         Buffer Size : Неизвестно
         Queue Depth : 32
        # of Sectors : 937694831
       Rotation Rate : —- (SSD)
           Interface : Serial ATA
       Major Version : ACS-2
       Minor Version : ACS-2 Revision 3
       Transfer Mode : SATA/300 | SATA/600
      Power On Hours : 7332 ч
      Power On Count : 1177 раз
          Host Reads : 11264 GB
         Host Writes : 7267 GB
         NAND Writes : 8344 GB
         Temperature : 40 C (104 F)
       Health Status : Хорошо (100 %)
            Features : S.M.A.R.T., APM, NCQ, TRIM, GPL
           APM Level : 0080h [ON]
           AAM Level : —-
        Drive Letter : E:

    — S.M.A.R.T. —————————————————————
    ID Cur Wor Thr RawValues(6) Attribute Name
    01 100 100 _50 000000000000 Частота ошибок чтения
    05 100 100 _50 000000000010 Перераспределённые сектора
    09 100 100 _50 000000001CA4 Часы работы
    0C 100 100 _50 000000000499 Включения/отключения
    A0 100 100 _50 000000000019 Невосстановимые сектора при чтении/записи
    A1 100 100 _50 000000000050 Действующие запасные блоки
    A3 100 100 _50 00000000000B Изначально недействительные блоки
    A4 100 100 _50 0000000071C0 Всего стираний
    A5 100 100 _50 000000000052 Максимум стираний
    A6 100 100 _50 000000000003 Минимум стираний
    A7 100 100 _50 000000000038 В среднем стираний
    A8 100 100 _50 000000001B58 Максимум стираний по спецификации
    A9 100 100 _50 000000000064 Оставшийся ресурс
    AF 100 100 _50 000000000000 Ошибки программирования, худший штамп
    B0 100 100 _50 000000000000 Ошибки стирания, худший штамп
    B1 100 100 _50 000000000000 Всего операций Wear Leveling
    B2 100 100 _50 000000000010 Недействительные блоки при работе
    B5 100 100 _50 000000000000 Всего ошибок программирования
    B6 100 100 _50 000000000000 Всего ошибок стирания
    C0 100 100 _50 00000000006A Аварийные парковки при отключении питания
    C2 100 100 _50 000000000028 Температура
    C3 100 100 _50 00000007B47E Аппаратное ECC-восстановление
    C4 100 100 _50 000000000019 События перераспределения
    C5 100 100 _50 000000000010 Текущие нестабильные сектора
    C6 100 100 _50 000000000019 Невосстановимые офлайн-ошибки
    C7 100 100 _50 000000000003 CRC-ошибки Ultra DMA
    E8 100 100 _50 000000000050 Доступное резервное место
    F1 100 100 _50 000000038C7B Всего LBA записано
    F2 100 100 _50 00000005800A Всего LBA прочитано
    F5 100 100 _50 000000041300 Сектора записи флэш-памяти

    ————————————————————————————
      ID      Name                   Value  Worst  Tresh       Raw    Health
    ————————————————————————————
      1 Raw read error rate                 100    100     50                0   •••••
      5 Reallocated sector count            100    100     50               16   •••••
      9 Power-on time                       100    100     50             7332   •••••
     12 Start/stop count                    100    100     50             1177   •••••
    160 Uncorrectable sector count read or write      100    100     50               25   •••••
    161 Number of valid spare block         100    100     50               80   •••••
    163 Number of initial invalid block      100    100     50               11   •••••
    164 Total erase count                   100    100     50            29120   •••••
    165 Maximum erase count                 100    100     50               82   •••••
    166 Minimum erase count                 100    100     50                3   •••••
    167 Average erase count                 100    100     50               56   •••••
    168 Max NAND erase count from specification      100    100     50             7000   •••••
    169 Total bad block count / SMI remain life (percentage)      100    100     50              100   •••••
    175 SMI program fail count in worst die      100    100     50                0   •••••
    176 Erase fail count in worst die       100    100     50                0   •••••
    177 Wear leveling range percent         100    100     50                0   •••••
    178 Used reserved block count (Chip)      100    100     50               16   •••••
    181 Program Fail Count (Total)          100    100     50                0   •••••
    182 Erase Fail Count (Total)            100    100     50                0   •••••
    192 Unsafe shutdown count               100    100     50              106   •••••
    194 Temperature controller              100    100     50       40°C/104°F   •••• 
    195 Hardware ECC recovered              100    100     50           504956   •••••
    196 Reallocated event count             100    100     50               25   •••••
    197 Current pending sectors             100    100     50               16   •••••
    198 Offline uncorrectable sectors count      100    100     50               25   •••••
    199 Ultra DMA CRC errors                100    100     50                3   •••••
    232 Available Reserved Space            100    100     50               80   •••••
    241 Total sectors write                 100    100     50           232571   •••••
    242 Total LBA read                      100    100     50           360458   •••••
    245 Timed Workload Media Wear           100    100     50         4 / 4864   •••••

    Хотелось бы починить его для неважных задач.
    Что лучше делать? Ремапить в виктории? Прошивать? Или еще что?

    И еще вопрос, может у Colorful какая-нибудь RMA есть по которой его можно попробовать обменять? Ну это я конечно совсем губу раскатал :D

     
    miro1674n

    Member

    Статус: Не в сети
    Регистрация: 14.06.2018

    MaximillianGreat писал(а):

    Что лучше делать? Ремапить в виктории? Прошивать? Или еще что?

    SE сделать (диск сотрет все блоки), не размечать, посмотреть как изменится смарт, просканировать в виктории все сектора. Если не исправит дело, прописывать конкретно те участки где есть вот эти бэд-блоки. то есть выбирать в виктории запись и тот LBA где при сканировали зафиксировали бэд. Посмотреть переназначает ли при перезаписи, если переназначает, то дальше сканировать опять полностью чтобы проверить что больше нет сбойных блоков.

    Я как-то так это представляю :?:.

     
    O Smirnoff

    Member

    Статус: Не в сети
    Регистрация: 11.11.2010
    Откуда: Новосибирск

    miro1674n писал(а):

    SE сделать (диск сотрет все блоки), не размечать, посмотреть как изменится смарт, просканировать в виктории все сектора.

    Нафига что-то пытаться «сканировать» на SSD после Secure Erase?!. :?:
    Контроллер SSD читает только те физические блоки, которым сопоставлен LBA в трансляторе — но после процедуры SE таких просто нет.

    miro1674n писал(а):

    и тот LBA где при сканировали зафиксировали бэд.

    Ещё один бред: физические блоки NAND никак не привязаны к какому-то конкретному LBA, на какой именно физический блок попадёт конкретный LBA — решает транслятор…


    _________________
    С уважением,
    Олег Р. Смирнов

     
    MaximillianGreat

    Member

    Статус: Не в сети
    Регистрация: 18.02.2006

    Хмм. Так, получается, мнения разделились :?:
    Что делать то?

     
    Lightwarrior

    Member

    Статус: Не в сети
    Регистрация: 15.01.2013

    O Smirnoff писал(а):

    … Ещё один бред: физические блоки NAND никак не привязаны к какому-то конкретному LBA, на какой именно физический блок попадёт конкретный LBA — решает транслятор…

    Другими словами на ССД все средства и методы для работы с битыми блоками которые применялись на ХДД целиком и полностью бесполезны. Можно не тратить время.

    Если блок действительно неисправен (а не просто забыл данные, от чего поможет SE) то тут ровно 2 варианта — либо ССД его сам исключит из пула используемых блоков, либо ССД отправится в помойку.

    MaximillianGreat писал(а):

    Хмм. Так, получается, мнения разделились :?:
    Что делать то?

    Начать с SE, затем если хочется проверить то нужно сначала писать весь объём, а потом только пробовать читать.

     
    O Smirnoff

    Member

    Статус: Не в сети
    Регистрация: 11.11.2010
    Откуда: Новосибирск

    Lightwarrior писал(а):

    если хочется проверить то нужно сначала писать весь объём, а потом только пробовать читать

    Причём, писать не «0», а случайными паттернами (либо, как предлагает Victoria, писать в каждый LBA его номер.


    _________________
    С уважением,
    Олег Р. Смирнов

     
    MaximillianGreat

    Member

    Статус: Не в сети
    Регистрация: 18.02.2006

    Ага. :?: В TXbench получается СЕ не работает (диск перетыкал). Начинает и потом пишет «failed». Сработало стирание только через трим.
    Как еще СЕ делать?

     
    miro1674n

    Member

    Статус: Не в сети
    Регистрация: 14.06.2018

    O Smirnoff писал(а):

    Контроллер SSD читает только те физические блоки, которым сопоставлен LBA в трансляторе — но после процедуры SE таких просто нет.

    Прописать полностью, потом прочитать, не?

    Добавлено спустя 1 минуту 23 секунды:

    O Smirnoff писал(а):

    Причём, писать не «0», а случайными паттернами

    А какая разница? Не пишут нули только определённые контроллеры. 2258XT к ним не относится.

     
    MaximillianGreat

    Member

    Статус: Не в сети
    Регистрация: 18.02.2006

    Так, после очистки тримом, диск полностью записался викторией и полностью прочитался без ошибок.
    Смарт вроде особо не изменился. 196 и 198 добавили единичку, но это вроде еще до стирания.

    Странно тогда устроены эти прошивки, если они не могут починить, то что тримом чинится :roll:

    Кто сейчас на конференции

    Сейчас этот форум просматривают: Big Gnom, Samnit и гости: 7

    Вы не можете начинать темы
    Вы не можете отвечать на сообщения
    Вы не можете редактировать свои сообщения
    Вы не можете удалять свои сообщения
    Вы не можете добавлять вложения

    Лаборатория

    Новости

    1. Цена: US $16.98 (брал за $9.65)
    2. Перейти в магазин

    Всем привет! В конце ноября были хорошие скидки и я заказал SSD (пост о скидке) на 128 GB от WALRAM.
    Ничего особенного не ждал, главное что бы работали и не глючили)
    Брал 6 шт, в ноуты/компы ставить вместо жестких дисков (или в дополнение). Почти все поставил — все работают.
    Посмотрим и протестируем, обзор краткий(больше отзыв).
    Обычный дешевый SSD, не вижу смысла писать «много букв»)

    Упаковка — запаянный пакет. Раньше, судя по информации из другого обзора, была картонная упаковка

    Корпус изготовлен из пластика.

    Разбирается легко. Внутри контроллер Yeestor YS9082HC, неожиданно, обычно SM2258XT ставят.
    Память hynix TLC.


    На странице товара указаны скорости в 560мб/с чтение и 490мб/с запись
    CrystalDiskInfo

    Посмотрим, что покажет SSD-Z

    Тест в программе

    Теперь CrystalDiskMark. Накопитель заполнен на четверть

    Программа ATTO Disk Benchmark

    Программа As SSD Benchmark

    Проверим линейное чтение и запись в программе HD TUNE. Все настройки по умолчанию.
    Чтение — постоянные 400 мб/с

    Запись — на большей части объема ~ 300мб/с, потом упала.

    Через 20 минут провел тест еще раз — результат изменился.

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

    Спасибо за внимание!



    Планирую купить

    +7


    Добавить в избранное



    Обзор понравился


    +42
    +57

    Как бы упорно мы не полагались на машины, они далеки от идеала. Как минимум, потому что сделаны человеком.

    Пока программы не станут умнее людей, нам придётся следить за их состоянием постоянно. Особенно когда говорим об отвественном деле.

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

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

    1. Система заживо похоронила 8 500 пациентов больницы в Мичигане

    В 2003 году Медцентр Св. Марии Милосердия в городе Гранд-Рапидс обновил свою программу для учёта больных до новой версии. Из-за неверного толкования данных переменные «выписан» и «скончался» перепутались.

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

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

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

    2. Обновление ПО лишило 60 тысяч человек междугородных звонков

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

    Данные начали наслаиваться друг на друга, и проблема быстро распространилась по другим точкам. На обратном конце люди слышали только шум. Так продолжалось 9 часов.

    Проблему решили откатом ПО до предыдущей версии, однако проблема не перестала быть актуальной.

    Ситуация повторилась как минимум один раз в 1998 году, но тогда были затронуты только сервисные уведомления по SMS.

    3. 5% всех магазинов России сломалось из‑за новой онлайн‑кассы

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

    Сбои начались в салонах сети DNS во Владивостоке, где люди просыпаются раньше Москвы. Система не давала отправлять расчёты в Федеральную налоговую службу (ФНС), а из-за этого кассиры не имели права реализовывать товар.

    Пока проблема добралась до столицы, откуда начал решаться вопрос, по всей России встали некоторые точки Магнита, Пятёрочки с Перекрёстком, Эльдорадо и аптек Ригла.

    ФНС пришлось быстро реагировать и разрешать магазинам работать в офлайн режиме. Тем разрешили вносить данные после того, как система восстановится.

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

    Теоретический ущерб, по мнению Ассоциации компаний интернет-торговли, мог дойти до 2,5 млрд рублей. Реальный оказался чуть ниже благодаря быстрой оптимизации процессов со стороны ФНС.

    4. Машине дали проектировать стадион в Коннектикуте. Тот рухнул

    С 1972 года город Хартфорд старался расширить свою инфраструктуру и вкладывался в крупные проекты. Одним из них стал Hartford Civic Center – комплекс торговых, развлекательных и спортивных площадок.

    Структуру стадиона проектировали через программу, что вместе с оптимизированным расходом материалов сэкономило городу около $500 тысяч.

    Комплекс полностью функционировал и даже был «домом» для местной хоккейной группы New England Whalers с 1975 года.

    Однако утром 18 января 1978-го стадион обвалился. Игр в тот день не проходило: здание было пустым и никто не пострадал.

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

    Четыре несущие колонны с момента возведения были плохо продуманы в размере и креплении. Стадион начал постепенно «складываться» ещё во время строительства, а группы по контролю качества распределялись между разными подрядчиками и плохо согласовали данные.

    Восстановление стоило городу $90 млн. В последствии на месте комплекса возвели арену XL Center, которая до сих пор исполняет роль главной спортивной площадки Хартфорда.

    5. Intel выпустила процессор с ошибкой и устроила международный скандал

    В 1994 году CPU под брендом Pentium был флагманом компании, и в нём пряталась микроскопическая проблема, которая касалась крошечной части людей: когда пользователь делил одно число на другое, результат был неверным. Выглядела ошибка так:

    Программисты неправильно настроили одну из веток операций, вшитых в процессор. Она искала корневые данные и находила не те.

    При этом основной ущерб пришёлся не на пользователей, а на компанию.

    Из-за того, что Intel уже тогда уверенно чувствовала себя на рынке, а чипы были новые, даже федеральные СМИ многих стран подхватили новость и нанесли катастрофический ущерб имиджу и доходу компании.

    В итоге за 1994 год замена всех повреждённых процессоров сократила выручку компании вдвое от запланированной – на $475 млн.

    6. 6 миллионов автомобилей могут не раскрыть воздушные подушки

    В январе 2020 года выяснилось, что датчики в некоторых моделях компаний Toyota и Honda слишком чувствительны к электрическому шуму.

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

    Проблема может быть глобальнее, поскольку компьютер из автомобилей Toyota разрабатывался сторонней организацией ZF-TRW. А она поставляла свои наработки как минимум шести компаниям в одних США, которые продали 12,3 млн машин.

    Но пока только японские производители решили чинить датчики. И то, многие всё ещё ждут уведомления от своих диллеров.

    7. MySpace уничтожил 50 миллионов песен пользователей

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

    А в ходе переноса своей огромной библиотеки музыки, фотографий и видео возникла ошибка на сервере, которая их безвозвратно удалила.

    Поскольку точной причины руководство не раскрыло, по поводу источника проблемы ходят разные слухи. Например, есть предположение, что хранить такой объём старых данных невыгодно и руководству было дешевле его «случайно» удалить.

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

    8. 144 тысячи родителей-одиночек не получили государственных выплат

    В апреле 2003 года британская компания по поддержке малообеспеченных и неполноценных семей Child Support Agency внедрила систему по фильтрации заявлений. Она стоила £300 млн.

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

    Скандал длился как минимум до 2006 года, пока программа продолжала съедать 70% выделяемых на проект денег и затраты к 2010 году не составили £1,1 млрд.

    В итоге в 2012 году агенство закрыли и вместо него запустили новую организацию Child Maintenance Group.

    9. Уязвимость в защите 500 тысяч крупнейших сайтов давала доступ к вашей RAM

    В апреле 2014 года специалисты по информационной безопасности обнаружили в библиотеке OpenSSL, на которой держится самый распространённый протокол HTTPS, критическую дыру в безопасности.

    Её назвали Heartbleed по аналогии с процессом Heartbeat, взятым за основу этой ошибки.

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

    И, хотя максимальный объём украденной информации не мог превышать 64 Кб за один запрос, этого хватало на доступ к паролям и конфиденциальным сообщениям.

    Ошибка затронула 17% всех защищенных сайтов. В том числе Google, Facebook, Instagram, Twitter и даже Minecraft.

    Опасность закрывалась простым патчем, поэтому многие компании отреагировали быстро.

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

    10. Мир потратил $300 млрд, чтобы в 2000 году компьютеры продолжили работать

    Фото Эмори Кристоф / Emory Kristof

    До 1999 года системы программировали так, что одни отмечали даты форматом из 8 цифр (ЧЧ.ММ.ГГГГ), а другие оставляли 6.

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

    Дата формата ЧЧ.ММ.ГГ могла заменить 2000 на 1900 год, поскольку оба числа кончаются на «ОО». Таким образом ошибка бы переписала и стёрла данные, нарушила работу алгоритмов и спровоцировала коллапс онлайн-систем.

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

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

    Вокруг Проблемы 2000 года (или Y2K) было много разговоров, в том числе о целесообразности паники. Их подогревало то, что страны восприняли вопрос серьезно и прописывали инициативы на государственном уровне.

    Например, Россия создала официальный документ Национальный план действий по решению “Проблемы 2000” в Российской Федерации.

    Табло на последней строке «обнулилось» и показывает 1900 вместо 2000

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

    64-х битных систем ситуация коснётся через 292 миллиарда лет, так что тут можно расслабиться.

    Куда реальнее и скорее грозит Проблема 10 000 года своим переходом на значения из пяти цифр. Кажется, что не стоит о ней беспокоиться – пока вопрос ведь скорее теоретический.

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

    Может, призадуматься и стоит.

    1 Звезд2 Звезды3 Звезды4 Звезды5 Звезд (30 голосов, общий рейтинг: 4.77 из 5)

    🤓 Хочешь больше? Подпишись на наш Telegram.

    undefined

    iPhones.ru


    В последнем случае – миллиардов.

    • Подборки,
    • Это интересно

    Павел avatar

    Павел

    @Tinelray

    У меня 4 новых года: обычный, свой, WWDC и сентябрьская презентация Apple. Последний — самый ожидаемый, и ни капли за это не стыдно.

  • Ошибки прогнозов бывают следующих видов
  • Ошибки проверки конвертируемых объектов
  • Ошибки проверки вводимых данных инъекция e mail
  • Ошибки проверки вводимых данных sql инъекция
  • Ошибки приус 30 перевод