I/O error, dev sda hys_seg 128 prio class 2

шлейф переткни. Разъёмы от пыли продуй.

В смарт заглянул бы хоть.

Я когда-то игрался с опциями монтирования ext4 и получил ошибку чтения на сектор 1443084053. Викторией просканил диск и сделал ремап сектора. После этого пол года прошло. Смарт ниже

SMART Attributes Data Structure revision number: 16
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  1 Raw_Read_Error_Rate     0x002f   200   200   051    Pre-fail  Always       -       0
  3 Spin_Up_Time            0x0027   181   175   021    Pre-fail  Always       -       3950
  4 Start_Stop_Count        0x0032   095   095   000    Old_age   Always       -       5881
  5 Reallocated_Sector_Ct   0x0033   200   200   140    Pre-fail  Always       -       0
  7 Seek_Error_Rate         0x002e   100   253   000    Old_age   Always       -       0
  9 Power_On_Hours          0x0032   069   069   000    Old_age   Always       -       22842
 10 Spin_Retry_Count        0x0032   100   100   000    Old_age   Always       -       0
 11 Calibration_Retry_Count 0x0032   100   100   000    Old_age   Always       -       0
 12 Power_Cycle_Count       0x0032   095   095   000    Old_age   Always       -       5575
192 Power-Off_Retract_Count 0x0032   200   200   000    Old_age   Always       -       633
193 Load_Cycle_Count        0x0032   199   199   000    Old_age   Always       -       5247
194 Temperature_Celsius     0x0022   106   095   000    Old_age   Always       -       41
196 Reallocated_Event_Count 0x0032   200   200   000    Old_age   Always       -       0
197 Current_Pending_Sector  0x0032   200   200   000    Old_age   Always       -       0
198 Offline_Uncorrectable   0x0030   200   200   000    Old_age   Offline      -       0
199 UDMA_CRC_Error_Count    0x0032   200   200   000    Old_age   Always       -       0
200 Multi_Zone_Error_Rate   0x0008   200   200   000    Old_age   Offline      -       2

SMART Error Log Version: 1
No Errors Logged

SMART Self-test log structure revision number 1
Num  Test_Description    Status                  Remaining  LifeTime(hours)  LBA_of_first_error
# 1  Extended offline    Completed without error       00%     22211         -
# 2  Extended offline    Aborted by host               90%     22205         -
# 3  Extended offline    Aborted by host               90%     22205         -
# 4  Extended offline    Aborted by host               90%     22205         -
# 5  Short offline       Completed: read failure       90%     22205         1443084053
# 6  Extended offline    Completed: read failure       90%     22204         1443084053
# 7  Extended offline    Completed: read failure       90%     22204         1443084053
# 8  Extended offline    Completed: read failure       90%     22204         1443084053
# 9  Extended offline    Interrupted (host reset)      90%     22199         -
#10  Extended offline    Completed: read failure       90%     22196         1443084053
#11  Extended offline    Completed: read failure       90%     22196         1443084053
#12  Extended offline    Completed: read failure       90%     22196         1443084053
#13  Extended offline    Completed: read failure       90%     22196         1443084053
#14  Short offline       Completed without error       00%     22196         -
#15  Short offline       Completed without error       00%     17367         -
#16  Extended offline    Completed without error       00%     12985         -
#17  Short offline       Completed without error       00%     12982         -
#18  Short offline       Completed without error       00%     12982         -
#19  Extended offline    Completed without error       00%      6278         -
#20  Extended offline    Aborted by host               90%      1814         -
#21  Extended offline    Completed without error       00%      1814         -
8 of 8 failed self-tests are outdated by newer successful extended offline self-test # 1

SMART Selective self-test log data structure revision number 1
 SPAN  MIN_LBA  MAX_LBA  CURRENT_TEST_STATUS
    1        0        0  Not_testing
    2        0        0  Not_testing
    3        0        0  Not_testing
    4        0        0  Not_testing
    5        0        0  Not_testing
Selective self-test flags (0x0):
  After scanning selected spans, do NOT read-scan remainder of disk.
If Selective self-test is pending on power-up, resume after 0 minute delay.

Стрёмно это как-то всё. Раньше на один сектор ругался, теперь на другие. Параметр Multi_Zone_Error_Rate ненулевой… Я бы этот диск на игрушки пустил бы или на торренты, а важные данные перенёс на другой.

Multi_Zone_Error_Rate появился примерно в одно время с read failure 1443084053(smart). В виктории был только 1 сектор нечитаемый. Вручную он тоже был нечитаемый - выдавал io error. Секторы, которые погрепались в журнале - читаются

После отката на вменяемые опции монтирования ext4 - подобных ошибок не было

Лог виктории: https://pasteboard.co/tGcqhOtR3e9l.png

Вангую, что поверхность в удовлетворительном состоянии

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

PPSS: накопитель около года находился в неотапливаемом помещении(в 16 году бежал от войны и дома пк остался без отопления). Может контакты закисли от влажности. Чем их почистить - хзхз. Попробую еще сменить шлейф(шлейф новый шел с материнкой, может быть брак, в любом случае попробую поменять)

Никакой ремап ты не сделал, ты что не видишь что в смарте по нулям?

Проблема не с поверхностью.

Чем их почистить - хзхз

Канцелярским ластиком который с абразивом.

Была проблема с поверхностью. Там было

197 Current_Pending_Sector  0x0032   200   200   000    Old_age   Always       -       1
198 Offline_Uncorrectable   0x0030   200   200   000    Old_age   Offline      -       1
200 Multi_Zone_Error_Rate   0x0008   200   200   000    Old_age   Offline      -       7

После ремапа pending стал 0, uncorrectable остался 1 и через месяц стал 0 и мультизон потихоньку начал отрицательный рост и стал равен 2

Но по поводу мультизон, есть еще предположение, что виноват корпус. В enthoo pro 2 есть крепление на боковой стенке и там, где в нормальных корпусах psu стоит. Я на боковой стенке поставил - очень шумно т.к недалеко от морды корпуса, который весь в сетке. И я его поставил по-дальше т.е там, где psu. А там крепление такое, что накопитель весь такой шатается. Рукой берешь и шевелишь крепление. Я планку, на которую цепляется корзина для hdd подогнул и стало всё ок. Возможно мультизон из-за этого рос. При работе начинал вибрировать и сам себя раскачивал(как один из вариантов)

Канцелярским ластиком который с абразивом.

И как туда ластиком залесть? Может лучше спиртом после бритья на ватку и протереть контакты?

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

Обычным спиртом

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

После ремапа reallocated увеличивается

realloc увеличивается, когда резервное место под ремап заканчивается, а когда сектор не читается - он помечается как Pending и если к нему не обращаются - он может так годами висеть как Pending. Но если к нему несколько раз обратился - накопитель его сам его лечит из резервного объема. Если объем закончился - помечает его как реалокейтед

Всегда ваш Алиса

PS: а я быстрей его в виктории переназначил т.е по сути выполнил работу за хард

Если объем закончился - помечает его как реалокейтед

Разве? Reallocated_Sector_Ct инкрементируется независимо от объёма резервных секторов. Pending’и могут пропасть сами.

инкрементируется независимо от объёма резервных секторов

Конечно же нет. В новом харде битых секторов много. Они сразу заменяются из резервной области. И по мере эксплуатации хард их втихую заменяет. А когда резерв заканчивается - тогда они помечаются как Reallocated. Это известно еще с seagate 10gb или ты и правда думаешь, что поверхность блинов с их плотностью записи такая идеальная, что там нет не одного бэда?

Битых секторов много, но они просто пропускаются при форматировании (заводском низкоуровенвом).

А когда резерв заканчивается - тогда они помечаются как Reallocated.

Чего? Если резерв закончился, то откуда НЖМД берёт сектора на замену?

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

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

Это известно еще

Ну ты ещё напиши «общеизвестно» :)

Странные у вас действия. В dmesg написано:

cmd 60/00:40:00:68:36/04:00:73:00:00/40 tag 8 ncq dma 524288 in

Прочитать 1024 сектора (524288 байт) с 0x73366800=1932945408 (524288 байт).

В результате:

res 40/00:3c:00:64:36/00:00:73:00:00/40 Emask 0x10 (ATA bus error)

Ошибка ATA-шины, причём Emask только AC_ERR_ATA_BUS, ни AC_ERR_DEV, ни AC_ERR_MEDIA, ни AC_ERR_TIMEOUT (если НЖМД не может прочитать сектор, он может долго это делать). LBA адрес в res 0x73366400 (хотя его и не надо рассматривать), другой, чем требуемый сектор. В smart-журнале нет ошибки чтения.

Но вы, зачем-то, пробуете:

reading sector 1932945408: succeeded

хотя ошибка шины — это кабель, контроллер, может ОЗУ, но не поверхность блинов. И, обычно, если Линукс не может прочитать сектор, то он пробует повторно, но уже 4096 байт. А раз второго сообщения нет, скорее всего этот 1932945408 сектор ядро успешно прочитало в Aug 21 15:56:25.

Погрепал журнал

И обрезали Emask, чтобы было не понятно, с чем связана ошибка чтения.

Но вы, зачем-то, пробуете: reading sector 1932945408: succeeded

sudo hdparm --read-sector 0x73366800 /dev/sda

/dev/sda:
reading sector 1932945408: succeeded

Видимо 1932945408 - это 0x73366800

Насчет вышесказанного - со всем согласен. Буду начинать с:

1. протереть контакты на накопителе
2. сменить шлейф
3. сменить порт sata
4. проверить память

После этого буду делать какие-то выводы. А вообще очень странные ошибки, которые появляются нерегулярно и по разу в день. Я вот думаю, не связано ли это с нахождением и выходом из standby и, скажем, с torrent клиентом deluge или чем-то еще, что может после пробуждения что-то читать и промахиваться?

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

И для Dimez

Битых секторов много, но они просто пропускаются при форматировании (заводском низкоуровенвом).

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

1. предполагаю, что ссылки нет и поэтому предположу, что нет никакого заводского форматирования и карты заводских бэдов. Есть системная логика работы с секторами, которые требуют ремап из резервной области. И логика очень простая: плохо читается? - заменяем сектор из резервной области!. Это снимает вопрос про заводское форматирование и карту бэдов. Кому это надо подключать эти блины и что-то там форматировать? Блины проверяются на % дефектности рентгеном и всё. Удовлетворительно? Ставим блины в накопитель. Иначе - выкидываем или еще какой-то вариант

2. моему накопителю 10 лет. Врядли у него за это время нет не одного бэда. Но Reallocated_Sector_Ct == 0. Очень странно, да? Если бы любой бэд записывался в Reallocated_Sector_Ct, то был бы дикий плач ото всех, кто смог добраться до смарта. И куча судов/возвратов/etc. Поэтому производители, от греха по-дальше не трогают этот параметр, пока есть место в резервной области. Иначе у всех накопителей было бы ненулевое значение

Верны ли эти два утверждения - хзхз, нет документации. Когда будет - тогда можно это опровергнуть. Но по логике вроде коллизий нет

3. Я один раз сталкивался с диском с бэдами. Это seagate 10gb. Да, там постоянно были ошибки и скандиск на венде запускался постоянно. И некоторые файлы оказывались битыми. Подозреваю, что это напрямую связано с Reallocated

I/O error, dev sda hys_seg 128 prio class 2 (комментарий)

Ты про какие контакты? Речь идёт про контакты между платой контроллера и самим диском. Снимаешь плату контроллера и смотришь на контакты. Они зачастую окислены. Очищаешь их от окислов и ставишь назад.

Вот один из кучи примеров в сети https://pravilno-vybrat.ru/wp-content/uploads/2019/12/do-i-posle-chistki-600x750.jpg

Видимо 1932945408 - это 0x73366800

Ну да, и для этого достаточно: echo $(( 0x73366800 )).

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

И нужно смотерть сообщения до и после «I/O error», может там link переустанавливается с 6 на 1,5 Гбит/с и всё становится нормально. Особенно, 13 янв, когда три ошибки подряд, запросто, что ядро контроллер reset'нуло. Насколько я знаю, давным давно (IDE) можно было командами hdparm переключать скорость линка, а потом это убрали и сейчас ядро пытается установить максимальную скорость, а в случае ошибок понижает.

Причём нет никаких средств диагностик, чтобы узнать уровень сигнала. Иногда бывает, что конкретное сочетание контроллер/накопитель упорно не желают на 6 Гбит стабильно работать, протирай/не протирай контакты, меняй кабель — разницы нет. Может немного параметры микросхем ушли, может конденсаторы на сигнальных линиях потеряли немного ёмкости — неведомо.

Мда, сколько ты чуши понаписал.

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

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

моему накопителю 10 лет. Врядли у него за это время нет не одного бэда. Но Reallocated_Sector_Ct == 0. Очень странно, да?

Ничего не странно. Да, именно ни одного бэда. Этот счётчик как раз для того там и сделали чтобы юзер заметил что появились бэды, которые контроллер успел спрятать от обычных i/o операций.

Насколько я знаю, давным давно (IDE) можно было командами hdparm переключать скорость линка, а потом это убрали и сейчас ядро пытается установить максимальную скорость, а в случае ошибок понижает.

Можно в аргументы ядра прописать libata.force=1:1.5G

Не помню что означает первая единица, возможно это номер диска.

Есть PC-3000 (за денюжку). Там в документации достаточно много написано. Старые НЖМД, условно <160 Гб достаточно хорошо изучили, прошивки реверсили и т.д. Можете гуглить по G-list, P-list и читать, читать форумы.

«Износ» блинов минимальный, иначе бы НЖМД не работали годами. Первое (заводское, низкоуровневое) форматирование, там пишется во все сектра, читаются, оценивается хороший/плохой. И потом пишутся сервометки (номера секторов) только в хорошие сектора. То есть физически 0,1,2,3, второй плохой, будет 0,1,x,2.

нет никакого заводского форматирования

Ага, и откуда на блинах сервометки берутся? По которым определяется номер сектора? Даже floppy (НГМД) с шаговым приводом и то делал низокуровневое форматирование — записывал номер сектора.

И логика очень простая: плохо читается? - заменяем сектор из резервной области!.

Хорошая логика. И что в конце, когда резервная область закончилась? Как работают НЖМД, у которых realloc 100+ и при этом полная ёмкость и нет ошибок ФС? Откуда он берёт сектора для realloc, если скрыто подменял их из резервной области и она закончилась?

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

И куча судов/возвратов/etc.

Какие суды/возвраты? Есть гарантийный срок, отработал и всё.

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

Я думал контакты, куда питание и шлейф вставляется. Ок, понял-принял что надо чистить

Да, ошибка каждый раз при загрузке

Mar 10 21:05:39 debian-home kernel: ata9.00: exception Emask 0x0 SAct 0x60000 SErr 0x8d0000 action 0x6 frozen
Mar 10 21:05:39 debian-home kernel: ata9: SError: { PHYRdyChg CommWake 10B8B LinkSeq }
Mar 10 21:05:39 debian-home kernel: ata9.00: failed command: READ FPDMA QUEUED
Mar 10 21:05:39 debian-home kernel: ata9.00: cmd 60/00:88:28:94:c4/04:00:3c:00:00/40 tag 17 ncq dma 524288 in
                                             res 40/00:00:00:4f:c2/00:00:00:00:00/00 Emask 0x4 (timeout)
Mar 10 21:05:39 debian-home kernel: ata9.00: status: { DRDY }
Mar 10 21:05:39 debian-home kernel: ata9.00: failed command: READ FPDMA QUEUED
Mar 10 21:05:39 debian-home kernel: ata9.00: cmd 60/00:90:28:98:c4/04:00:3c:00:00/40 tag 18 ncq dma 524288 in
                                             res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
Mar 10 21:05:39 debian-home kernel: ata9.00: status: { DRDY }
Mar 10 21:05:39 debian-home kernel: ata9: hard resetting link
Mar 10 21:05:39 debian-home kernel: ata9: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
Mar 10 21:05:39 debian-home kernel: ata9.00: configured for UDMA/133
Mar 10 21:05:39 debian-home kernel: sd 8:0:0:0: [sda] tag#17 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_OK cmd_age=31s
Mar 10 21:05:39 debian-home kernel: sd 8:0:0:0: [sda] tag#17 Sense Key : Illegal Request [current]
Mar 10 21:05:39 debian-home kernel: sd 8:0:0:0: [sda] tag#17 Add. Sense: Unaligned write command
Mar 10 21:05:39 debian-home kernel: sd 8:0:0:0: [sda] tag#17 CDB: Read(10) 28 00 3c c4 94 28 00 04 00 00
Mar 10 21:05:39 debian-home kernel: I/O error, dev sda, sector 1019515944 op 0x0:(READ) flags 0x80700 phys_seg 9 prio class 2
Mar 10 21:05:39 debian-home kernel: sd 8:0:0:0: [sda] tag#18 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_OK cmd_age=31s
Mar 10 21:05:39 debian-home kernel: sd 8:0:0:0: [sda] tag#18 Sense Key : Illegal Request [current]
Mar 10 21:05:39 debian-home kernel: sd 8:0:0:0: [sda] tag#18 Add. Sense: Unaligned write command
Mar 10 21:05:39 debian-home kernel: sd 8:0:0:0: [sda] tag#18 CDB: Read(10) 28 00 3c c4 98 28 00 04 00 00
Mar 10 21:05:39 debian-home kernel: I/O error, dev sda, sector 1019516968 op 0x0:(READ) flags 0x80700 phys_seg 9 prio class 2
Mar 10 21:05:39 debian-home kernel: ata9: EH complete

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

Viktoria-20250525.png https://pasteboard.co/GbhZLhcmZ9Ad.png
Viktoria-20250822.png https://pasteboard.co/MC4zAULziyq7.png

Заметь, 15 –> 11, 2378 –> 2144. Магия да? Т.е диск стал на 3 месяца старше и поверхность стала лучше. Вангую, что в 15 секторах с 250мс четырем секторам стало плохо и он их втихую заремапил. А 100мс - не знаю что произошло. И да, скорость чтения заремапленных секторов может не падать по причине того, что резерв может быть сначала диска, где скорость выше. Или вообще резерв может нарезаться параллельно обычным дорожкам. Хз, доки бы!

Мда...

Реаллок это и есть замена из резерва, что ты несёшь то?

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

Магия да?

Беспонятия. Вы вобще в начале писали, что у вас НЖМД болтался в корпусе, думаете это только на чтение сказывается? Возможно, что эти сектора были перезаписаны при нормальной эксплуатации. У вас исходно неправильное представление, что если сектор стал плохо читаться, то всё. Сектор мог быть исходно плохо записан, по какой-то из множества случайных причин и просто ещё одна запись в этот сектор его чинит.

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

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

Или вообще резерв может нарезаться параллельно обычным дорожкам.

Точно, половину поверхности под резерв. И пофиг на плотность записи. Резерв делали в одном месте, так как заранее неизвестно где будут дефекты. Выделять, допустим, два сектора на цилиндр смысла нет, на каком-то цилиндре может возникнуть 10 bad, а на остальных 0. Скорости не добавит, а логику работы с remap-секторами усложнит.

Хз, доки бы!

Учебников по НЖМД нет, знания размазаны. Maxtor, вроде, любил подробно разжёвывать, он же SMART придумывал. Только его нет и док его нету. Вот, допустим: https://documents.westerndigital.com/content/dam/doc-library/en_us/assets/pub...

3.13.7 Defect Management
Every Western Digital drive undergoes factory-level intelligent burn in, which thoroughly tests for and maps out defective sectors on the media before the drive leaves the manufacturing facility. Following the factory tests, a primary defect list is created. The list contains the cylinder, head, and sector numbers for all defects. Defects managed at the factory are sector slipped. Grown defects that can occur in the field are mapped out by relocation to spare sectors on the inner cylinders of the drive.

Для справки: https://en.wikipedia.org/wiki/Sector_slipping

Далее, из следующего раздела этого документа:

The following item is specific to automatic defect retirement on reads (read autorelocation):
 When host retries are enabled, the drive will internally flag any unrecoverable errors (DAMNF or ECC). This flagging allows subsequent write commands to this location to relocate the sector only if the sector test fails.

Запись в realoc-сектор, только если запись в этот нечитающийся сектора провалилась.

В описании параметров SMART от WD:

Reallocated Sectors Count. The raw value represents a count of the bad sectors that have been found and remapped.

Нигде нет про «скрытый remap в случае плохого чтения».

Но, это всё про обычную запись. Черепичная запись уже, судя по результатам тестов, стала хитрой, под чем-то напоминает SSD, и там НЖМД, скорее всего, сам может перезаписывать большие области иметь какой-то кеш, с низкой плотностью записи и пр.

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

З.Ы. лучше брать кабель с фиксатором

1. эти кратковременные отвалы не постоянные
2. до марта месяца этих сообщений в логе не было. Возможно с каким-то апдейтом начало это писать
3. конечно полный набор действий сделаю

Видишь, информация сегментарная и с разных источников. Я не склонен на 100% доверять каким-то источникам. К тому же производители hdd могут и будут утаивать какую-то инфу о своих продуктах. Например, у нас же нет информации о кол-ве секторов в резервной области. Область есть, а информации о ней нет. Поэтому и гадаем на кофейной гуще. А так-то вторю, что я склоняюсь к тому, что блины всегда имеют бэды и накопитель их втихую перешивает из резервной области. Что бы не говорила вики и какая-то дока из WD

информация сегментарная и с разных источников.

Добро пожаловать в реальный мир. По всем реальным предметам так. Берем проект/тех. документацию, там в начале перечисление кучи ГОСТ, ФЗ и пр. чему проект соотвествет — куча разных источников. И никто не объясняет, что такое «гайка», «болт» и т.д.

Я не склонен

О, да пожалуйста. Вы пока могли спокойно прочитать про FD (НГМД), там полно открытой информации, узнали бы, что означает форматирование там, как на дорожке лежат биты.

Поэтому и гадаем на кофейной гуще

Кто-то гадает, а кто-то разрабатывает/дорабатывает PC-3000. Общаясь с прошивкой НЖМД можно много чего узнать.

По дорогам ездит куча разных авто, и у них схожая конструкция. И по ним нет одного источника, как у них внутри всё устроено. Конечно, можно считать, что внутри двигателя сидят зёлный человечки и крутят педали (== НЖМД сам перемещает сектора, но не увеличивает Reallocated_Event_Count), но сомнительно.

эти кратковременные отвалы не постоянные

Именно

до марта месяца этих сообщений в логе не было. Возможно с каким-то апдейтом начало это писать

Скорее, контакты в кабеле ослабли. Как уже говорил, новый бери с фиксатором (металлическая полоска, которая работает как замок и кнопка)

У меня одно время в домашнем сервере было 6 hdd. Через какое-то время они начали так же сыпать ошибками, пока кабели не заменил

Это происходит при загрузке. Шлейф новый шел с материнкой. Он с фиксатором

В смысле «только при загрузке»? Тогда может БП не тянет

потому что эти строки - именно отвал линка

Aug 21 15:56:23 debian-home kernel: ata9.00: irq_stat 0x00000040, connection status changed

Aug 21 15:56:23 debian-home kernel: ata9: SError: { PHYRdyChg CommWake DevExch }

Aug 21 15:56:23 debian-home kernel: ata9.00: failed command: READ FPDMA QUEUED

Aug 21 15:56:23 debian-home kernel: ata9.00: cmd 60/00:40:00:68:36/04:00:73:00:00/40 tag 8 ncq dma 524288 in

                                        res 40/00:3c:00:64:36/00:00:73:00:00/40 Emask 0x10 (**ATA bus error**)

Aug 21 15:56:23 debian-home kernel: ata9.00: status: { DRDY }

до марта месяца

До Марта какого года?

Отвал линка не обязательно кабель. Были проблемы с SATA link power management. В ядре не раз меняли дефолт параметры и через вой в багзиле расширяли список бажных контроллеров... /sys/class/scsi_host/host3/link_power_management_policy, /proc/sys/vm/laptop_mode

Но, так как ТС не гуглит по модели контроллера/материнки, не пишет нормально ли Power_On_Hours 22842 vs Power_Cycle_Count 5575 (отключение каждые 4 часа) то пусть меняет кабель :) Это безобиднее, чем откручивать плату от гермоблока и тереть контакты к блоку головок у исправного НЖМД.

да щас. это значит, что диск сильно занят и линк отваливается по таймауту. у меня Тошиба P300 так себя ведёт при сильной загрузке, при этом не единого бэда - просто контроллер тормозной.

это значит, что диск сильно занят и линк отваливается по таймауту.

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