Смарт давай. Пробуй testdisk.

Смарт давай.

smartctl -ax /dev/sdb : http://pastebin.com/2jftRmWd

smartctl -ax /dev/sdb6 : http://pastebin.com/H6vnXVW8

Так-то всё неплохо, вроде. Попробуй тестдиском оживить раздел.

пытаюсь... testdisk /dev/sdb6 но что-то никак (может конечно давно этой штукой не пользовался)

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

понял, спасибо, я пока что вот файлы уже увидеть сумел. просто видимо не дождался всего /dev/sdb и решил конкретнее сделать /dev/sdb6

вроде восстановил в fdisk -l пропало

Раздел 4 начинается не на границе физического сектора.

но все равно при старте, не хочет /dev/sdb6 монтироваться, да еще, забыл сообщить, в rc.local у меня практически всегда было прописано hdparm -B 254 -S 0 /dev/sdb я это умышленно сделал, т.к. машина все равно на месте стоит и диск постоянно цокал

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

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

Фс сдохла, хрен её знает почему.

В смарте 1 нестабильный сектор (атрибут 197).

Current_Pending_Sector 1 штука

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

Дефекты на поверхности, видно же

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

ну я раздел форматнул вот вроде сижу

не посмотрите, а сейчас? http://pastebin.com/exSYwCPe

Эм, а на что смотреть?

Диск тот же, и диск неисправен.У него дефекты на поверхности. Если вам нравится работать на минном поле, велкам :) Если совсем некуда деваться, просканируйте диск, определите, какие области сбойные, и если они локальны, а не по всему диску, то переразбейте диск так, чтоб дефекты попали на неразмеченный участок. Хотя при нынешней цене на бу терабайтники я даже не знаю, чего ради такие пляски. Я бы советовал ценные данные с него снять и под замену.

и вот еще вопрос, рсинк репозиториев так мог убить жесткий?

Если вам нравится работать на минном поле

при нынешней цене на бу терабайтники

Или крестик сними, или трусы надень.

просадка питания при записи

да, еще информация, диск с которым данное произошло вставлен в контейнер, который вставляется вместо cd-rom'а ноутбука и в общем-то там у меня этот sdb и был пару лет, может год

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

но вот как посоветуйте разбить, таблицу ms-dos я лично предпочитаю или лучше делать 4 главных или весь media-диск - один раздел?
И после разметки и форматирования в конкретной ФС, какие действия для проверки проделать, check и вывод smartlctrl'ом?

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

Пока на диск ничего не писалось, есть смысл прогнать его mhdd.

Поднять содержимое раздела было можно с большой вероятностью, сняв образ при помощи ddrescue и 1) монтируя его или 2) пройдя по диску mhdd (если сектор оживет или ремапнется).

Чего сказать хотел, остроумец?

Я вот, например, хотел сказать, что найти исправный диск недорого несложно, а диск ТС заведомо неисправен, а ты?

Нет, не мог

Ну, конечно, если рсинк не делался в завернутом в три свитера ноуте на стиральной машинке в режиме отжима :)

У тебя в тексте взаимоисключающие параграфы.

б/у диск
исправный диск

Меня одно говно на другое говно.

определите, какие области сбойные, и если они локальны, а не по всему диску, то переразбейте диск так, чтоб дефекты попали на неразмеченный участок

удалил в обще все разделы, форматнул уже несколько раз в ext4 и один раздел на весь диск сделал, толку по ходу нет

http://pastebin.com/T9x1CUsd

есть какие-нибудь еще предложения?

т-щ bormant - mhdd советует, уже после всего не уверен даст ли эта утилитла толк... и боюсь дело уже в самом жестком.

Тогда вопрос ребят, попробую поискать чек и если гарантия осталась, то в СЦ, идти с какими претензиями что бы на свою проверку или починку они взяли диск? Сказать, что у меня linux и smartctrl то-то показывает - не уверен, что будет достаточным

Диск отработал 2 с лишним года чистого времени, он ещё на гарантии?
Обратите внимание на большое количество показателей в состоянии pre-fail (флаг P).

Если замена не светит, можно стереть диск в mhdd, затем в нем же прогнать тест на предмет наличия и расположения медленных и сбойных блоков. Дальнейшее решение принимать по результатам. Если диск не «сыпется» (показатели стабильны, не ухудшаются), еще вполне послужит, но на сильно ответственные задачи использовать его не стоит.

2-3 года гарантия вроде бы, на ссд у меня 3 точно , вроде как

Диск отработал 2 с лишним года чистого времени

по мне это немного он отработал, помню старое время диски 80-300Gb IDE работали и по 10 лет
На них и винда и линь бывали, а на этом только линь и swap+ext4

по мне это немного он отработал

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

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

От неразрушающего теста нет толку, кроме получения статистики по медленным блокам и их расположению.
Тем не менее, для получения общей картины есть смысл его прогнать хотя бы раз (можно было бы на ночь оставить, если знать, что не будет ошибок, после которых контроллер все последующие операции считает за сбойные и требует сброса вручную (да элементарно перегреться может). Но без хотя б одной проверки под присмотром такое знание взять неоткуда).
Затем выписать расположение сбойных блоков.
Затем прогнать тесты с перезаписью ошибок/замедлений на участках, их содержащих, задавая соответственно диапазоны LBA. Тут mhdd/whdd будет пытаться спровоцировать контроллер на ремап. Имеет смысл при наличии места в пользовательской таблице ремапов. Запускать тест с перезаписью на весь диск без присмотра — плохая идея из-за возможности ошибок, приводящих контроллер в неадекватное состояние, см. выше.

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

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

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

Наблюдал интересный случай, когда машина на загрузке «вставала колом» на 5-15-25 минут с явными признаками зависания, но по истечении указанного времени нормально продолжала загрузку. В журнале, естественно, дикие таймауты и ошибки по чтению от диска. Бэкап, стирание медленного участка в mhdd, восстановление проблему полностью устранило.
Был в руках переносной диск со сбойным сектором в интересном месте, ставил колом минут на 5-30 машину, куда его подключали, потом все отмирало. «Стирание ошибки» (ремап) в mhdd вернуло бедолагу в строй.

Remap это не стирание ошибки. Ошибка как была так и осталась. Это перезапись таблицы сбойных участков диска.

Remap это не стирание ошибки. Ошибка как была так и осталась. Это перезапись таблицы сбойных участков диска.

Спасибо, кэп.

Перечитайте то, на что отвечали еще раз, продолжайте до полного понимания смысла прочитанного.

Да, решение о ремапе принимает контроллер диска. Спровоцировать его на принятие решения о ремапе можно записью в «плохие» сектора. Плохие сектора могут быть как «медленными» — из которых удается что-либо прочитать (многократное чтение+коррекция ошибок), так и сбойные (из которых уже ничего прочитать не удаётся). У mhdd (и его последователей whdd/Victoria/...) есть режим «стирания ошибок» — многократная перезапись сбойных секторов с целью вызвать ремап. Данные в этих секторах уже потеряны (то есть хуже уже не будет), содержащие их файлы, да, уже повреждены, а после операции будут повреждены несколько иначе.

«Стирание ошибок» — это терминология mhdd и последователей, так назван один из режимов работы, все претензии на этот счет не ко мне.

Сейчас в чём конкретно проблема с диском?

проблема в этом http://pastebin.com/raw/T9x1CUsd

dell ~ # smartctl -ax /dev/sdb | grep Err
Error logging capability:        (0x01)	Error logging supported.
					SCT Error Recovery Control supported.
  1 Raw_Read_Error_Rate     POSR-K   100   100   051    -    2575
  7 Seek_Error_Rate         -OSR-K   252   252   051    -    0
191 G-Sense_Error_Rate      -O---K   100   100   000    -    31
199 UDMA_CRC_Error_Count    -OS-CK   200   200   000    -    0
200 Multi_Zone_Error_Rate   -O-R-K   100   100   000    -    172
0x10       GPL     R/O      1  SATA NCQ Queued Error log
SMART Extended Comprehensive Error Log Version: 1 (2 sectors)
Device Error Count: 1926 (device log contains only the most recent 8 errors)
	ER     = Error register
Error 1926 [5] occurred at disk power-on lifetime: 19194 hours (799 days + 18 hours)
  40 -- 51 00 08 00 00 33 00 f0 40 40 00  Error: UNC at LBA = 0x3300f040 = 855699520
Error 1925 [4] occurred at disk power-on lifetime: 19194 hours (799 days + 18 hours)
  40 -- 51 00 10 00 00 33 00 f0 40 40 00  Error: UNC at LBA = 0x3300f040 = 855699520
Error 1924 [3] occurred at disk power-on lifetime: 19194 hours (799 days + 18 hours)
  40 -- 51 00 10 00 00 33 00 f0 40 40 00  Error: UNC at LBA = 0x3300f040 = 855699520
Error 1923 [2] occurred at disk power-on lifetime: 19194 hours (799 days + 18 hours)
  40 -- 51 00 10 00 00 33 00 f0 40 40 00  Error: UNC at LBA = 0x3300f040 = 855699520
Error 1922 [1] occurred at disk power-on lifetime: 19194 hours (799 days + 18 hours)
  40 -- 51 00 10 00 00 33 00 f0 40 40 00  Error: UNC at LBA = 0x3300f040 = 855699520
Error 1921 [0] occurred at disk power-on lifetime: 19194 hours (799 days + 18 hours)
  40 -- 51 00 10 00 00 33 00 f0 40 40 00  Error: UNC at LBA = 0x3300f040 = 855699520
Error 1920 [7] occurred at disk power-on lifetime: 19194 hours (799 days + 18 hours)
  40 -- 51 00 18 00 00 33 00 f0 48 40 00  Error: UNC at LBA = 0x3300f048 = 855699528
Error 1919 [6] occurred at disk power-on lifetime: 19194 hours (799 days + 18 hours)
  40 -- 51 00 20 00 00 33 00 f0 40 40 00  Error: UNC at LBA = 0x3300f040 = 855699520
SMART Error Log Version: 1
No Errors Logged
SCT Error Recovery Control:

то что не знаешь и чего ждать в дальнейшем

У mhdd (и его последователей whdd/Victoria/...) есть режим «стирания ошибок»

звучит просто)

Прочитал все что Вы написали, честно не понял, «что делать?»

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

я так вчитываюсь в это и чую что целая гора ключей к команде ждет

Тут mhdd/whdd будет пытаться спровоцировать контроллер на ремап

Кстати, а на _SBo этот пакет-билд брать надо?
https://slackbuilds.org/repository/14.2/system/mhddfs/?search=mhdd

Whdd я с другого лив-сиди дистра просто запускал

Тем временем... засунул контейнер с данным жестким в ноут с Win7 , там пришлось его разметить, резметил, прогнал на ошибки раздел который по картинке винды у меня на всем жестком расположился и 5 ошибок вроде как она нашла, а толку вот, вставил этот диск в машину с линем, там опять smartctrl и опять Error'ы

раздел hdd не читается и не монтируется (комментарий)

MHDD можно тут взять: http://www.mhdd.ru/download.html Эта программа не для системы, а загрузочный образ.

...кстати знаете ребят, я что еще вспоминаю, было дело я на этом жестком KDE4-SC собирал(

Если проверяете на Win7, возьмите Victoria.

Создание разделов к теме не имеет отношения, mhdd, whdd, Victoria командуют диском, посылая команды контроллеру напрямую.
Поэтому, разделы, ФС и прочие верхние абстракции к делу отношения не имеют, только адрес блока (LBA) и не выше.

я хочу понять, если ремапнуть, то тут это просто размер hdd (без разделов) изменится или я что-то не то смотрю в гугле?

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

Я тут это, прогнал в Victoria и что-то Error и не нашлись
http://meson.ad-l.ink/79krK89Td/image.png

сейчас попробую удалить все с диска и в linux - smartctrl опять глянуть

Потом наверно опеть прогоню сначала в Restore , потом в Remap, постараюсь от оранжевых меток избавиться. У меня уже подозрение что smartctrl в lin'е просто что-то мудрит(

http://pastebin.com/d5eSDVfs ошибки не исчезли

SMART можно и в Victoria смотреть.

Restore — зачем? Кстати, басплатная версия этот режим не поддерживает.

потом в Remap, постараюсь от оранжевых меток избавиться

Remap — запускается только для секторов в состоянии Err, поэтому смысла нет.

Выставить начало-конец слева/справа от сбойного блока с небольшим запасом, выполнить тест Write вместо чтения (все равно на диске уже ничего нет ценного), по окончании теста продолжать «Loop test». Вместо последовательного чтения/записи можно (лучше) выставить случайное. Прогнать несколько кругов, контролируя ремап, прервать.

Повторить со вторым блоком (третьего не вижу в логе, с ним тоже).

Проверить достигнут ли ожидаемый результат, задав по очереди диапазон проверки вокруг сбойных участков (LBA 486677760 и 667988992).

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

прогнал в Victoria и что-то Error и не нашлись

Зато есть точки с доступом почти в секунду. И если там лежит суперблок, то ...

сейчас в erase все прогоняю

Повторить со вторым блоком (третьего не вижу в логе, с ним тоже).

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

басплатная версия этот режим не поддерживает

уже выяснил, да, есть такое

Мне кажется Win-версия она не та что ли, никак флэшкодосовская что ли, я к тому что из-за этого в Виктории не светятся ошибки, ну реально, не показывает ошибок же

в erase все прогоняю

всё-то зачем? только диск греть лишний раз ;-)
Хотя, хозяин — барин.

в начале подчистил

журнал проверки в LOGS в каталоге с викторией

Win-версия она не та что ли

вид другой, алгоритмы те же. Может работать через порты при наличии драйвера (на 64 битах не видел) и через API (кое что недоступно: пароли, HPA, регистры).

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