воскресенье, 13 ноября 2016 г.

Обработка ошибок у разных дисков

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

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

И тут я вспомнил, что десктопному винту можно добавить чуток "серверности" подкрутив параметр SCT ERC (TLER в терминологии WD). В этом случае винт не пытается мучить сбойный сектор до посинения, а по истечении некоторого времени на попытки - сообщает об ошибке. В этом случае RAID контроллер просто читает нужный сектор с другого диска и проблем с тормозами в системе не возникает. Собственно это одно из важных отличий дисков, предназначенных для RAID, от десктопных. Но поскольку меня интересует только быстрый пропуск сбойных секторов, то мне нужно выставить минимально разумное время попытки чтения секторов.

Пробую выяснить поддержку SCT в S.M.A.R.T.:

# smartctl -a /dev/sda | grep SCT
SCT capabilities:  (0x3037)  SCT Status supported.
                             SCT Feature Control supported.
                             SCT Data Table supported.

Что-то не видно в выводе про "Error Recovery Control" - проверяю это:

# smartctl -l scterc /dev/sda
Warning: device does not support SCT Error Recovery Control command

Не выйдет моя задумка - управление ERC (Error Recovery Control) в WD5000AAKX отсутствует. А теперь сравнение с не менее десктопными Toshiba DT01ACA300 у который с SCT ERC все в порядке:

# sudo smartctl -a /dev/sdb | grep SCT
SCT capabilities:  (0x003d)  SCT Status supported.
                             SCT Error Recovery Control supported.
                             SCT Feature Control supported.
                             SCT Data Table supported.

# sudo smartctl -l scterc /dev/sda
SCT Error Recovery Control:
           Read:     70 (7.0 seconds)
          Write:     70 (7.0 seconds)

Для десктопа, где зачастую жесткий диск только один важно установить значение SCT ERC в 0 (отключение таймаута), а для RAID наоборот нужно установить его значение в небольшое значение. По-умолчанию в Linux значение таймаута SCSI команд равно 30 секундам (/sys/block/sda/device/timeout).

суббота, 12 ноября 2016 г.

Siemens MC60 - умели же делать телефоны

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


Телефон у нее появился в 2004 и был отправлен в отставку только в начале 2010. С тех пор телефоном никто не пользовался и хранился он с извлеченным аккумулятором. После теста я выключил телефон, но не извлек аккумулятор.

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

Сегодня жена рассказала, что в детском садике сломался мобильный телефон, который лежит в группе. Этот телефон удобен тем, что позвонив на него можно пообщаться с тем воспитателем, который сейчас с детьми (сказать что опаздываем, заболели и не придем или попросить не укладывать ребенка спать днем, т.к. заберешь его после обеда). Сразу вспомнился тот Siemens MC60, который я предложил отдать в садик.

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


Пол-часа я мучался с очисткой телефона от личной инфы (контакты, sms, "фотки", и т.д.), но аккумулятор уверенно показывал прежний заряд. Я уверен, что этот телефон и дальше будет служить верой и правдой.

Собственно к чему я это - Siemens A50, SL45, M55, S55, MC60, ... Их делали инженеры, а не маркетологи! И хотя инженеры в итоге проиграли (в 2005 телефонное подразделение Siemens отошло к Benq), но их творения живы и по сей день. Снимаю шляпу!

Скручен "пробег" у жесткого диска?

На прошлой недели покупали коплектующие для нового компьютера в офис, среди них был диск WD5000AAKX - популярная модель из серии WD Blue. Новый компьютер я собрал во вторник, а уже в среду жетский диск посыпался бэдами. Что ж бывает - диск заменили, но теперь нужно подготовить обоснование для возврата по гарантии. В этом случае обычно достатоно сделать распечатку вывода smartctl -AHi -  вот как он выглядит на этом диске:

smartctl 6.4 2014-10-07 r4002 [x86_64-linux-4.0.0-1-amd64-finnix] (local build)
Copyright (C) 2002-14, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF INFORMATION SECTION ===
Model Family:     Western Digital Caviar Blue (SATA 6Gb/s)
Device Model:     WDC WD5000AAKX-22ERMA0
Serial Number:    WD-C1UQ747597479
LU WWN Device Id: 0 000000 000000000
Firmware Version: 35.25Q.0
User Capacity:    500,107,862,016 bytes [500 GB]
Sector Sizes:     512 bytes logical, 4096 bytes physical
Device is:        In smartctl database [for details use: -P show]
ATA Version is:   ATA8-ACS (minor revision not indicated)
SATA Version is:  SATA 3.0, 6.0 Gb/s (current: 6.0 Gb/s)
Local Time is:    Thu Nov 10 13:33:48 2016 UTC
SMART support is: Available - device has SMART capability.
SMART support is: Enabled

=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: FAILED!
Drive failure expected in less than 24 hours. SAVE ALL DATA.
See vendor-specific Attribute list for failed Attributes.

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     0x0001   200   200   051    Pre-fail  Offline      -       5
  3 Spin_Up_Time            0x0001   147   137   021    Pre-fail  Offline      -       3608
  4 Start_Stop_Count        0x0000   100   100   000    Old_age   Offline      -       39
  5 Reallocated_Sector_Ct   0x0001   133   133   140    Pre-fail  Offline  FAILING_NOW 3041
  7 Seek_Error_Rate         0x0001   200   200   051    Pre-fail  Offline      -       118
  9 Power_On_Hours          0x0000   100   100   000    Old_age   Offline      -       75
 10 Spin_Retry_Count        0x0001   100   253   051    Pre-fail  Offline      -       0
 11 Calibration_Retry_Count 0x0000   100   253   051    Old_age   Offline      -       0
 12 Power_Cycle_Count       0x0000   100   100   000    Old_age   Offline      -       22
184 End-to-End_Error        0x0001   100   100   097    Pre-fail  Offline      -       0
187 Reported_Uncorrect      0x0000   099   099   000    Old_age   Offline      -       1
188 Command_Timeout         0x0000   098   098   000    Old_age   Offline      -       8590065666
190 Airflow_Temperature_Cel 0x0000   067   043   000    Old_age   Offline      -       33
192 Power-Off_Retract_Count 0x0000   200   200   000    Old_age   Offline      -       19
193 Load_Cycle_Count        0x0000   200   200   000    Old_age   Offline      -       8
194 Temperature_Celsius     0x0000   110   086   000    Old_age   Offline      -       33
195 Hardware_ECC_Recovered  0x0000   200   200   000    Old_age   Offline      -       0
196 Reallocated_Event_Count 0x0000   084   084   000    Old_age   Offline      -       116
197 Current_Pending_Sector  0x0000   200   200   000    Old_age   Offline      -       0
198 Offline_Uncorrectable   0x0000   100   253   000    Old_age   Offline      -       0
199 UDMA_CRC_Error_Count    0x0000   200   200   000    Old_age   Offline      -       0
200 Multi_Zone_Error_Rate   0x0001   100   253   051    Pre-fail  Offline      -       0

За 75 часов работы диск ощутимо покрылся BAD блоками. Возможно заводской брак в механике - подумал я и отправил отчет на печать. Уже выделяя маркером "важные" параметры в отчете для гарантийщиков, я заметил несовпадение серийного номера (S/N) и модели диска (MDL) в отчете S.M.A.R.T. и на наклейке:


По данным S.M.A.R.T. серийник WD-C1UQ747597479 и модель WD5000AAKX-22ERMA0, но на наклейке значатся WCBAEPU56008 и WD5000AAKX-08U6AA0 соответственно. В принципе я допускаю, что на наклейке номер может незначительно отличаться (быть более полным или наоборот - обрезанным). Но тут номера не совпадают совсем. Еще смущает дата выпуска - 10 февраля 2015, а куплен диск был 4 ноября 2016. С учетом того, что модель популярная, то слабо верится что он почти два года лежал на складах.

Перехожу к обратной стороне:



И сразу бросается в глаза квадрат на плате со следами клея (1). По номеру ревизии платы электроники диска (2060-771824-005 REV A) нашел изображение платы в интернете:

Изображение с сайта www.dawntech.cc

На месте квадрата со следами клея должен быть стикер с QR кодом. Поскольку диск новый и ставил я его аккуратно, то я уверен что стикера на нем не было. Дальше стикер с надписью "DELUX EP-450TC" (2) - это вообще от компьютерного блока питания! Про стикер с надписью "2016 / 6" (3) - трудно судить наверняка, но с учетом что дата отличается от даты выпуска почти на полтора года, то создается впечатление, что передо мной refirbished диск, который нам продали под видом нового (вот хоть убей, но не могу вспомнить был ли запаян антистатический пакет с диском).

Если это действительно не новый диск, то тогда понятно почему серийный номер и модель в S.M.A.R.T. отличаются от указанных на диске.

четверг, 10 ноября 2016 г.

userauth_pubkey: key type ssh-dss not in PubkeyAcceptedKeyTypes

В Ubuntu 16.04.1 из коробки отключена поддержка DSA ключей (споры на эту тему). Насколько это оправдано - решать вам, но если вам очень нужно ее включить обратно, то добавьте в /etc/ssh/sshd_config строку "PubkeyAcceptedKeyTypes=+ssh-dss".

echo 'PubkeyAcceptedKeyTypes=+ssh-dss' | sudo tee -a /etc/ssh/sshd_config
sudo service ssh reload

После этого можно зайти с DSA ключем.

воскресенье, 6 ноября 2016 г.

Как мне GPON втюхали

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

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

Под конец месяца явился еще один установщик с терминалом GPON, подключил оборудование и сообщил новый номер. Вот тут начинается самое главное - поскольку сменился номер, то логично предположить что при звонке на старый будет выполнено перенаправление на новый номер. До этого я не раз слышал как робобаба диктует сообщение про смену номера и после этого идет переключение на новый номер. Но при попытке набрать свой старый номер я услышал только длинные гудки и никакой реакции телефона. Сначала подумал, что переадресацию не включили из-за конца недели, но когда на следующей неделе картина не изменилась, то я позвонил в поддержку БТК. Меня выслушали и сообщили, что все нормально и "так работает система". Мол когда все абоненты старой АТС перейдут на GPON, то всем автоматически включат оповещение и переадресацию. Но когда это произойдет хотя бы ориентировочно, ответить затруднились.

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

Что в сухом остатке:
  • мне навязали "бесплатный" переход на GPON
  • если не упереться, то может пострадать ремонт в квартире
  • мне сменили номер, но за переадресацию придется дополнительно платить
  • в бытовом плане оптоволокно значительно менее практичный вариант в сравнении с медными кабелями, которые обслуживать я могу самостоятельное
  • если установлена охранная сигнализация, то за модернизацию придется доплатить около 140 BYN (~73$)